[JBoss JIRA] (WFLY-556) Complete support for Bundle uninstall
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-556?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-556.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Complete support for Bundle uninstall
> -------------------------------------
>
> Key: WFLY-556
> URL: https://issues.jboss.org/browse/WFLY-556
> Project: WildFly
> 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
12 years, 4 months
[JBoss JIRA] (WFLY-1104) Provide access to OSGiMetaData for server, web, etc
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1104?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1104.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Provide access to OSGiMetaData for server, web, etc
> ---------------------------------------------------
>
> Key: WFLY-1104
> URL: https://issues.jboss.org/browse/WFLY-1104
> Project: WildFly
> Issue Type: Feature Request
> Components: OSGi, Server
> Reporter: Thomas Diesler
>
> Currently we have a policy that server does not have a dependency on OSGi API and as a result to OSGiMetaData.
> In several places we do a check like this
> {code}
> if (depUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
> ...
> }
> {code}
> This however implies that the Manifest is the only possible source of valid OSGi metadata. The OSGi webapp spec allows for metadata to be specified as part of a "webbundle://" URI (see AS7-6006)
> To make this work, the integration code currently generates a Manifest and later OSGiMetaData from it. The above code still works even if the deployment content does not have a Manifest.
> I propose to move the OSGiMetaData one level down so that
> {code}
> if (depUnit.hasAttachment(Attachments.OSGI_METADATA)) {
> ...
> }
> {code}
> is the deciding criteria. As a additional benefit web would no longer need to produce/consume the raw Manifest headers and OSGi metadata would be treated like all other metadata structures.
--
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
12 years, 4 months