\
My understanding of the init levels is that it's scope of
influence is for components in a composite.
Yes that's correct and if you have dependencies across modules,
it's not going to help. What we need is for the dependency thingy
Meeraj and Jeremy were working on to resolve out transitive
dependencies and load the extensions accordingly. I'm not sure
where that is at currently.
Transitive dependencies are not going to address this - they are
for the location of resources (e.g, classpath).
One change may be to the way we do deployment. Currently for
convenience when you deploy a component we also start it
automatically. When we scan for extensions we deploy/start them as
we find them.
It is probably better if we modify the deploy API so that it does
not automatically start the component. That way the scanner can
deploy all the extensions first and then go back and start them
all. That would mean that any inter-component references would
resolve appropriately.
If the system services are in separate composites (as opposed to
included) I don't think that is going to solve it either since system
services aren't proxied so we can't lazy instantiate a reference. If
one extension requires another extension, we need to figure out the
start order, which involves calculating transitive dependencies. In
this case we also need to deal with visibility of interfaces across
classloaders. If they are included in one composite then I agree but
I was under the assumption that they were not being included. In any
event, I think we should revisit the deployment API, particularly if
we want to deploy multiple things as a "unit of work".
The first case is sounding a lot like OSGi ;-)
Jim
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
