Multiple phase deployments

[thomas.diesler]

Related to JBAS-8517

In OSGi a set of bundles is (hot-) deployed in two phases.

#1 Bundles are installed into the Framework

#2 Bundes are started

After #1 a bundle is in state INSTALLED, the Framework is free to transition the bundle to state RESOLVED at any time. This can explicitly be triggered via PackageAdmin or implicitly by a class loading operation on Bundle.loadClass(String). Bundle.start() transitions the bundle from INSTALLED to RESOLVED to ACTIVE.

Given a set of bundles, it is important that all of them are INSTALLED (without getting started). The expected hot-deploy semantics is however that after the set of bundles got installed an attempt is made to start them.

In AS6 I worked arround that by wrapping the AS Deployers (see JBDEPLOY-214)

In AS7 I would need a notion of post deployment processing hook, that allows me to query the set of successful deployments (i.e. DeploymentServices) so that I can do processing step #2

Currently I work around that by collecting the deployments in a ThreadLocal

[brian.stansberry]

This sounds like something that should be handled by the deployers and the services they install. I.e. the #1 work is encapsulated in one or more services and the deployer attaches a listener to that service's ServiceController. When all services are started, a second set of services that handles #2 is started.

It's possible to register a deployment with the server without starting it. But that's not what you are looking for; all that does is make the deployment content known to server and get it copied into the deployment repository; "starting" it means actually deploying it. You're looking for more of a 2 step deployment notion.

[dmlloyd]

If service lifecycle needs to be manually controlled, then you can have a service for each phase which is manually controlled to "NEVER" at first and then set to "IMMEDIATE" as each part becomes active.

Basically any time a service should be manually controlled, toggle the mode to do so.  Any time you have a multi-phase start sequence you should use a separate service for each phase.

[thomas.diesler]

(12:26:09 AM) bstansberry: what identifies a "set of bundles" ?
(12:26:31 AM) tdiesler: I guess the ones that are part of the plan
(12:26:47 AM) tdiesler: which might be flawed to start of with ;-)
(12:27:34 AM) tdiesler: given that the scan can chop the physical set that the user hot-deploys in multiple scans hence multiple plans
(12:27:53 AM) bstansberry: true
(12:28:16 AM) bstansberry: plus it seems like what you want is more of a package notion like a sar or war
(12:28:34 AM) bstansberry: even if it was virtual -- something that deployers could treat as a unit
(12:28:41 AM) tdiesler: lets assume the set is the plan
(12:29:31 AM) bstansberry: still the DeploymentPlan etc is an external client API
(12:29:55 AM) tdiesler: in practice a user would drop a set of bundles in /deployments lets assume they all end up in a plan
(12:30:06 AM) bstansberry: ok
(12:30:10 AM) tdiesler: so my DUProcessors see a set of those DUCs
(12:31:03 AM) tdiesler: my workaround relies on ThreadLocal http://github.com/jbosgi/jboss-as/blob/d853975467b33a836ac77a0f9e22976ac5bfa836/osgi/src/main/java/org/jboss/as/osgi/deployment/OSGiDeploymentService.java
(12:31:12 AM) tdiesler: but shows the idea
(12:32:42 AM) bstansberry: so what you're looking for is a way to associate a set of deployments with each other
(12:33:00 AM) tdiesler: yes
(12:33:02 AM) ***bstansberry looks at where the TL is cleared
(12:36:19 AM) bstansberry: hmm, so this depends on all the deployments being installed in a batch
(12:36:51 AM) bstansberry: which is how it works now but is fragile

(12:37:32 AM) bstansberry: so some other mechanism to know that the deployments are part of a set is better
(12:37:54 AM) tdiesler: yes, the TL counts them up when the services are created and down when they got installed/failed. If there are no more pending it starts the installed deployments
(12:40:15 AM) tdiesler: yes, if I had access to the notion of DeploymentSet I could associate lifecycle with the set
(12:41:29 AM) tdiesler: some other form of SetContext.start/SetContext.end would also do
(12:42:48 AM) bstansberry: I'll think about how the DeploymentSet could be managed. The ServerDeploymentManager knows there is a plan, so could associate a DeploymentSet with each individual update.
(12:43:00 AM) bstansberry: and the set could be attached to the DeploymentUnitContext
(12:43:09 AM) tdiesler: right on
(12:44:00 AM) bstansberry: but something would need to trigger the fact that all the updates in the set have been processed
(12:44:06 AM) tdiesler: I would need to be able to associate state with the set
(12:44:15 AM) tdiesler: perhaps attach stuff to it
(12:44:17 AM) bstansberry: ok
(12:45:12 AM) tdiesler: callback on the set?
(12:45:44 AM) bstansberry: yeah
(12:45:57 AM) tdiesler: merci (f)

[brian.stansberry]

Been chatting a bit with Thomas. The part that wasn't clear to me is that the "set of bundles" he describes is really a number of independent deployment units. Any DeploymentUnitProcessor would see each deployment unit as an independent thing. He was seeing a DeploymentPlan as a way of processing them as a unit.

Currently, all the deployments in a plan are installed as part of the same batch. So his ThreadLocal approach lets him use a TL to detect and count up all the deployments in a batch, and then use a listener on each service to track when they are all started, moving on to his #2 step at that point.

We talked about instead adding a notion of a DeploymentSet. All updates associated with a DeploymentPlan would be associated with the same DeploymentSet. The DeploymentSet could be attached to the DeploymentUnitContext for each deployment, and a callback triggered when the update for each deployment in the set has been applied.

This is similar to some things that would happen with ear deployments; it's just that instead of using packaging to determine what comprises a set of deployments, we'd be using the fact that they are in the same DeploymentPlan.

This can use some further digestion, but it's intriguing.

[bosschaert]

Brian Stansberry wrote:

(12:28:16 AM) bstansberry: plus it seems like what you want is more of a package notion like a sar or war

Just as a side note, the notion of an OSGi 'ear' (it will most likely have the extension .eba - Enterprise Bundle Archive) is currently being standardized in the OSGi Alliance in RFC 152. Until then, we'd have to live with a bunch of bundles in the deployment folder which together happen to be a possibly coherent set.