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

[Greg Dritschler <gr...@gmail.com>]

I have a test case with 2 contributions.
Contribution A contains deployable composite C1, and exports the namespace
of C1.
Contribution B contains deployable composite C2, and imports the namespace
of C1.
C2 contains a component which uses C1 as its implementation.

First I'll admit this is a strange test.  I think it's unlikely that
something that's designed to be reused by other deployable composites is
likely to be deployed by itself as well.  Nevertheless I'm not aware that
this is prohibited.

This test fails with message
SEVERE: [ASM90005] The SCA binding Helloworld on component
HelloServiceComponent service Helloworld should not have a URI and the URI
is currently set to /HelloServiceComponent/Helloworld

Here is what is happening:
1) Contribution A is built.  BindingURIBuilderImpl computes and sets the
binding uri in its component services.
2) Contribution B is built.  ComponentBuilderImpl processes C1 again, sees
the binding uri is set, and issues the
error because binding.sca does not permit external specification of @uri.

So the code is confusing a runtime update to the model for an external
error.
This may be the tip of the iceberg of what could go wrong.  C1 is deployed
and could be active.
If subsequent contributions are going to reprocess C1, a lot of care needs
to be taken to not modify the model in a way that breaks active operations.
 It looks to me like the builder code thinks it has free reign to rebuild
C1.

Greg

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

[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

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

[Greg Dritschler <gr...@gmail.com>]

I opened JIRA TUSCANY-3907 and attached test case.

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

[Simon Nash <na...@apache.org>]

Greg Dritschler wrote:
> I have a test case with 2 contributions.
> Contribution A contains deployable composite C1, and exports the 
> namespace of C1.
> Contribution B contains deployable composite C2, and imports the 
> namespace of C1.
> C2 contains a component which uses C1 as its implementation.
> 
> First I'll admit this is a strange test.  I think it's unlikely that 
> something that's designed to be reused by other deployable composites is 
> likely to be deployed by itself as well.  Nevertheless I'm not aware 
> that this is prohibited.
> 
I think this is a valid use of composites and should be supported.

> This test fails with message
> SEVERE: [ASM90005] The SCA binding Helloworld on component 
> HelloServiceComponent service Helloworld should not have a URI and the 
> URI is currently set to /HelloServiceComponent/Helloworld
> 
> Here is what is happening:
> 1) Contribution A is built.  BindingURIBuilderImpl computes and sets the 
> binding uri in its component services.
> 2) Contribution B is built.  ComponentBuilderImpl processes C1 again, 
> sees the binding uri is set, and issues the
> error because binding.sca does not permit external specification of @uri.
> 
> So the code is confusing a runtime update to the model for an external 
> error.
> This may be the tip of the iceberg of what could go wrong.  C1 is 
> deployed and could be active.
> If subsequent contributions are going to reprocess C1, a lot of care 
> needs to be taken to not modify the model in a way that breaks active 
> operations.  It looks to me like the builder code thinks it has free 
> reign to rebuild C1.
> 
+1 on the general principle of "do no harm".  For this specific case,
perhaps BindingURIBuilderImpl could add a Tuscany-specific attribute
instead of the SCA @uri attribute.  The presence of this attribute
wouldn't be flagged as an error by ComponentBuilderImpl.

   Simon

> Greg