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