[brian.stansberry]

I don't know if there needs to be a true dependency; e.g. a "DeployersCompletionService" that depends on each deployer ServiceName that gets passed to SomeAppropriateContext, and then deployments depend on that. Problem with that is you remove some minor subsystem that had a deployer, that results in DeployersCompletionService stopping, which stops every deployment. Oops.

A listener mechanism is more flexible, but if you do things concurrently we'd need to be careful about races, i.e. the deployer is started before we listen for it, so we don't get a notification. Not sure it's worth it.

Or were you thinking registerDeployers has to do the actual deployer creation, addition to chains, etc?

[dmlloyd]

Brian Stansberry wrote:

I don't know if there needs to be a true dependency; e.g. a "DeployersCompletionService" that depends on each deployer ServiceName that gets passed to SomeAppropriateContext, and then deployments depend on that. Problem with that is you remove some minor subsystem that had a deployer, that results in DeployersCompletionService stopping, which stops every deployment. Oops.

A listener mechanism is more flexible, but if you do things concurrently we'd need to be careful about races, i.e. the deployer is started before we listen for it, so we don't get a notification. Not sure it's worth it.

Or were you thinking registerDeployers has to do the actual deployer creation, addition to chains, etc?

I guess I'm not really sure.  If the deployer creation/registration is very lightweight (as it should be, since I can't imagine those things having much state if any at all), then we could have a single Deployer service which calls all subsystem registerDeployer methods on startup and it should be pretty fast (i.e. not much to be gained from making that particular part concurrent).  Then at runtime, adding/removing processors doesn't affect the runtime state of that service, so nothing gets removed unexpectedly.

I can't think of a reason that the existence or registration of the deployment unit processors would need to depend on any particular service being up.  And the services they produce would, at most, require the service to exist in the container.  Granted this would be much easier with MSC-21 but barring that, we could then require all subsystems to complete activation before processing deployments.  The problem comes in if the activation processes do stuff that takes a long time.  But really this shouldn't be the case - at activation time, they should be adding services to the container or a batch, and deployments which depend on those services should just use them in a dependency item; this should be a very fast operation.  This way deployments using a specific service just depend on that service.  Long running stuff should be services, not blocking operations.

So to summarize, registerDeployers would just do initial registration of the processor (no computation or major tasks).  The applyUpdateBootAction (this is the method which runs at startup) would just do initialization of services (also no computation or major tasks).

??

[brian.stansberry]

David Lloyd wrote:

I guess I'm not really sure.  If the deployer creation/registration is very lightweight (as it should be, since I can't imagine those things having much state if any at all), then we could have a single Deployer service which calls all subsystem registerDeployer methods on startup and it should be pretty fast (i.e. not much to be gained from making that particular part concurrent).  Then at runtime, adding/removing processors doesn't affect the runtime state of that service, so nothing gets removed unexpectedly.

Ok, so that Deployer(s) service returns from start() when all the registered deployers have completed start(). That's blocking rather than event driven though.

I can't think of a reason that the existence or registration of the deployment unit processors would need to depend on any particular service being up.

Probably not, but I think if we can avoid imposing that as an absolute requirement, it's more flexible. Absolute requirement meaning a design that makes such a thing impossible. In code reviews we can prevent silly dependencies or ones on services that take a long time to start.

David Lloyd wrote:

And the services they produce would, at most, require the service to exist in the container.  Granted this would be much easier with MSC-21 but barring that, we could then require all subsystems to complete activation before processing deployments. 

That could be a bit tricky if the deployment processors are getting added into the msc via one thread and the other services are getting added via another thread. Doable, but screw-upable. If processors and other subsystem services get added in the same batch, then it's just automatic. That means a single method though, or registerDeployers just means recording the names of the deployer services that are going to be added in applyUpdateBootAction. Just recording the names smells funny though; the AbstractSubsystemUpdate has to figure out what the deployer services are going to be in registerDeployers, and then figure it out again in applyUpdateBootAction.

Agreed that the work done in registerDeployers and in applyUpdateBootAction should be fast; it's the non-deployer service start() methods that would take time.

[emuckenhuber]

Hmm, in the end if we use MSC to add deployers as a msc service - we need a listener anyway to wait until all of them are installed? Otherwise it would be just adding the constructed deployers without any injections.

Where the latter would actually prevent people doing weird injections. However i'm not quite convinced that this makes much sense and deployers can be fully isolated from other subsystems. At least if you look at the way common EE injection is currently - where you would need something like a injection resolver (or similar) to set the correct dependencies before you install the services in a deployment. At least i would like to avoid passing "services" through the deployers attachment system.

[dmlloyd]

Emanuel Muckenhuber wrote:

Hmm, in the end if we use MSC to add deployers as a msc service - we need a listener anyway to wait until all of them are installed? Otherwise it would be just adding the constructed deployers without any injections.

Where the latter would actually prevent people doing weird injections. However i'm not quite convinced that this makes much sense and deployers can be fully isolated from other subsystems. At least if you look at the way common EE injection is currently - where you would need something like a injection resolver (or similar) to set the correct dependencies before you install the services in a deployment. At least i would like to avoid passing "services" through the deployers attachment system.

It's really hard to say for sure until we actually have some real processors to play with.  But my thinking was that the processors themselves should be pretty simple, just a simple transformation of data or mapping from data to built services, with all the logic being in the actual service.  These things should be mostly stateless without any dependency on the running system state; such things should be expressed in terms of service dependencies.

Now something like this is very easy for me to say, but we're going to have to inspect some real use cases (namely EJB and Servlet) to discover if it is a feasible approach.  And I have a feeling that its feasibility is directly tied to MSC-21/MSC-22 as well.

As a general philosophy I'm usually opposed to adding broadly-scoped functionality "just in case".  I'd like to know the actual use cases that require the feature; otherwise we're just guessing.

[emuckenhuber]

Yes, we definitely agree on not "adding broadly-scoped functionality". Where actually what i did, was likely the easiest/quickest way to implement what i wanted it to do - maybe i just shoudn't have attached that prototype though

As for the actual deployment processors - "just a simple transformation of data or mapping from data to built services, with all the logic being in the actual service" - is certainly all the deployers should do (beside setting up the deployment classloader). When mentioning common EE injection in the deployers i was referring to the resolution of @Ejb -> service dependency name, since this would be needed to create the proper service dependencies. So maybe the deployment framework should also define a formal contract for this kind of resolution?  The actual injection would be part of the service lifecycle