[jboss-osgi-issues] [JBoss JIRA] (JBOSGI-704) Complete support for Bundle start/stop

[Thomas Diesler (JIRA)]

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

Thomas Diesler moved WFLY-555 to JBOSGI-704:
--------------------------------------------

        Project: JBoss OSGi  (was: WildFly)
            Key: JBOSGI-704  (was: WFLY-555)
       Workflow: jira  (was: GIT Pull Request workflow )
    Component/s:     (was: OSGi)
                     (was: Server)

    
> Complete support for Bundle start/stop 
> ---------------------------------------
>
>                 Key: JBOSGI-704
>                 URL: https://issues.jboss.org/browse/JBOSGI-704
>             Project: JBoss OSGi
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>              Labels: roadmap
>
> 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