[JBoss JIRA] (AS7-378) Support deployment of a set of Bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-378?page=com.atlassian.jira.plugin.sy... ]
Thomas Diesler updated AS7-378:
-------------------------------
Comment: was deleted
(was: This only seems to be an issue for bundle hot-deployment. The management API should support explicit start/stop through AS7-2777
We may need the notion of hot-deployment-extension-handler. I'll revisit this when the dependent issues are resolved.)
> Support deployment of a set of Bundles
> --------------------------------------
>
> Key: AS7-378
> URL: https://issues.jboss.org/browse/AS7-378
> Project: Application Server 7
> Issue Type: Sub-task
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 9.0.0.CR1
>
>
> In one deploy cycle, bundles must first get installed and then started.
> It generally needs to be discussed how multiple phase deployments should be handled.
--
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
11 years, 9 months
[JBoss JIRA] (AS7-6801) Complete support for Bundle uninstall
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6801?page=com.atlassian.jira.plugin.s... ]
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
11 years, 9 months
[JBoss JIRA] (AS7-2777) Complete support for Bundle start/stop
by Thomas Diesler (JIRA)
[ 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
11 years, 9 months
[JBoss JIRA] (AS7-5567) Resolve AS8/OSGi disconnects
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5567?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved AS7-5567.
---------------------------------
Resolution: Out of Date
Out of Date, see AS7-6952
> Resolve AS8/OSGi disconnects
> -----------------------------
>
> Key: AS7-5567
> URL: https://issues.jboss.org/browse/AS7-5567
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> An umbrella issue that collects tasks that need to be resolved to improve (or make it even work) OSGi/AS7 integration
> #1 Framework Startup
> At Framework startup a number bootstrap and persistent bundles (from a former run) need to be deployed before the Framework reaches its ACTIVE state. This cannot be modelled with service dependencies because must be possible to uninstall the persistent bundles without taking the Framework down. Tracked by AS7-5365
> #2 Defer Resolution Phase
> It is a MUST HAVE requirement that the user can deploy a large set of bundles in an arbitrary order. In OSGi we talk about a bundle states like
> * INSTALLED (metadata is known and valid)
> * RESOLVED (wiring is available, classes can get loaded)
> * ACTIVE (services that the bundle provides have started)
> Currently, any deployment running through the chain of deployment unit processors get a module created and a classloader associated. DUPs in the following phases assume that a classloader is available, which is currently not the case for unresolved bundles.
> This simplistic approach causes an ordering issue and does not work with OSGi bundles. Here it must be possible to install multiple bundles before the set can be resolved. Technically, bundle deployment must stop before the module phase and resume when bundle resolution is triggered. If this is done, the following DUPs can correctly assume that a classloader is available. Tracked by AS7-5477
> #3 Deployment Properties
> It is a MUST HAVE requirement that users can associate properties with a bundle deployment. This would for example be a bundle start-level or an auto-start flag that determines whether a bundle deployment should automatically resolve/start. This issue is a dependency of #2. On a technical level this needs to be supported by the management API and later by the higher levels (i.e. console & cli). Tracked by AS7-3694
--
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
11 years, 9 months
[JBoss JIRA] (AS7-6955) Support Bundle deploy/undeploy from management operation
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-6955:
-----------------------------------
Summary: Support Bundle deploy/undeploy from management operation
Key: AS7-6955
URL: https://issues.jboss.org/browse/AS7-6955
Project: Application Server 7
Issue Type: Sub-task
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 9.0.0.CR1
There is a requirement that a bundle can install/uninstall other bundles during start/stop. We support auto start/stop for bundle deployments and explicit start/stop as management operations.
In both cases this would trigger a management operation (i.e. deploy/undeploy) from within the another management operation, which currently not supported.
--
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
11 years, 9 months
[JBoss JIRA] (AS7-6951) EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-6951?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-6951:
-----------------------------------
That's just a DEBUG level logging and nothing serious. Of course, it's probably a good idea to not dump a stacktrace at all. But that's something that the Narayana project needs to decide. I'll move this JIRA to that project.
> EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
> --------------------------------------------------------------------------------------
>
> Key: AS7-6951
> URL: https://issues.jboss.org/browse/AS7-6951
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Darryl Miles
> Assignee: Jason Greene
>
> When enabling additional logging to system DEBUG on startup of standalone-full.xml it is possible to see:
> 07:15:40,780 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to lookup: java:/TransactionManager: javax.naming.NameNotFoundException: Error looking up TransactionManager, service service jboss.naming.context.java.TransactionManager is not started
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:132) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:80) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.tryJNDI(TransactionManagerLocator.java:150) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:131) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 07:15:40,786 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to instantiate legacy transaction manager: java.lang.ClassNotFoundException: org.jboss.tm.TxManager from [Module "org.jboss.jboss-transaction-spi:main" from local module loader @634f6b14 (finder: local module finder @72ff20fb (roots: F:\Devel\deps\jboss-eap-6.1\modules,F:\Devel\deps\jboss-eap-6.1\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.2.0.CR1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_17]
> at java.lang.Class.forName(Class.java:188) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.usePrivateAPI(TransactionManagerLocator.java:172) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:133) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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
11 years, 9 months
[JBoss JIRA] (AS7-6954) Complete support for Bundle update
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-6954:
-----------------------------------
Summary: Complete support for Bundle update
Key: AS7-6954
URL: https://issues.jboss.org/browse/AS7-6954
Project: Application Server 7
Issue Type: Sub-task
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
A Bundle can have multiple revisions. A call to Bundle.update(…) creates a new revision. There is only ever one current revision (the latest update) associated with a Bundle. Stale revisions continue to exist in the runtime until an explicit refresh of the transitive dependency graph.
Approach #1 - bundle revisions are represented as individual deployments
Each bundle update deploys the revision as a new deployment
The association of revisions to bundle happens in the OSGi layer only
Management sees disconnected deployments with no notion of stale/current or belonging together
Approach #2 - deployment API supports the notion of multiple revisions
deployments, their revisions and respective mapping would be modelled more closely on OSGi requirements
some deployment types might not support revisions
--
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
11 years, 9 months