It seems to me both Ant and Raymond agree on many points.
1) Node APIs have advantages over SCADomain APIs including different
type which is a benefit for OSGI.
2) Node APIs should be favored. SCADomain APIs should be deprecated.
3) Many samples and test cases use the SCADomain APIs and should be
converted.
The disagreement seems to stem from:
1) Implement SCADomain API in terms of Node APIs to reduce sample and
test case changes now. (Raymond)
2) Implement Node APIs independently and leave SCADomain APIs as is to
reduce build and customer changes now. (Ant)
I tend to agree with the second path although it might mean more
developer work upfront. I can help with the update too. It seems that
this path will help shield existing usage and allow customers to upgrade
from deprecated SCADomain APIs when they are ready.
ant elder wrote:
But we can do all that without touching the SCADomain impl so i think it
would be better not to change it which will avoid any chance of breaking
anyone. This change has stopped webapps working now and the continuum build
is failing because of that so I'd like to put back the old impl to fix this,
if not permanently at least while this discussion continues.
What are others views on replacing the SCADomain impl? Is it worth doing or
is it safer to just leave it and just deprecate the class?
...ant
On Sat, Aug 16, 2008 at 5:48 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
There are a few reasons I did this:
1) Node APIs should be favored over SCADomain APIs as the behavior of the
Node APIs is much better aligned with the SCA specifications.
2) There are a lot of samples and testcases using the SCADomain. Swapping
the implementation is a simple way to align it with Node APIs without
breaking existing code. In fact, I just had to change one itest (where two
deployable composites have the same name) to get the full build passed.
That
gives us great confidence that this change is not more "breaking" than
other
changes by the nature of trunk.
3) The ongoing OSGi enablement will make it possible to create SCANode
instances of different types such as JSE, OSGi or JEE. SCADomain can
leverage it as well for the purpose of test automation.
4) This change can buy us some buffer to convert all the existing samples
and testcases to use Node APIs (thank you for volunteering :-). We can
start
to deprecate the SCADomain and migrate to Node APIs.
Thanks,
Raymond
From: ant elder
Sent: Saturday, August 16, 2008 12:19 AM
To: [email protected]
Subject: Re: Port the DefaultSCADomain implementation to use
tuscany-node2-impl
On Sat, Aug 16, 2008 at 8:14 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:
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.
Right and my question is why do that and risk breaking users with any
incompatibilities caused by the impl change?
If the new Node2 APIs are what we want people to use them we should change
all our sample/demo/test code to show that and deprecated the old
SCADomain
so people migrate off it to the new APIs.
...ant
--
Thanks, Dan Becker
