[
https://issues.jboss.org/browse/AS7-6801?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-6801:
--------------------------------
Description:
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
was:
In OSGi
Stops the bundle, destroys the BundleContext, prevents further starts and marks the bundle
as "removal pending". Determine the usage count of the bundle classloader (i.e.
number of wires to this bundle). Only if there is no active wire left the bundle can get
removed from the Framework and the bundle class loader can get garbage collected. Until
then, wires to the bundle stay active and resource/class loading continues to work as
before. A bundle gets removed from the Framework automatically when the last dependency
gets is marked as removal pending or if there is an explicit call to refresh the the
wirings of the dependency closure (i.e. removal pending bundles are thrown out new wirings
get established)
In AS today
Bundle uninstall causes an 'undeploy' management operation, which rolls back the
deployment through all DUPs and removes it from the Framework. AS has no notion of
"removal pending" or "in use" module. Due to the way deployment phase
services have dependencies on phase services from other deployments, we get an undesired
side effect of bundle deployments stopping/breaking if they have a dependency on an
undeployed bundle. As mentioned above, dependecies should be limited to services but not
on bundle lifecycle let alone break class loader dependencies.
Complete support for Bundle uninstall
-------------------------------------
Key: AS7-6801
URL:
https://issues.jboss.org/browse/AS7-6801
Project: Application Server 7
Issue Type: Sub-task
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 9.0.0.CR1
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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira