You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2007/05/04 17:17:03 UTC
SCARuntimeActivator and multiple .composite files
I've a problem using SCARuntimeActivator with implementation-script tests as
it fails saying there are components with duplicate names. This looks like
its because there are multiple .composite files for all the various
testcases which do use the same component names and they're all getting
found and used even though the SCARuntimeActivator start method takes a
composite name. How should this work? Should all the .composite files get
used (so why does SCARuntimeActivator.start need a composite name?) Should
it be possible to do unit tests like the script impl does with lots of
individual .composite files?
See
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/test/resources/org/apache/tuscany/sca/implementation/script/itests/
...ant
Re: SCARuntimeActivator and multiple .composite files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Some comments inline.
Raymond Feng wrote:
> Hi,
>
> With SCARuntimeActivator, we use the contribution service to discover
> all the composites in the "default contribution" which is the
> jar/folder that contains the composite path from the start() method.
> If there is META-INF/contribution-metadata.xml that lists the
> deployable composites, then only the deployables will be actiavated.
> Othwerwise, all the composites will be treated as deployables and
> added to the SCA domain. When a composite is activated, it's included
> in the SCA domain composite and top-level components cannot have
> duplicate names.
>
> The composite passed to the start() method is really a workaround to
> discover the root of the default contribution. Maybe we should use it
> as the deployable in case that no META-INF/contribution-metadata.xml
> is present.
Yes, that makes sense to me.
... but (unless I mis-understood) it's going to help at the very top
level but still won't solve all Ant's problem with composites containing
duplicate contents in his Maven module. If a composite A references a
composite B, by name (since this is how it works now in SCA 1.0), and
you have two files declaring a composite B in your Maven module, we
really have no way to distinguish between the two, and it's not a
technical limitation, it's a characteristic of the programming and
packaging model. The list of deployables is not going to help here as it
only lists the top level composites.
So my recommendation would be: handle these composites like you would
handle Java classes: don't use duplicate composite qnames in a single
contribution / project / Maven module.
And handle deployable composites like you would handle C# partial
classes: don't use duplicate component names in the composites you're
using as deployables and including in a single domain.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "ant elder" <an...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, May 04, 2007 8:17 AM
> Subject: SCARuntimeActivator and multiple .composite files
>
>
>> I've a problem using SCARuntimeActivator with implementation-script
>> tests as
>> it fails saying there are components with duplicate names. This looks
>> like
>> its because there are multiple .composite files for all the various
>> testcases which do use the same component names and they're all getting
>> found and used even though the SCARuntimeActivator start method takes a
>> composite name. How should this work? Should all the .composite files
>> get
>> used (so why does SCARuntimeActivator.start need a composite name?)
>> Should
>> it be possible to do unit tests like the script impl does with lots of
>> individual .composite files?
>>
>> See
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/test/resources/org/apache/tuscany/sca/implementation/script/itests/
>>
>>
>> ...ant
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCARuntimeActivator and multiple .composite files
Posted by Raymond Feng <en...@gmail.com>.
Hi,
With SCARuntimeActivator, we use the contribution service to discover all
the composites in the "default contribution" which is the jar/folder that
contains the composite path from the start() method. If there is
META-INF/contribution-metadata.xml that lists the deployable composites,
then only the deployables will be actiavated. Othwerwise, all the composites
will be treated as deployables and added to the SCA domain. When a composite
is activated, it's included in the SCA domain composite and top-level
components cannot have duplicate names.
The composite passed to the start() method is really a workaround to
discover the root of the default contribution. Maybe we should use it as the
deployable in case that no META-INF/contribution-metadata.xml is present.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, May 04, 2007 8:17 AM
Subject: SCARuntimeActivator and multiple .composite files
> I've a problem using SCARuntimeActivator with implementation-script tests
> as
> it fails saying there are components with duplicate names. This looks like
> its because there are multiple .composite files for all the various
> testcases which do use the same component names and they're all getting
> found and used even though the SCARuntimeActivator start method takes a
> composite name. How should this work? Should all the .composite files get
> used (so why does SCARuntimeActivator.start need a composite name?)
> Should
> it be possible to do unit tests like the script impl does with lots of
> individual .composite files?
>
> See
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/test/resources/org/apache/tuscany/sca/implementation/script/itests/
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org