Simon Laws 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.
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
Case 3 is a convenience method for use by samples and itests. The
composite file may either be part of the current module and picked up
from the target/classes directory, or it may be part of some other
module that's listed in the pom.xml dependencies of the current module,
and picked up from a jar file in a local or remote maven repo. The
findContributionFromResource() method allows these two cases to be
treated the same by the sample writer.
If we change the samples and tests so that they identify contributions
rather than composite files, I think we would also need to change the
build process to package contributions in a uniform way (probably as
jar files), so that case 3 could use a replacement convenience API
that refers explicitly to contributions rather than to composite files.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
