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.