On Fri, Aug 15, 2008 at 11:39 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > On Fri, Aug 15, 2008 at 6:49 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> 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 > > Is there a good reason we need to do this? If not then i don't think we > should. > > Backward compatibility is really important, this is an API we've been using > in all the samples and telling users to use since the 0.90 release so we > need a _really_ good reason to break it as is being done in (2), and even > for (1) i think its an unnecessary risk as there will be differences in the > impl which will likely break things for users in some scenarios. > > To be safe wouldn't it be better to just deprecate the SCADomain class and > change all our samples and tests to use the new Node2 APIs? If we don't > think the Node2 APIs are as easy to use as the SCADomain we should fix that. > I know thats a little more work but i'll help by volunteering to make all > the test and sample changes. > > ...ant > > >
I thought the changes from Raymond were making SCADomain to internally use Node apis, and that should maintain compatibility. Looking at changes in revision #r686391 I didn't see any sample changes. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
