You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Greg Dritschler <gr...@gmail.com> on 2011/08/02 16:23:27 UTC

Re: Problem installing one deployable that uses another deployable's component as an implementation

I opened JIRA TUSCANY-3907 and attached test case.

Re: Problem installing one deployable that uses another deployable's component as an implementation

Posted by Simon Laws <si...@googlemail.com>.
On Tue, Aug 2, 2011 at 3:23 PM, Greg Dritschler
<gr...@gmail.com> wrote:
> I opened JIRA TUSCANY-3907 and attached test case.


So when we reference a composite as an component implementation we
clone the referenced (and already resolved) composite model at the
start of the build phase. However we don't clone the top level
composite models that are added to the domain composite. The version
of the composite model that is build is the same version that is
referenced by the CompositeModelResolver for the contribution in
question. Hence, with the scenario stated, the effect you will see
after loading the contributions is:

1) start C2 followed by start C1 will probably work because the clone
of C1 is done before C1 itself is build at the top level
2) start C1 followed by start C2 will fail for the reasons already stated

I have a local change where the top level composites are cloned as
they are added to the domain composite (in the same way that
implementation composites are cloned before the are build as part of
the component implementation). This means that the
CompositeModelResolver retains a reference to a resolved but unbuilt
model. Am testing it now.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com