[jboss-jira] [JBoss JIRA] (AS7-6801) Complete support for Bundle uninstall

[Thomas Diesler (JIRA)]

     [ https://issues.jboss.org/browse/AS7-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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