Hi Rajini
> But the code that I have run into problems with are in > > > org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource > (ClassLoader > classLoader, String compositeString) > > which only works with file:// or jar:// URLs (it is very similar to the > code > used by the old DefaultSCADomain). I've always been skeptical about this method. It was included as a convenience to allow the location of a contribution to be determined from some well know file, for example, the composite file that is being tested. Handy for testing but it seems back to front to me. As a user you either have a contribution or you don't. Seems a strange thing to ask a runtime to find a contribution based on what is known to be inside it. > > This method is invoked from > > 1. SCADomainImpl to find the folder/jar containing domain.composite > 2. SCADomainProxyImpl to find the folder/jar containing node.composite > 3. SCANodeFactory.createNodeWithComposite(String composite) > 4. SCANodeLauncher.main() > > 1) and 2) in particular need to be fixed properly since they are internal > to > Tuscany and it doesn't seem appropriate to expect applications to > override resource loading for the Tuscany runtime when Tuscany is > installed > into OSGi. For 1 and 2 I'm sure we can find a better solution that using this method, for example, some alternatives Have the runtime implementations that Ant is thinking about specify a well know location for these system contributions Have the assemblies for these contributions generated programatically rather than read from the file system . Simon
