I think we need to be careful of the distinction between resource
loading and artifact loading.
At the top level here we are specifying how the primordial SCDL
artifact will be loaded - we are defining that it is a resource in
WEB-INF and so using a (ServletContext based) resource loader to load
it is OK.
However, that SCDL will contain references to other artifacts that
may not be resources that are part of the webapp or which may not
even be physical resources at all.
Right, understand the resource/artifact distinction here -- my problem
was that I had been under the impression that the classloader injected
onto the module implementation was used to load the SCDL (and actually
added a comment to that effect.. oops), and so was worried that by
using a different mechanism at the top-level for a SCDL file would run
into problems when it hit includes. As I grovel through the code I
see that SCDL file references are tracked via URLs and included SCDLs
have their URL built relative to a parent URL, so the module impl's
injected classloader is a red herring.
Working on understanding the deployment code; here's a snippet that's
unclear to me:
In DeployerImpl.deploy(CompositeComponent<?> parent,
CompositeDefinition<I> componentDefinition) :
DeploymentContext deploymentContext = new RootDeploymentContext(null,
xmlFactory, moduleScope, null)
For the case where componentDefinition.getImplementation() is an
instance of SystemCompositeImplementation, shouldn't the SCDL URL be
passed into the RootDeploymentContext? (as opposed to null)
There are certain types of artifact that we know that we will need to
deal with because they are referenced by the SCA specifications (e.g
Java classes, WSDLs) ; there are other types that will be contributed
as part of Tuscany extensions (e.g. Groovy scripts).
I think some form of artifact repository will be needed but we should
work out the form and the API implementations can use to access it.
I've hinted before at possibly basing something on Maven's repository
and would be curious what people think.
I hope to have some thoughts on this later when I free up some brain cycles :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
