search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[rfc 66] "Uninstalling web application" section is ambiguous #1231

Closed bjhargrave closed 15 years ago

bjhargrave commented 15 years ago

Original bug ID: BZ#1332 From: sahoo@sun.com Reported version: R4 V4.2

bjhargrave commented 15 years ago

Comment author: sahoo@sun.com

Section BZ#5.2.4 of the draft dated 15 May 2009 says the following: "A web application can be uninstalled by simply stopping the corresponding web application bundle. The application will be permanently removed from the framework."

It is not clear as to what does "framework" mean here? Is it referring to OSGi framework? That can't be the case, as simply stopping a bundle can't and should not lead to uninstallation of the bundle. Then, does framework mean underlying web container? If so, I am curious to know the interpretation of "permanently removed from the framework." How can this be validated by a test case regardless of container implementation?

bjhargrave commented 15 years ago

Comment author: Alasdair Nottingham <not@uk.ibm.com>

You are right, this is wrong, it should read:

"A web application can be stopped by simply stopping the corresponding web application bundle. Uninstalling the web application bundle from the framework will cause the application to be permanently removed from the framework."

This means if the Bundle.stop method is invoked then the bundle will be stopped and the web container will cease serving content.

If the Bundle.uninstall method is invoked then the bundle will be stopped (see above) and the bundle will be removed from the framework.

These are standard OSGi semantics.

bjhargrave commented 15 years ago

Comment author: Richard Hall <richard.s.hall@sun.com>

To be precise, if the Bundle.uninstall() method is invoked, then the bundle will be uninstalled, but not completely removed until the framework is refreshed.

bjhargrave commented 15 years ago

Comment author: sahoo@sun.com

You are right, this is wrong, it should read:

"A web application can be stopped by simply stopping the corresponding web application bundle. Uninstalling the web application bundle from the framework will cause the application to be permanently removed from the framework."

This means if the Bundle.stop method is invoked then the bundle will be stopped and the web container will cease serving content.

Should this be clarified further? Let's say the underlying web container allows "disable" functionality to temporarily disable a web app, is it enough to call "disable" upon stop event? If yes, then on next start event, the same old ServletContext is used. Is this OK? Or, does the spec actually mean the web app be undeployed from underlying web container leading to stopping of all the web context listeners and destruction of servlet context when the bundle is stopped? Or, is it left to individual implementation? Whatever the case, it is better to clarify this in the spec.

If the Bundle.uninstall method is invoked then the bundle will be stopped (see above) and the bundle will be removed from the framework.

These are standard OSGi semantics.

Agreed.

bjhargrave commented 15 years ago

Comment author: mkv@us.ibm.com

Stopping a bundle has well defined semantics in OSGi. It is expected that a stopped bundle should release any resources it has acquired, and terminate threads, via stop() method of a bundle activator. The framework automatically unregisters the services exported by a stopped bundle. While the packages exported by the bundle continue to be available, it is expected that a stopped bundle should not provide useful function, in a good service centric design.

A typical use of OSGi extender pattern maps bundle start and stop life cycle events to the life cycle of the application itself. It would be useful to not leave the application in a undefined state post bundle stop. Additionally, updating a bundle (which causes it to be stopped and restarted under the covers) can trigger the extender to refresh the application without side effects. I think it would be reasonable to say that stopping a bundle should result in the following:

  1. Sservices registered by the bundle are unregistered (enforced by the framework), and references are no longer valid.
  2. Web container must stop serving the content that belongs to a stopped application
  3. Web container should treat the stop operation as a "application stop", and clean up application resources. This means, releasing any resources held by the application, invoking the context listeners, and destruction of servlet context etc.

This would be consistent with how a Blueprint extender manages module contexts of stopped bundles.

I will update the spec with these clarifications, pending specific objections.

bjhargrave commented 15 years ago

Comment author: mkv@us.ibm.com

Fixed in draft 13