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).
??