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.