Hi,
SCADomain APIs were introduced in Tuscany before we come up the Node APIs
which are more consistent with the Domain concepts in the SCA spec. Even
though we should now use the Node APIs, there are still quite a few samples
and testcases using the SCADomain API as a legacy. To better align the
behaviors of two APIs before we can finally remove the SCADomain, I'm
starting the port the DefaultSCADomain implementation to use node2-impl. The
idea is to delegate the SCADomain APIs to Node2Impl.
I run into two issues here:
1) Node2Impl assumes the deployable composite has been fully resolved by the
SCA Domain. For example, the binding URIs and policies. In the SCADomain,
CompositeDocumentProcessor tries to transform the original composite by
applying the policySets first and then load it into the Composite model
using CompositeProcessor.
I'll work around this issue in the Node2Impl (use CompositeDocumentProcessor
to load the composite file and open a JIRA to fix it later when we have a
good story to resolve the policy applications in the SCA domain first).
2) SCADomain APIs can take more than one deployable composites which Node
APIs expect only one deployable composite.
We'll only honor the first composite from SCADomain.newInstance. For a few
testcases using more than one composites, we should create a composite that
includes other composites and pass it the SCADomain API.
Thanks,
Raymond
