Hi,
The changes are checked in under r686391. I managed to create deployment
composite that includes all the composites passed from the
SCADomain.newInstance() so that the Node API only has to deal with one
deployable composite.
Thanks,
Raymond
--------------------------------------------------
From: "Raymond Feng" <[EMAIL PROTECTED]>
Sent: Friday, August 15, 2008 10:49 AM
To: "tuscany-dev" <[email protected]>
Subject: Port the DefaultSCADomain implementation to use tuscany-node2-impl
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
