Simon,
On 1/11/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > 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. Yes, it will be good if the code can be changed, but since many of the samples and tests find their contributions based on the composites/sca- contribution.xml, I am not sure if it is feasible to get rid of it altogether after it has been around for so long. > > > 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 When Tuscany is running under OSGi, we will require these contributions to be installed into OSGi. I dont know the code well enough to understand how these contributions are used/loaded/resolved etc. But yes, it will be good to stop manipulating URLs to locate contributions. . > Simon > Thank you... Regards, Rajini
