8 p.m.
Folks,
we are still having disconnects between the OSGi Bundle lifecycle operations and their
respective mapping to the deployment API. Here I'd like to describe how it currently
works and how it could possibly get fixed. Related issues are tracked by [1] - further
background is described in [2].
Bundle start/stop disconnect
--------------------------------------
A Bundle start/stop operation activates/deactivates the bundle services. The associated
class loader and wiring is unaffected.
Approach #1 - start/stop is not mapped to deployment operations
Bundle deploy installs the Bundle to the Framework
Bundle is not resolved/started as part of the deploy operation
No module/classloader is created during deployment
All deployment processing that needs load classes/resources is skipped
No service provided by the bundle deployment is created
Bundle needs to be started/stopped explicitly
Bundle start/stop management operations are specific to bundle deployments
The POST_MODULE processing for OSGi enabled deployments (e.g. webapp) would need to be
executed in an OSGi specific processor chain
OSGi enabled POST_MODULE DUPs have their functionality externalised such that it can get
reused for start/stop operations
The start/stop processing chain must be traversable in both directions repeatedly
Approach #2 - start/stop is mapped to deployment operations
Bundle deploy installs the Bundle to the Framework and attempts to resolve/start the
Bundle
If the Bundle can get resolved, a module/classloader is created as part of the DU
processing
In case the Bundle cannot get resolved, DUP processing is deferred and MODULE phase
processing is reattempted later based on an external trigger
Has the benefit that any deployment type can also be a Bundle
Bundle stop must reverse work that is done in POST_MODULE DUPs
POST_MODULE DUPs must be traversable in both direction multiple times
Currently, we use approach #2 with limited support from POST_MODULE DUPs (i.e. they are
not designed to be executed multiple times for the same deployment). There is also the
cleanup phase which breaks multiple executions of POST_MODULE DUPs.
Bundle uninstall disconnect
--------------------------------------
Bundle uninstall only removes the BundleRevision from the runtime if it is no longer in
use. The classloader associated with an uninstalled bundle that is still in use remains
active.
Approach #1 - "in use" semantic specific to Bundle deployments
An undeploy management operation undeploys the bundle revision but holds in the MODULE
phase when the revision is still in use
This is similar to deferred MODULE phase for deploy operation
in use is not respected for non-osgi deployments and hence breaks bundle deployments that
depend on them
Approach #2 - "in use" semantic applies to all deployment types
Undeploy will only destroy the Module service if the Module is not in use by another
deployment
When Module usage drops to zero, undeploy continues and removes the deployment from
management
This approach would map cleanly - there is no cascading destroy effect. i.e. when you
undeploy a jar that a webapp depends on
Services provided by the undeployed deployment would always go down, only classloader
destruction is deferred
Bundle update disconnect
------------------------------------
A Bundle can have multiple revisions. A call to Bundle.update(…) creates a new revision.
There is only ever one current revision (the latest update) associated with a Bundle.
Stale revisions continue to exist in the runtime until an explicit refresh of the
transitive dependency graph.
Approach #1 - bundle revisions are represented as individual deployments
Each bundle update deploys the revision as a new deployment
The association of revisions to bundle happens in the OSGi layer only
Management sees disconnected deployments with no notion of stale/current or belonging
together
Approach #2 - deployment API supports the notion of multiple revisions
deployments, their revisions and respective mapping would be modelled more closely on OSGi
requirements
some deployment types might not support revisions
------------------------------------------------------------------------------------------------------------------------------------------------------
I suspect that solving these disconnects can happen in the context of AS9 only.
Looking forward to your feedback
Cheers
--thomas
[1] [AS7-5567] Resolve AS8/OSGi disconnects
[2] AS/OSGi Deployment Lifecycle Requirements
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx