[jboss-jira] [JBoss JIRA] (WFLY-555) Complete support for Bundle start/stop

[Thomas Diesler (JIRA)]

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

Thomas Diesler resolved WFLY-555.
---------------------------------

    Resolution: Won't Fix


Won't Fix - OSGi is going to get removed
                
> Complete support for Bundle start/stop 
> ---------------------------------------
>
>                 Key: WFLY-555
>                 URL: https://issues.jboss.org/browse/WFLY-555
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: OSGi, Server
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>              Labels: roadmap
>             Fix For: 9.0.0.CR1
>
>
> 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.

--
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