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
