On Sep 26, 2006, at 6:38 PM, Jim Marino wrote:
\
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.
They're a hybrid - extensions are "included" in the system composite
as components implemented by the extension's composite that are
registered as its children. So the semantic is "include" although
there is no specific <include> element.
If one extension requires another extension, we need to figure out
the start order, which involves calculating transitive dependencies.
We should be clear when speaking of transitive dependencies about
whether they are on resources (Artifacts) or components.
We do handle transitive references in the wire connection phase
(don't we?)
In this case we also need to deal with visibility of interfaces
across classloaders.
This should not be an issue here as the extensions are implementing
services defined in terms of interfaces that come from the spi module
which is in a parent classloader. I think that will be common.
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".
+1
The first case is sounding a lot like OSGi ;-)
Dunno - remember this is about service dependencies not fancy
classloading schemes :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
