[
https://issues.jboss.org/browse/AS7-2777?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-2777:
--------------------------------
Description:
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.
was:
The JSR88 deployemt API allows control over the full deployment lifecycle
* deploy
* start
* stop
* undeploy
OSGi deployments (i.e. bundles) also have the notion of start/stop
This should be reflected in the management API for deployments.
Complete support for Bundle start/stop
---------------------------------------
Key: AS7-2777
URL:
https://issues.jboss.org/browse/AS7-2777
Project: Application Server 7
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