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]

Reply via email to