Simon Laws wrote:
Having looked at Kelvin's new asynch sample it seems that the sample
launcher I made a little while back which takes a parameter and
decides what to launch adds to the complexity rather than reduces it.
I'm going to try adding separate launchers for each of the tests
inside the existing launcher directories. I'll do it in parallel with
what is already there to see how it looks.
Simon
On Tue, Jul 13, 2010 at 11:24 AM, Simon Laws <[email protected]> wrote:
On Mon, Jul 12, 2010 at 10:30 AM, kelvin goodson
<[email protected]> wrote:
Has anyone seen this issue where on reading a jar file contribution
the path to an element within the jar file seems to be constructed in
the format of a windows network path? The problem occurs when
attempting to try to get a composite from the jar file. The jar file
itself has been successfully resolved, and a number of its contents
already processed. .The path is not a valid network path since it
uses the C drive letter in the place where a host name would be
expected.
Kelvin.
2-Jul-2010 09:20:37 org.apache.tuscany.sca.node.impl.NodeImpl start
INFO: Starting node: http://tuscany.apache.org/sca/1.1/nodes/default0
domain: default
12-Jul-2010 09:20:37 org.apache.tuscany.sca.node.impl.NodeFactoryImpl
loadContributions
INFO: Loading contribution:
file://C:/Dev7/SCA/samples/my-contribution/target/my-sample-contribution-implementation-java-calculator.jar
12-Jul-2010 09:20:52
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor
[Contribution: c1, Artifact: CalculatorClient.composite]
(ContributionReadException)
SEVERE: ContributionReadException occured due to : {0}
org.apache.tuscany.sca.contribution.processor.ContributionReadException:
Exception reading CalculatorClient.composite
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:83)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProcessorExtensionPoint$LazyURLArtifactProcessor.read(DefaultURLArtifactProcessorExtensionPoint.java:288)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:109)
at
org.apache.tuscany.sca.contribution.processor.impl.ContributionContentProcessor.read(ContributionContentProcessor.java:152)
at
org.apache.tuscany.sca.contribution.processor.impl.ContributionContentProcessor.read(ContributionContentProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProcessorExtensionPoint$LazyURLArtifactProcessor.read(DefaultURLArtifactProcessorExtensionPoint.java:288)
at
org.apache.tuscany.sca.deployment.impl.DeployerImpl.loadContribution(DeployerImpl.java:694)
at
org.apache.tuscany.sca.node.impl.NodeFactoryImpl.loadContributions(NodeFactoryImpl.java:394)
at org.apache.tuscany.sca.node.impl.NodeImpl.start(NodeImpl.java:125)
at launcher.RuntimeIntegration.startNode(RuntimeIntegration.java:35)
at
launcher.SampleJSELauncher.launchBindingSCACalculator(SampleJSELauncher.java:79)
at launcher.SampleJSELauncher.main(SampleJSELauncher.java:51)
Caused by: java.io.FileNotFoundException:
\\C\Dev7\SCA\samples\my-contribution\target\my-sample-contribution-implementation-java-calculator.jar
(The network path was not found)
Hi Kelvin
I just tried the sample now you've added it to the contrib directory.
I didn't see this specific error but a fixed a few other things to
make the test run in my environment. Be interested to hear if you're
still seeing the problem above and also if the changes I made make
sense to you. Let me know.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Folks,
The way I tackled this function in the case of the OASIS testcases is to have a small number of
launcher programs - I started with one, but created a couple more when I needed a more sophisticated
client for callback tests.
Each testcase then differs mainly by providing different parameters for the
launcher.
In the OASIS tests, I provided the parameters using Java classes to hold the config, each being a
subclass of the main launch class. Clearly, this could have been done with command line parameters
or with separate text/XML files, but it worked out much easier in this case to encapsulate
everything in a class that could then be run as a JUnit test (if required). The idea here is
keeping things as simple as possible for the end-user.
I think that different launchers are appropriate for different kinds of
application.
I can envisage a very simple launcher when dealing with a single composite and a single node - and
making assumptions such as the contribution IS the directory which contains the composite - so no
need to name any contributions.
One you get into multiple nodes, distributed runtimes, multiple contributions and all the wonderful
stuff that SCA can do, then something more sophisticated is probably required. However, I don't see
the point of trying to cover all cases - simple and complex - with one launcher.
What's wrong with multiple launchers each appropriate to certain use cases?
Of course, under the covers, the launchers should be using common interfaces - duplication there is
undesirable. Different kinds of runtime should be handled through SPIs that provide different
implementations of eg. Contribution container, Runtime Domain container, etc.
Yours, Mike.
