RE: Calling XSD2JavaGenerator from ANT
Hi, The observed behaviour is the documented behavior of Ant means there are two separate command-line arguments i.e. args.length=2 Is different from Which means there is one command-line argument of value "key1 value1". The non-recommended approach to emulate the two-argument behaviour is Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 1:51 AM To: tuscany-dev Subject: Calling XSD2JavaGenerator from ANT I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like , you actually MUST pass the arguments like two separate arguments . Is this the expected behavior ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Calling XSD2JavaGenerator from ANT
I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like , you actually MUST pass the arguments like two separate arguments . Is this the expected behavior ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
On 8/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > Hi Ole > >Here is what I tried, and all went OK > > 1.Removed .m2\repository\org\apache\tuscany > 2.svn update to revision #565235 > 3.cd %tuscany_home%\java > 4.mvn -U -fn clean install > > java version "1.5.0_12" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) > Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) > > Maven version: 2.0.5 --> If you have a higher version, I'd recommend > trying with 2.0.5 > > > [INFO] > > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 48 minutes 3 seconds > [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007 > [INFO] Final Memory: 61M/63M > [INFO] > > > > On 8/12/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: > > Hi Simon, > > > > Simon Laws wrote: > > > > > > > > I note from your other post that you are having problems with the full > build > > > with JDK1.6. Is it possible for you to try with 1.5 as this is known > to > > > work? We can then isolate JDK issues from these more general build > issues. > > > > Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and > it made it this far (I also disabled SELinux to make sure nothing funky was > happening): > > > > --- > > T E S T S > > --- > > Running supplychain.SupplyChainClientTestCase > > In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, > customer is [Proxy - f6438d] > > java.lang.ClassNotFoundException: supplychain.retailer.Retailer > > at org.apache.felix.framework.Felix.loadBundleClass(Felix.java > :1422) > > at org.apache.felix.framework.BundleImpl.loadClass( > BundleImpl.java:335) > > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService > (OSGiImplementationProvider.java:773) > > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle > (OSGiImplementationProvider.java:873) > > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle > (OSGiImplementationProvider.java:326) > > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance > (OSGiInstanceWrapper.java:70) > > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget > (OSGiTargetInvoker.java:121) > > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke > (OSGiTargetInvoker.java:172) > > at > org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke( > RuntimeSCABindingInvoker.java:41) > > at > org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke( > AbstractInvocationHandler.java:145) > > at > org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( > JDKInvocationHandler.java:75) > > at $Proxy7.purchaseGoods(Unknown Source) > > at supplychain.SupplyChainClientTestCase.test( > SupplyChainClientTestCase.java:52) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:585) > > at junit.framework.TestCase.runTest(TestCase.java:168) > > at junit.framework.TestCase.runBare(TestCase.java:134) > > at junit.framework.TestResult$1.protect(TestResult.java:110) > > at junit.framework.TestResult.runProtected(TestResult.java:128) > > at junit.framework.TestResult.run(TestResult.java:113) > > at junit.framework.TestCase.run(TestCase.java:124) > > at junit.framework.TestSuite.runTest(TestSuite.java:232) > > at junit.framework.TestSuite.run(TestSuite.java:227) > > at org.junit.internal.runners.OldTestClassRunner.run( > OldTestClassRunner.java:35) > > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( > JUnit4TestSet.java:62) > > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( > AbstractDirectoryTestSuite.java:138) > > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( > AbstractDirectoryTestSuite.java:125) > > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMet
Re: I think Tuscany needs a graph generator for composite layouts
Take a look at this post on Tuscany blog : http://apache-tuscany.blogspot.com/2007/07/sca-tooling.html Looks like the tooling project mentioned there has the ability to introspect components from your workspace, and give you a visual representation of your composite On 8/12/07, shaoguang geng <[EMAIL PROTECTED]> wrote: > as the title, when composite contents comes more and more complicated, a > layout graph generator would do greate help to developers. > > Or did some one see commercial providers of such a grapher? > > Good day. > > > - > Building a website is a piece of cake. > Yahoo! Small Business gives you all the tools to get online. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: itests: There are no tests to run
Surefire is configure to run test based on the following criteria : **/*TestCase.java The test case java file must match the criteria above, and to take a concrete example (java/sca/itest/callback-api), you can see that the test case is named as CallBackApiTest.java and will not be picked up by surefire, that's why you see the message of no tests to run : --- T E S T S --- There are no tests to run. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 On 8/12/07, venu reddy <[EMAIL PROTECTED]> wrote: > I am trying to execute itests from itest folder with mvn. Everything went > fine without any errors including the sample itest that we are trying to > write. However I have observed that, while trying to execute itests from > each itest folder, for few folders it says "There are no tests to run". What > does this mean, are those tests incomplete?, or am I missing something > here?. > Thanks, Venu. > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
Hi Ole Here is what I tried, and all went OK 1.Removed .m2\repository\org\apache\tuscany 2.svn update to revision #565235 3.cd %tuscany_home%\java 4.mvn -U -fn clean install java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Maven version: 2.0.5 --> If you have a higher version, I'd recommend trying with 2.0.5 [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 48 minutes 3 seconds [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007 [INFO] Final Memory: 61M/63M [INFO] On 8/12/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: > Hi Simon, > > Simon Laws wrote: > > > > > I note from your other post that you are having problems with the full build > > with JDK1.6. Is it possible for you to try with 1.5 as this is known to > > work? We can then isolate JDK issues from these more general build issues. > > Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it > made it this far (I also disabled SELinux to make sure nothing funky was > happening): > > --- > T E S T S > --- > Running supplychain.SupplyChainClientTestCase > In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer > is [Proxy - f6438d] > java.lang.ClassNotFoundException: supplychain.retailer.Retailer > at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1422) > at > org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:335) > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService(OSGiImplementationProvider.java:773) > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle(OSGiImplementationProvider.java:873) > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle(OSGiImplementationProvider.java:326) > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance(OSGiInstanceWrapper.java:70) > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:121) > at > org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:172) > at > org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) > at > org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:145) > at > org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:75) > at $Proxy7.purchaseGoods(Unknown Source) > at > supplychain.SupplyChainClientTestCase.test(SupplyChainClientTestCase.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:232) > at junit.framework.TestSuite.run(TestSuite.java:227) > at > org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.S
Re: Release management for next release, was: SCA 0.92 release?
Simon Laws wrote: > +1 for 21st as the target. Can I suggest we take some time (assuming there > is some) on the 20th to test the samples and check through the readmes etc > before taking the branch. We could probably get a "stable distribution" available on the 20th, and we would check that. On 8/12/07, Simon Laws <[EMAIL PROTECTED]> wrote: > On 8/9/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > I guess early the following week still leaves time for an August release. > > It will be real tight though so we'll all need to be quick and thorough > > with > > our RC reviews as one problem once we get to the IPMC voting and it could > > easily slip it into September. > > > > So does taking the branch on the 21st sound ok to everyone? > > > >...ant > > > > On 8/9/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > > > > Ant talked about cutting the branch very early next week. I'd prefer > > > that to doing it on August 18th. I will be away for a few days, > > > returning home late on the 18th, and I could take advantage of the > > > extra couple of days to help with last-minute things. > > > > > >Simon > > > > > > Venkata Krishnan wrote: > > > > > > > Hi, > > > > > > > > Theres been lots of discussion. So let me summarize my understanding > > > > / imaginiation : - > > > > > > > > - We will cut a branch around Aug 18th for Release 0.95. As always, > > > > once the branch is cut we need to be watchful on the commits > > > > (including getting the RMs nod to significant ones) to the branch and > > > > also ensure the trunk is always in sync. > > > > - Post 0.95, maybe a couple of weeks after the release, we'd cut > > > > another branch and head with that for 1.0 release. Being a 1.0 > > > > release, we prob. need a branch early as that so that we can whet the > > > > things we are targetting for the release. > > > > > > > > Is that all right ? > > > > > > > > - Venkat > > > > > > > > > > > > > > > > On 8/9/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > >>On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > >> > > > >> > > > >> > > > >>Sure, 1.0 development should happen in trunk, but I was trying to > > > >> > > > >>>respond to a different point brought up by Raymond. > > > >>> > > > >>>On Aug 18, we are going to cut the August release branch. The point > > is > > > >>>about allowing small changes, bug fixes and improvements to continue > > in > > > >>>that branch while we are putting the release distros together, with > > the > > > >>>following conditions: > > > >>> > > > >>>- No completely new function, only bug fixes and improvements. > > > >>>- No changes to dependencies or structure of the distro (unless > > > required > > > >>>to fix a major bug, and approved by the RM). > > > >>>- Commits go with a full build of the runtime, itests, samples and > > > demos, > > > >>>and verification that the samples still work following the steps > > > documented > > > >>>in their readmes. > > > >> > > > >> > > > >>Sure ok, the branch wont be immediately frozen, but, and its a big > > but, > > > we > > > >>need to be really careful with that as every time we've allowed > > > development > > > >>to continue in the branch it has ended up delaying a release. No one > > can > > > on > > > >>each commit do a full review including running all the samples, > > reading > > > all > > > >>the readme's and vetting all the legal stuff, so things get missed. > > Its > > > also > > > >>hard to review things thoroughly after you've already done a review a > > > couple > > > >>of times, so things start getting missed. I'd rather delay taking the > > > branch > > > >>than plan on being able to continue development in the branch. There's > > > been > > > >>a lot of change in trunk since 0.91, maybe what we should do is start > > > the > > > >>clean up work, legal review, sorting out the distributions for all the > > > >>module changes etc in trunk towards then end of next week but not take > > > the > > > >>branch till very early the following week with the expectation of > > > getting > > > >>RC1 out really quickly. > > > >> > > > >> ...ant > > > >> > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > +1 for 21st as the target. Can I suggest we take some time (assuming there > is some) on the 20th to test the samples and check through the readmes etc > before taking the branch. > > Simon > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For a
Re: Release management for next release, was: SCA 0.92 release?
On 8/9/07, ant elder <[EMAIL PROTECTED]> wrote: > > I guess early the following week still leaves time for an August release. > It will be real tight though so we'll all need to be quick and thorough > with > our RC reviews as one problem once we get to the IPMC voting and it could > easily slip it into September. > > So does taking the branch on the 21st sound ok to everyone? > >...ant > > On 8/9/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > > Ant talked about cutting the branch very early next week. I'd prefer > > that to doing it on August 18th. I will be away for a few days, > > returning home late on the 18th, and I could take advantage of the > > extra couple of days to help with last-minute things. > > > >Simon > > > > Venkata Krishnan wrote: > > > > > Hi, > > > > > > Theres been lots of discussion. So let me summarize my understanding > > > / imaginiation : - > > > > > > - We will cut a branch around Aug 18th for Release 0.95. As always, > > > once the branch is cut we need to be watchful on the commits > > > (including getting the RMs nod to significant ones) to the branch and > > > also ensure the trunk is always in sync. > > > - Post 0.95, maybe a couple of weeks after the release, we'd cut > > > another branch and head with that for 1.0 release. Being a 1.0 > > > release, we prob. need a branch early as that so that we can whet the > > > things we are targetting for the release. > > > > > > Is that all right ? > > > > > > - Venkat > > > > > > > > > > > > On 8/9/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > >>On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> > > >>Sure, 1.0 development should happen in trunk, but I was trying to > > >> > > >>>respond to a different point brought up by Raymond. > > >>> > > >>>On Aug 18, we are going to cut the August release branch. The point > is > > >>>about allowing small changes, bug fixes and improvements to continue > in > > >>>that branch while we are putting the release distros together, with > the > > >>>following conditions: > > >>> > > >>>- No completely new function, only bug fixes and improvements. > > >>>- No changes to dependencies or structure of the distro (unless > > required > > >>>to fix a major bug, and approved by the RM). > > >>>- Commits go with a full build of the runtime, itests, samples and > > demos, > > >>>and verification that the samples still work following the steps > > documented > > >>>in their readmes. > > >> > > >> > > >>Sure ok, the branch wont be immediately frozen, but, and its a big > but, > > we > > >>need to be really careful with that as every time we've allowed > > development > > >>to continue in the branch it has ended up delaying a release. No one > can > > on > > >>each commit do a full review including running all the samples, > reading > > all > > >>the readme's and vetting all the legal stuff, so things get missed. > Its > > also > > >>hard to review things thoroughly after you've already done a review a > > couple > > >>of times, so things start getting missed. I'd rather delay taking the > > branch > > >>than plan on being able to continue development in the branch. There's > > been > > >>a lot of change in trunk since 0.91, maybe what we should do is start > > the > > >>clean up work, legal review, sorting out the distributions for all the > > >>module changes etc in trunk towards then end of next week but not take > > the > > >>branch till very early the following week with the expectation of > > getting > > >>RC1 out really quickly. > > >> > > >> ...ant > > >> > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. Simon
itests: There are no tests to run
I am trying to execute itests from itest folder with mvn. Everything went fine without any errors including the sample itest that we are trying to write. However I have observed that, while trying to execute itests from each itest folder, for few folders it says "There are no tests to run". What does this mean, are those tests incomplete?, or am I missing something here?. Thanks, Venu.
Re: 1 more new component instance per request?
Great help, thank you very much. You realy make me a litte uneasy: I need to give more time to spec analyzation. Simon Laws <[EMAIL PROTECTED]> wrote: On 8/9/07, shaoguang geng wrote: > > Today, I found in respond to each request, Tuscany instantiate new one > class for each. I tried binding.ws, it works as well. > > SCA1.0 does not specify instance management of a component, but I remember > J2EE does not mentioned such things for EJB and servlet, it should be > managed by the containers. > > So here comes my question: is it a good idea to make a great deal of > component instances in Tuscany, or we might control it to act as singleton? > > > > > - > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's > on, when. Hi Shaoguang SCA defines a concept of scope for a component, for example, if you take a look at the Java Annotations and APIs spec you will see an annotation @SCOPE defined which takes the values, STATELESS REQUEST CONVERSATION COMPOSITE This gives you some fairly coarse grained control over how the runtime will manage instances of Java components. For example, if you mark your Java implementation as having @SCOPE(COMPOSITE) you should see that only one instance is created within the composite. Hope that helps Simon - Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
I think Tuscany needs a graph generator for composite layouts
as the title, when composite contents comes more and more complicated, a layout graph generator would do greate help to developers. Or did some one see commercial providers of such a grapher? Good day. - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
Re: mvn eclipse:eclipse fails on java
Hi Simon, Simon Laws wrote: I note from your other post that you are having problems with the full build with JDK1.6. Is it possible for you to try with 1.5 as this is known to work? We can then isolate JDK issues from these more general build issues. Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it made it this far (I also disabled SELinux to make sure nothing funky was happening): --- T E S T S --- Running supplychain.SupplyChainClientTestCase In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer is [Proxy - f6438d] java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1422) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:335) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService(OSGiImplementationProvider.java:773) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle(OSGiImplementationProvider.java:873) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle(OSGiImplementationProvider.java:326) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance(OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:145) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:75) at $Proxy7.purchaseGoods(Unknown Source) at supplychain.SupplyChainClientTestCase.test(SupplyChainClientTestCase.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.12 sec <<< FAILURE! test(supplychain.SupplyChainClientTestCase) Time elapsed: 1.995 sec <<< ERROR! org.apache.tuscany.sca.factory.ObjectCreationException: org.apache.tuscany.sca.factory.ObjectCreationException: java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle(OSGiImplementationProvider.java:360) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance(OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.a
Re: Intent and Policy attachments on Operations
Hi Sebastien, thanks for that explanation. I get your point. For now I'd revert back those changes to 'Operation' and will figure out an alternative. - Venkat On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Venkata Krishnan wrote: > > Sebastien, thanks for responding. I am still not convinced about > > Intent instances having links to things in the assembly model. I > > perceive the Policy module to be independent of any other SCA module > > (assembly, or interface, ... ). > > > > > I just responded to some of these in a response to Ant's email in the > same thread. I think I covered your questions there. > > All of this can probably be summarized as: > > If you're not convinced that Intent should point to interface/operation, > try to draw a parallel with how service/reference point to interface. > > or > > An intent configures a particular use of an interface/operation (so > it should point to that operation...) > > > Also when we are resovling or building the composites, it seems a bit > > odd to me to go after a PolicyRegistry and get the bunch of all > > Intents defined for a domain and then run thro each to find the > > operations that use it. Also I see that there are other decorations > > as well to the Operation that exists today - one of which is the > > databinding. So, why wouldn't intents and policy sets simply add on. > > > > Because Databindings should not be doing this in the first place :) > > > However if you say that we share instances of Operations across > > interface definitions, then we probably need to store this map in the > > InterfaceDef.. or if the InterfaceDef instances are shared then we > > have look at the next higher level thing that is not shared to manage > > this information. > > > > Am I missing some point here ? > > > > - Venkat > > > > The models are currently using lists and I'd suggest to continue on the > same path. > > If you really wanted to switch the relationship around, I think you'd > have to come up with a new model object containing pointers to > interface, operation, and the list of intents that apply to it. Then try > to give a meaningful name to that object, if you can't find a good name > for it, maybe that's because it's just too artificial and does not > represent a real entity in the model but instead a disguised > relationship? ... which is simply represented at the moment as an Intent > -> Operation pointer I'll let you think about it :) > > > On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > >> Venkata Krishnan wrote: > >> > >>> Hi, > >>> > >>> The Assembly Specs and the PolicyFramework specs allows for intents > >>> and policysets to be specified on Operations. > >>> > >>> To implement this I'd expect that the Operation interface support > >>> methods to hold a set of required intents and policysets. This also > >>> seems in sync with the schema definition for Operation. > >>> > >>> However in the existing code this has been modeled as an Intent > >>> instance having a list of operations over which the intent could > >>> apply. Similarly a PolicySet instance has a list of operations to > >>> which the policyset applies. Is there any specific reason for > >>> modeling it this way? > >>> > >>> I am in progress with changes that change this to what I have > >>> mentioned in the second paragraph of this mail. If I am heading in > >>> the wrong direction, could somebody shout please. > >>> > >>> Thanks > >>> > >>> - Venkat > >>> > >>> > >>> > >> The "Intent -> operations" relationship was modeled like this > >> intentionally. > >> > >> Here's why: > >> > >> If you're talking about o.a.t.interfacedef.Operation, then I don't think > >> it can hold intents. Operation represents a business method/operation on > >> a business interface, potentially used in multiple Services or > >> References... with different sets of intents. > >> > >> The element in SCA assembly XML does not represent the > >> actual operation on the business interface, it is just the syntax used > >> to group the intents that apply to a given operation, within the context > >> of a particular service or reference. > >> > >> So basically we need to represent the association: > >> a set of intents -> a set of operations in the context of a particular > >> service/reference > >> > >> There's basically two ways to represent this: > >> a) In an intent, list the business operations that the intent applies to > >> or > >> b) Invent a new object representing an "operation used within the > >> context of a reference/service", pointing to the actual operation + > >> listing the intents > >> > >> The assembly model being a logical model it does not have to follow the > >> convolutions of the particular XML syntax, and it seems to me that (a) > >> is more logical than (b). At least it'll allow us to easily find which > >> operations a particular intent (and the corresponding interceptors) > >> applies to. > >> > >> Hope this helps. > >> > >> -
Re: Policy intents and policySets on bindings and implementations
Hi Sebastien, Yes, this was what I intended to do initially. But got a bit concerned about losing the original state of the model after build time. I was thinking of a Admin or Mgmt function that might display the original configurations before thing got built i.e. computed or aggregated. For this I thought its best to have information that was originially loaded preserved. The 'ComputedIntents' and 'ComputedPolicies' will only emerge during the build time. I could not figure out a better place to hold this information than the model itself. Well, that's just for explaining the thoughts behind that implementation. I am open to cutting this out :). Independent of this change, could you please help me get some clarity on how we could retrieve the original configurations. Thanks. - Venkat On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > I noticed that bindings and implementations now have: > - intents > - policySets > > and > > - computedIntents > - computedPolicySets > > How about simplifying this a bit and doing what we've done in > CompositeBuilder with all other similar cases like bindings, property > configuration etc. > - we read intents > - we compute/combine/override intents declared at different levels > - eventually the intents field contains the effective (computed) intents > > With bindings on references for example we don't have bindings and > computedBindings... > > This will make the model simpler, and will also avoid confusion when > people use the model, like: hmm I'm looking at Binding, which intent > field should I use? intents or computedIntents? should I add to both? > which one should I get the intents from? if I add to one does the other > reflect my changes? etc. :) > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
