You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2010/07/13 12:38:56 UTC
A bit more sample launcher tidying - was: Re: jar file contrbution
read complains about network path not found
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 <si...@googlemail.com> wrote:
> On Mon, Jul 12, 2010 at 10:30 AM, kelvin goodson
> <ke...@apache.org> 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
>
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: A bit more sample launcher tidying - was: Re: jar file
contrbution read complains about network path not found
Posted by ant elder <an...@gmail.com>.
Do we even really need a separate launcher for each sample, can't we
have a single generic launcher that can use arbitrary
contributions/composites?
...ant
On Tue, Jul 13, 2010 at 11:38 AM, Simon Laws <si...@googlemail.com> 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 <si...@googlemail.com> wrote:
>> On Mon, Jul 12, 2010 at 10:30 AM, kelvin goodson
>> <ke...@apache.org> 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
>>
>
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: A bit more sample launcher tidying - was: Re: jar file
contrbution read complains about network path not found
Posted by Simon Laws <si...@googlemail.com>.
>
> I'll have a go at making both styles and we can see which we like best
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
OK I added an example of a specific launcher at r964782. This
exercises the embedded node api in a single class. I didn't do the
generic version as looking at the code I realize that the existing
launcher does a number of different things depending on the
contribution. It would be appropriate to have a separate launcher
sample I think if someone wants to demonstrate to the user how to
build a generic launcher using the enbedded node api but that's still
different from what's going on here IMHO.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: A bit more sample launcher tidying - was: Re: jar file
contrbution read complains about network path not found
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Jul 14, 2010 at 12:47 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>> What's wrong with multiple launchers each appropriate to certain use cases?
>>>
>>
>> Nothing, i didn't mean to imply there should just be one single one i
>> was commenting that having a launcher per sample didn't seem perfect.
>> So i agree with what you've just been suggesting. I do think once we
>> have some of these done how we like then we should look at what of the
>> code really should be in samples/ or if some of it could be moved to
>> be part of the Tuscany modules function.
>>
>> ...ant
>>
>
> For some of the samples we've separated the launchers from the contributions.
>
> Because of this we are able to offer a variety of launchers for the
> contributions, for example,
>
> launcher-command-line
> launcher-shell
> launcher-maven
> launcher-embedded-jse
> launcher-embedded-osgi
> etc
>
> Each of these demonstrate to the user a different way of launching a
> contribution(s). Remember that these are samples so the objective is
> not necessarily to provide the most expedient way of implementing the
> code but is rather to provide the clearest of demonstrations to the
> user of how to lauch contributions using Tuscany.
>
> I wasn't very clear in my original comment. What I was referring to
> specifically was the current launcher-embedded-jse and
> launcher-embedded-osgi solution where I originally provided a
> parameterized launcher for starting different contributions. On
> reflection I don't think this passes the test of being as clear to the
> user as we could be. I would prefer to offer a selection of examples
> demonstrating the launching different contributions in an embedded
> environment. Hence I'm suggesting creating separate launchers inside
> these embedded directories instead of a single parameterized launcher.
>
> Now I hear the shouts of let's have a single launcher. We already have
> several examples of that. See launcher-command-line and laucher-shell
> for example. If we build a generic launcher to demonstrate use of the
> embedding APIs I fear that would demonstrate to the user how smart we
> are at building a generic launcher rather than demonstrating how to
> use the API. This is what motivated my original comment, i.e. I think
> I've included more code to handle the parameterization, which is of no
> interest to the user, rather than focusing on use the embedding API to
> load and start a contribution.
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
I'll have a go at making both styles and we can see which we like best
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: A bit more sample launcher tidying - was: Re: jar file
contrbution read complains about network path not found
Posted by Simon Laws <si...@googlemail.com>.
>>
>> What's wrong with multiple launchers each appropriate to certain use cases?
>>
>
> Nothing, i didn't mean to imply there should just be one single one i
> was commenting that having a launcher per sample didn't seem perfect.
> So i agree with what you've just been suggesting. I do think once we
> have some of these done how we like then we should look at what of the
> code really should be in samples/ or if some of it could be moved to
> be part of the Tuscany modules function.
>
> ...ant
>
For some of the samples we've separated the launchers from the contributions.
Because of this we are able to offer a variety of launchers for the
contributions, for example,
launcher-command-line
launcher-shell
launcher-maven
launcher-embedded-jse
launcher-embedded-osgi
etc
Each of these demonstrate to the user a different way of launching a
contribution(s). Remember that these are samples so the objective is
not necessarily to provide the most expedient way of implementing the
code but is rather to provide the clearest of demonstrations to the
user of how to lauch contributions using Tuscany.
I wasn't very clear in my original comment. What I was referring to
specifically was the current launcher-embedded-jse and
launcher-embedded-osgi solution where I originally provided a
parameterized launcher for starting different contributions. On
reflection I don't think this passes the test of being as clear to the
user as we could be. I would prefer to offer a selection of examples
demonstrating the launching different contributions in an embedded
environment. Hence I'm suggesting creating separate launchers inside
these embedded directories instead of a single parameterized launcher.
Now I hear the shouts of let's have a single launcher. We already have
several examples of that. See launcher-command-line and laucher-shell
for example. If we build a generic launcher to demonstrate use of the
embedding APIs I fear that would demonstrate to the user how smart we
are at building a generic launcher rather than demonstrating how to
use the API. This is what motivated my original comment, i.e. I think
I've included more code to handle the parameterization, which is of no
interest to the user, rather than focusing on use the embedding API to
load and start a contribution.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: A bit more sample launcher tidying - was: Re: jar file
contrbution read complains about network path not found
Posted by ant elder <an...@gmail.com>.
On Wed, Jul 14, 2010 at 11:07 AM, Mike Edwards
<mi...@gmail.com> wrote:
> 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 <si...@googlemail.com>
>> wrote:
>>>
>>> On Mon, Jul 12, 2010 at 10:30 AM, kelvin goodson
>>> <ke...@apache.org> 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?
>
Nothing, i didn't mean to imply there should just be one single one i
was commenting that having a launcher per sample didn't seem perfect.
So i agree with what you've just been suggesting. I do think once we
have some of these done how we like then we should look at what of the
code really should be in samples/ or if some of it could be moved to
be part of the Tuscany modules function.
...ant
Re: A bit more sample launcher tidying - was: Re: jar file contrbution
read complains about network path not found
Posted by Mike Edwards <mi...@gmail.com>.
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 <si...@googlemail.com> wrote:
>> On Mon, Jul 12, 2010 at 10:30 AM, kelvin goodson
>> <ke...@apache.org> 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.