On Thu, Aug 21, 2008 at 8:30 AM, ant elder <[EMAIL PROTECTED]> wrote:
> I still have some problems with this change and the samples when running in > WebSphere. Its a bit intermittent but generally I get a class verify error, > sometimes that will go away on a WAS restart and everything works fine, but > then it comes back again later on some subsequent restarts. Changing the > impl back to the old SCADomain code and it always seems to work fine. To > recreate build the calc-ws-sample with the latest trunk code and try > deploying and running in WebSphere. I get a similar problem with using the > Node2 APIs in the 1.3 code as mentioned at : > http://apache.markmail.org/message/a4jy2hvku3uuvj46 > > org.osoa.sca.ServiceRuntimeException: java.lang.VerifyError > >> at > org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:189) > > ...ant > > > On Mon, Aug 18, 2008 at 11:14 PM, Raymond Feng <[EMAIL PROTECTED]>wrote: > >> FYI, the regression has been fixed under r686861. For some reason, the >> "demos" folder is not on the main build by default and the webapp test >> failure had skipped out of my build before the original commit. >> >> Thanks, >> Raymond >> -------------------------------------------------- >> From: "Dan Becker" <[EMAIL PROTECTED]> >> Sent: Monday, August 18, 2008 2:09 PM >> >> To: <[email protected]> >> Subject: Re: Port the DefaultSCADomain implementation to use >> tuscany-node2-impl >> >> Since you are fixing any build and web app regressions, in my view I >>> think that adds a few more coins to your side of the scale. I am happy to >>> support your solution given this. >>> >>> Raymond Feng wrote: >>> >>>> >>>> 1) Keep the SCADomain impl as-is won't help the compatibility at all. >>>> The impl class has many dependencies to other classes in the code base, any >>>> change in the trunk will have the possibility to change the behaviors. The >>>> only criteria of "No Regression" in Tuscany we have so far is to make sure >>>> the build is successful with all the tests passing. Swapping or Keeping the >>>> impl of the DefaultSCADomain class won't make a difference here for the >>>> compatibility perspective. >>>> >>>> 2) When we start to deprecate SCADomain, we still have to ensure the >>>> functionality of the SCADomain API won't be broken. If we switch all the >>>> samples and test cases to the SCANode APIs, then no tests will execute the >>>> SCADomain path. This is risky. >>>> >>>> BTW, I'm fixing the webapp regression and will check in the fix as soon >>>> as the build is complete. >>>> >>>> Thanks, >>>> Raymond >>>> >>>> From: ant elder >>>> Sent: Monday, August 18, 2008 6:11 AM >>>> To: [email protected] >>>> Subject: Re: Port the DefaultSCADomain implementation to use >>>> tuscany-node2-impl >>>> >>>> >>>> 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 >>> >> >> > Sorry I'm coming late to this party... I'd like to make a proposal as an alternative to Raymond's original. 1. Mark SCADomain as deprecated 2. Move samples/demos over to Node 3. Duplicate one or two of the samples to keep testing SCADomain over the next month or so while it remains deprecated 4. Agree what we mean by deprecated and remove or port SCADomain at the point we agree is sensible. A little justification. When I first read this thread I have to admit it sounded reasonable to me. However the fun and games we've had with 1.3.1 have made me a little concerned about changing implementations under existing APIs unless we can avoid it . There is the usual rule of unintended consequences. I would rather we migrate users to new APIs/implementations in a more controlled and open way rather than change the implementation underneath them. Simon
