Re: [SCA 1.2] Release Status and RC plans
While we still waiting for the next RC, I have uploaded stable distribution to my people.a.o account [1]. Please feel free to use it for testing and report any issues. [1] http://people.apache.org/~lresende/tuscany/sca-1.2-stable/ On Wed, Apr 2, 2008 at 10:18 AM, Luciano Resende [EMAIL PROTECTED] wrote: Sure, so let me know when you are done, in the meantime I'll try to finish license reviews, etc. On Wed, Apr 2, 2008 at 9:49 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Looks like we are getting ready for RC3. I'm basically done with the dependency cleanup (see thread [1]) and JIRA count is very low (but looks like new ones are being created).. Please let me know if you have unfinished work that is a must for Java SCA 1.2, otherwise I'll review the list of open JIRA in the morning for any blockers, and start working on cutting a RC3. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29677.html I'd like to merge the fix for TUSCANY-2182 into the 1.2 branch if possible, I've tested the fix on Tomcat, Geronimo and WebSphere and have seen no regressions. After that is merged I'll still need to fix the issue with our ServletFilter on WebSphere to get a successful bring up of the webapp part of the Store tutorial on WebSphere App Server 6.0.1, but if it doesn't make the RC3 cut I can work on documenting a possible workaround later. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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: [VOTE] SDO 1.1 rc3 release
Hi, I found the problem. I was running the mvn command on impl folder and getting this failure, and not on the root folder. Strangely, I tried to run the mvn on the impl folder on another environment and it worked : ) It's probably a problem with my environment though So, the RC4 seems OK to me ; ) Adriano Crestani On Wed, Apr 2, 2008 at 9:16 PM, Adriano Crestani [EMAIL PROTECTED] wrote: mvn clean install didn't work either : ( Adriano Crestani On Wed, Apr 2, 2008 at 9:03 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just tried the 1.1-incubating branch with both IBM and SUN JDK 1.5.x. The build was successful. Did you run with mvn clean install? IIRC, when I was playing around different versions of surefire plugin this afternoon, I hit the same problem once in the OSGi test case. It seems to be a bit random. Anyway, I don't think it's a blocker. Thanks, Raymond -- From: Adriano Crestani [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 9:28 PM To: tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] SDO 1.1 rc3 release Hi, I'm getting a test failure (the maven output below)* : ( *. Am I doing something wrong? Regards, Adriano Crestani --- T E S T S --- Running org.apache.tuscany.sdo.test.DataObjectGetListTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec Running org.apache.tuscany.sdo.test.NeverStaleChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec Running org.apache.tuscany.sdo.test.XPathTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.tuscany.sdo.test.DynamicTypesComparisonTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.tuscany.sdo.test.ImplSpecificTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.tuscany.sdo.test.HelperContextTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.tuscany.sdo.test.SubstitutionValuesTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.681 sec FA ILURE! Running org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sdo.test.XMLSaveOptionsTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec Running org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec Running org.apache.tuscany.sdo.test.SequenceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sdo.test.ChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.tuscany.sdo.test.SchemaLocationTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.tuscany.sdo.test.FormTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.315 sec Running org.apache.tuscany.sdo.test.SerializeTypesTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.apache.tuscany.sdo.test.SimpleCopyTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.tuscany.sdo.test.osgi.ClassLoaderTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.349 sec Running org.apache.tuscany.sdo.test.DeserializationNoSchemaTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.19 sec Running org.apache.tuscany.sdo.test.MetadataInstancePropertiesTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec Running org.apache.tuscany.sdo.test.DefineTypeTestCase Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec Running org.apache.tuscany.sdo.test.DataTypeBaseTypeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sdo.test.XMLStreamHelperTestCase Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.291 sec Running org.apache.tuscany.sdo.test.MixedTypeTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011
Re: [VOTE] SDO 1.1 rc3 release
Thanks ;) I shall rebuild the RC4 distro to include that. ...ant On Wed, Apr 2, 2008 at 10:15 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Ant. I had to fix TUSCANY-2187 which broke the build on Windows with SUN JDK 1.5.x. The commit is r644071. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 2:12 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] SDO 1.1 rc3 release A new SDO 1.1 RC4 is available at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4, could anyone do a quick sanity check review before I call a release vote on this? ...ant On Wed, Apr 2, 2008 at 8:32 AM, ant elder [EMAIL PROTECTED] wrote: Thats excellent Adriano. I'll go merge this into the 1.1 branch and respin an RC now. ...ant On Tue, Apr 1, 2008 at 1:18 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Ant, The bug is fixed on revision 643224 ; ) Adriano Crestani On Mon, Mar 31, 2008 at 8:56 AM, ant elder [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 7:53 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Adriano, you've assigned TUSCANY-1659 to yourself so does that mean you're working on a fix (which would be great!)? Anyone have any pointers to help fix it? The jira has been open for over 6 months already so is anyone actually saying its a blocker for this 1.1 release? Yes, I'm trying to fix it : ). And I think it's not a blocker, cause it's not so relevant, since it blocks only in few cases that are env-dependent. So, for me it's ok if we add this fix only on next release. Does that email from Frank over on the SDO Date Format thread get you closer? I'm still happy hold of the repsin if you think you're likely to get a fix for this done soon. ...ant
Re: [VOTE] SDO 1.1 rc3 release
Thats good, looks like we might be just about there now. Just to confirm - were you testing with the code which included the TUSCANY-2187 fix that Raymond had just committed? ...ant On Thu, Apr 3, 2008 at 7:55 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I found the problem. I was running the mvn command on impl folder and getting this failure, and not on the root folder. Strangely, I tried to run the mvn on the impl folder on another environment and it worked : ) It's probably a problem with my environment though So, the RC4 seems OK to me ; ) Adriano Crestani On Wed, Apr 2, 2008 at 9:16 PM, Adriano Crestani [EMAIL PROTECTED] wrote: mvn clean install didn't work either : ( Adriano Crestani On Wed, Apr 2, 2008 at 9:03 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just tried the 1.1-incubating branch with both IBM and SUN JDK 1.5.x. The build was successful. Did you run with mvn clean install? IIRC, when I was playing around different versions of surefire plugin this afternoon, I hit the same problem once in the OSGi test case. It seems to be a bit random. Anyway, I don't think it's a blocker. Thanks, Raymond -- From: Adriano Crestani [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 9:28 PM To: tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] SDO 1.1 rc3 release Hi, I'm getting a test failure (the maven output below)* : ( *. Am I doing something wrong? Regards, Adriano Crestani --- T E S T S --- Running org.apache.tuscany.sdo.test.DataObjectGetListTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec Running org.apache.tuscany.sdo.test.NeverStaleChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec Running org.apache.tuscany.sdo.test.XPathTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.tuscany.sdo.test.DynamicTypesComparisonTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.tuscany.sdo.test.ImplSpecificTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.tuscany.sdo.test.HelperContextTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.tuscany.sdo.test.SubstitutionValuesTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.681 sec FA ILURE! Running org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sdo.test.XMLSaveOptionsTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec Running org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec Running org.apache.tuscany.sdo.test.SequenceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sdo.test.ChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.tuscany.sdo.test.SchemaLocationTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.tuscany.sdo.test.FormTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.315 sec Running org.apache.tuscany.sdo.test.SerializeTypesTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.apache.tuscany.sdo.test.SimpleCopyTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.tuscany.sdo.test.osgi.ClassLoaderTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.349 sec Running org.apache.tuscany.sdo.test.DeserializationNoSchemaTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.19 sec Running org.apache.tuscany.sdo.test.MetadataInstancePropertiesTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec Running org.apache.tuscany.sdo.test.DefineTypeTestCase Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec Running
Re: [VOTE] SDO 1.1 rc3 release
No, I just tested the code you posted at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 On Wed, Apr 2, 2008 at 11:27 PM, ant elder [EMAIL PROTECTED] wrote: Thats good, looks like we might be just about there now. Just to confirm - were you testing with the code which included the TUSCANY-2187 fix that Raymond had just committed? ...ant On Thu, Apr 3, 2008 at 7:55 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I found the problem. I was running the mvn command on impl folder and getting this failure, and not on the root folder. Strangely, I tried to run the mvn on the impl folder on another environment and it worked : ) It's probably a problem with my environment though So, the RC4 seems OK to me ; ) Adriano Crestani On Wed, Apr 2, 2008 at 9:16 PM, Adriano Crestani [EMAIL PROTECTED] wrote: mvn clean install didn't work either : ( Adriano Crestani On Wed, Apr 2, 2008 at 9:03 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just tried the 1.1-incubating branch with both IBM and SUN JDK 1.5.x. The build was successful. Did you run with mvn clean install? IIRC, when I was playing around different versions of surefire plugin this afternoon, I hit the same problem once in the OSGi test case. It seems to be a bit random. Anyway, I don't think it's a blocker. Thanks, Raymond -- From: Adriano Crestani [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 9:28 PM To: tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] SDO 1.1 rc3 release Hi, I'm getting a test failure (the maven output below)* : ( *. Am I doing something wrong? Regards, Adriano Crestani --- T E S T S --- Running org.apache.tuscany.sdo.test.DataObjectGetListTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec Running org.apache.tuscany.sdo.test.NeverStaleChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec Running org.apache.tuscany.sdo.test.XPathTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.tuscany.sdo.test.DynamicTypesComparisonTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.tuscany.sdo.test.ImplSpecificTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.tuscany.sdo.test.HelperContextTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.tuscany.sdo.test.SubstitutionValuesTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.681 sec FA ILURE! Running org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sdo.test.XMLSaveOptionsTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec Running org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec Running org.apache.tuscany.sdo.test.SequenceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sdo.test.ChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.tuscany.sdo.test.SchemaLocationTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.tuscany.sdo.test.FormTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.315 sec Running org.apache.tuscany.sdo.test.SerializeTypesTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.apache.tuscany.sdo.test.SimpleCopyTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.tuscany.sdo.test.osgi.ClassLoaderTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.349 sec Running org.apache.tuscany.sdo.test.DeserializationNoSchemaTestCase Tests run: 2, Failures: 0,
Re: [VOTE] SDO 1.1 rc3 release
Ok, i'm doing an RC4a right now to include the TUSCANY-2187 fix, will be up shortly, hopefully you'll have the endurance to try that too :) ...ant On Thu, Apr 3, 2008 at 8:50 AM, Adriano Crestani [EMAIL PROTECTED] wrote: No, I just tested the code you posted at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 On Wed, Apr 2, 2008 at 11:27 PM, ant elder [EMAIL PROTECTED] wrote: Thats good, looks like we might be just about there now. Just to confirm - were you testing with the code which included the TUSCANY-2187 fix that Raymond had just committed? ...ant On Thu, Apr 3, 2008 at 7:55 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I found the problem. I was running the mvn command on impl folder and getting this failure, and not on the root folder. Strangely, I tried to run the mvn on the impl folder on another environment and it worked : ) It's probably a problem with my environment though So, the RC4 seems OK to me ; ) Adriano Crestani On Wed, Apr 2, 2008 at 9:16 PM, Adriano Crestani [EMAIL PROTECTED] wrote: mvn clean install didn't work either : ( Adriano Crestani On Wed, Apr 2, 2008 at 9:03 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just tried the 1.1-incubating branch with both IBM and SUN JDK 1.5.x. The build was successful. Did you run with mvn clean install? IIRC, when I was playing around different versions of surefire plugin this afternoon, I hit the same problem once in the OSGi test case. It seems to be a bit random. Anyway, I don't think it's a blocker. Thanks, Raymond -- From: Adriano Crestani [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 9:28 PM To: tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] SDO 1.1 rc3 release Hi, I'm getting a test failure (the maven output below)* : ( *. Am I doing something wrong? Regards, Adriano Crestani --- T E S T S --- Running org.apache.tuscany.sdo.test.DataObjectGetListTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec Running org.apache.tuscany.sdo.test.NeverStaleChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec Running org.apache.tuscany.sdo.test.XPathTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.tuscany.sdo.test.DynamicTypesComparisonTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.tuscany.sdo.test.ImplSpecificTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.tuscany.sdo.test.HelperContextTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.tuscany.sdo.test.SubstitutionValuesTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.681 sec FA ILURE! Running org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sdo.test.XMLSaveOptionsTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec Running org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec Running org.apache.tuscany.sdo.test.SequenceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sdo.test.ChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.tuscany.sdo.test.SchemaLocationTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.tuscany.sdo.test.FormTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.315 sec Running org.apache.tuscany.sdo.test.SerializeTypesTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time
[jira] Resolved: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2182. - Resolution: Fixed Resolved - finally... - in SVN revisions r644201 (trunk) and r644202 (1.2 branch) ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SDO 1.1 rc3 release
The RC4a artifacts are now available at http://people.apache.org/~antelder/tuscany/sdo/1.1-RC4a/ I'll call a vote on releasing that late today, any reviews in the meantime welcomed. ...ant On Thu, Apr 3, 2008 at 8:58 AM, ant elder [EMAIL PROTECTED] wrote: Ok, i'm doing an RC4a right now to include the TUSCANY-2187 fix, will be up shortly, hopefully you'll have the endurance to try that too :) ...ant On Thu, Apr 3, 2008 at 8:50 AM, Adriano Crestani [EMAIL PROTECTED] wrote: No, I just tested the code you posted at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 On Wed, Apr 2, 2008 at 11:27 PM, ant elder [EMAIL PROTECTED] wrote: Thats good, looks like we might be just about there now. Just to confirm - were you testing with the code which included the TUSCANY-2187 fix that Raymond had just committed? ...ant On Thu, Apr 3, 2008 at 7:55 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I found the problem. I was running the mvn command on impl folder and getting this failure, and not on the root folder. Strangely, I tried to run the mvn on the impl folder on another environment and it worked : ) It's probably a problem with my environment though So, the RC4 seems OK to me ; ) Adriano Crestani On Wed, Apr 2, 2008 at 9:16 PM, Adriano Crestani [EMAIL PROTECTED] wrote: mvn clean install didn't work either : ( Adriano Crestani On Wed, Apr 2, 2008 at 9:03 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just tried the 1.1-incubating branch with both IBM and SUN JDK 1.5.x. The build was successful. Did you run with mvn clean install? IIRC, when I was playing around different versions of surefire plugin this afternoon, I hit the same problem once in the OSGi test case. It seems to be a bit random. Anyway, I don't think it's a blocker. Thanks, Raymond -- From: Adriano Crestani [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 9:28 PM To: tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] SDO 1.1 rc3 release Hi, I'm getting a test failure (the maven output below)* : ( *. Am I doing something wrong? Regards, Adriano Crestani --- T E S T S --- Running org.apache.tuscany.sdo.test.DataObjectGetListTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec Running org.apache.tuscany.sdo.test.NeverStaleChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec Running org.apache.tuscany.sdo.test.XPathTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.tuscany.sdo.test.DynamicTypesComparisonTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.tuscany.sdo.test.ImplSpecificTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.tuscany.sdo.test.HelperContextTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.tuscany.sdo.test.SubstitutionValuesTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.681 sec FA ILURE! Running org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sdo.test.XMLSaveOptionsTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec Running org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec Running org.apache.tuscany.sdo.test.SequenceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.tuscany.sdo.test.ChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.tuscany.sdo.test.SchemaLocationTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019
Re: Adding SVN version to Java files
Do you use an ide with svn integration? Using eclipse with the svn plugin you get this information displayed right next to the file name in the package explorer, no need to right click or anything you don't even need to open up the file. I'd guess other IDEs probably have similar tools available. Could you try that to see if it gives you what you need? See http://subclipse.tigris.org/. ...ant On Wed, Apr 2, 2008 at 11:01 AM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: The one use I see is that by looking at the file (and not doing anything extra), I can quickly learn the last revision at which it is modified. Otherwise, I will have to look at the file properties or svn log to know that revision number. I find that it saves time while investigating issues. ++Vamsi On Wed, Apr 2, 2008 at 3:07 PM, ant elder [EMAIL PROTECTED] wrote: On Mon, Mar 31, 2008 at 8:01 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Mon, Mar 31, 2008 at 7:27 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Mark Combellack wrote: Hi, I've been looking through the Tuscany source code and noticed that some files have a @version containing the SVN revision number in their JavaDoc headers but others do not. As an example, @version might look like: /** * Some JavaDoc for the class * * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov 2007) $ */ I would like to go through the Tuscany source code and add this header where it is missing. This would involve a large number of minor changes to the Tuscany tree so I wanted to run it by everyone to make sure no-one had a problem with me doing this at this time. I'll probably start this next week unless there is an objection. Thanks, Mark We're next week now :) Here's a summary of what I've seen in that thread so far: - Mark would like to help add SVN revision headers to all files - Vamsi +0.5 and suggests to set up to add headers to new files - Luciano +1 and agrees to set up SVN and IDE for this - Ant prefers not to this, not useful and clutters up the code - Sebastien +1 and also suggests to set up our IDEs for this - Simon would it find useful and also happy to set up his IDE 5 people seem to be reaching consensus, 1 prefers not to do it. Ant, do you still have any objections against doing this? Yep, I don't think we should do it. No one has given any even vaguely compelling reasons for using them but for them to have the very occasional usefulness _everyone_ has to always have it set up which will inevitably go wrong occasionally for someone which makes them completely unreliable anyway - how do you know that src you're looking at isn't one of the files which has been corrupted by someone with a bad environment? And it adds just another cause of negative emails to the ML when complaining that someone has done it wrong. All that is exactly what used to happen in the bad old days when we did use them. Doesn't using svn info work as a replacement in a lot of circumstances anyway? And if not then what are the circumstances where you're having to look at src out of version control or out of a released distro? This _is_ open source so its normal to have access to the version control system not like in closed src dev when its more likely there'll be uncontrolled src floating around. And its yet another burden to place on Tuscany development, i just don't understand the feeling that somehow things would be better if we had more formal processes and procedures in place - not having many of those it what I like about developing at Apache. ...ant Are you saying that we should remove them? What if I want to add them to the new files I'm editing (which is what I'm doing at the moment). Are you going to object to these commits? -- Jean-Sebastien I'd like to understand why we need them. If there are some real cases of where they really are useful then maybe it is worthwhile but right now no one has suggested any? ...ant
[jira] Assigned: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned TUSCANY-2165: Assignee: Vamsavardhana Reddy Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2192) iTest/OneWay has just failed on the Continuum server and has blocked the build on the root
[ https://issues.apache.org/jira/browse/TUSCANY-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585038#action_12585038 ] Mark Combellack commented on TUSCANY-2192: -- Looking at the code, the key output is: Finished callCount = 99 This value should be 100. I think the problem is that the unit test is not well coded to handle the case where the build server is heavily loaded as it has a sleep of 2 seconds and expects all @OneWay operations to complete in this time. The test case needs to be updated to improve how it waits for all the @OneWay operations to complete. iTest/OneWay has just failed on the Continuum server and has blocked the build on the root -- Key: TUSCANY-2192 URL: https://issues.apache.org/jira/browse/TUSCANY-2192 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Mark Combellack Assignee: Mark Combellack Fix For: Java-SCA-Next http://vmbuild.apache.org/continuum/buildResult.action?buildId=72567projectId=277 The Continuum build has failed in the Apache Tuscany SCA OneWay Integration Tests The error output is: Apr 2, 2008 6:31:23 PM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://vmbuild.apache.org:50976/OneWayServiceComponent Finished callCount = 99 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.584 sec FAILURE! testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase) Time elapsed: 45.55 sec FAILURE! junit.framework.AssertionFailedError: expected:100 but was:99 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:277) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:195) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.tuscany.sca.itest.oneway.OneWayTestCase.testOneWay(OneWayTestCase.java:73) 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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) 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:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Results : Failed tests: testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase) Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2192) iTest/OneWay has just failed on the Continuum server and has blocked the build on the root
[ https://issues.apache.org/jira/browse/TUSCANY-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Combellack resolved TUSCANY-2192. -- Resolution: Fixed I've improved the way in which the waiting for the @OnwWay methods to takes place. Instead of waiting for a fixed 2 seconds, it waits in a loop until all the @OneWay operations complete or 10 seconds passes. These changes will speed up the tests since it does not need to wait the original 2 seconds on a fast computer and allows extra time for the @OneWay methods to complete on a slower computer. Fixed in SVN revision 644255 iTest/OneWay has just failed on the Continuum server and has blocked the build on the root -- Key: TUSCANY-2192 URL: https://issues.apache.org/jira/browse/TUSCANY-2192 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Mark Combellack Assignee: Mark Combellack Fix For: Java-SCA-Next http://vmbuild.apache.org/continuum/buildResult.action?buildId=72567projectId=277 The Continuum build has failed in the Apache Tuscany SCA OneWay Integration Tests The error output is: Apr 2, 2008 6:31:23 PM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://vmbuild.apache.org:50976/OneWayServiceComponent Finished callCount = 99 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.584 sec FAILURE! testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase) Time elapsed: 45.55 sec FAILURE! junit.framework.AssertionFailedError: expected:100 but was:99 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:277) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:195) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.tuscany.sca.itest.oneway.OneWayTestCase.testOneWay(OneWayTestCase.java:73) 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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) 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:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Results : Failed tests: testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase) Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2192) iTest/OneWay has just failed on the Continuum server and has blocked the build on the root
iTest/OneWay has just failed on the Continuum server and has blocked the build on the root -- Key: TUSCANY-2192 URL: https://issues.apache.org/jira/browse/TUSCANY-2192 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Mark Combellack Assignee: Mark Combellack Fix For: Java-SCA-Next http://vmbuild.apache.org/continuum/buildResult.action?buildId=72567projectId=277 The Continuum build has failed in the Apache Tuscany SCA OneWay Integration Tests The error output is: Apr 2, 2008 6:31:23 PM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://vmbuild.apache.org:50976/OneWayServiceComponent Finished callCount = 99 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.584 sec FAILURE! testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase) Time elapsed: 45.55 sec FAILURE! junit.framework.AssertionFailedError: expected:100 but was:99 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:277) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:195) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.tuscany.sca.itest.oneway.OneWayTestCase.testOneWay(OneWayTestCase.java:73) 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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) 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:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Results : Failed tests: testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase) Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tutorial: Adding a Markeplace Scenario
Hello, I have modified the composite for the store-market module. I had never worked with multiplicity before. Thus, I need to some help to check if this code is OK. What I did was to modify the StoreMarketCatalog component from component name=StoreMarketCatalog ... reference name=fruitsCatalog target=StoreSupplierFruitsCatalog/ reference name=vegetablesCatalogtarget=VegetablesCatalogWebService binding.ws/ /reference ... /component To component name=StoreMarketCatalog ... reference name=GoodsCatalog multiplicity=0..n target=StoreMarketFruitsCatalog01 VegetablesCatalogWebService01/ ... /component So, the relevant parts of the composite look like this now: ... component name=StoreMarketCatalog implementation.java class=services.market.MarketCatalogImpl/ property name=currencyCodeUSD/property service name=Catalog t:binding.jsonrpc/ /service reference name=GoodsCatalog multiplicity=0..n target=StoreMarketFruitsCatalog01 VegetablesCatalogWebService01/ reference name=currencyConverter target=StoreMarketCurrencyConverter/ /component component name=StoreMarketFruitsCatalog01 implementation.java class=services.FruitsCatalogImpl/ property name=currencyCodeUSD/property reference name=currencyConverter target=StoreMarketCurrencyConverter/ /component component name=VegetablesCatalogWebService01 binding.ws/ /component ... Jean-Sebastien mentioned that the approach of hard-coding the components in the composite would not be needed when using multiplicity. However, the way I used multiplicity here still requires new stores to be added to the composite whenever the store wants to add its catalog to the marketplace. Jean-Sebastien, is this what you had in mind when you mentioned multiplicity or am I doing something wrong? Regards, Mario -Original Message- From: Antollini, Mario [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 6:28 PM To: tuscany-dev@ws.apache.org Subject: RE: Tutorial: Adding a Markeplace Scenario Hello, I have created the new module and called it store-market (I uploaded it to JIRA: https://issues.apache.org/jira/browse/TUSCANY-2163) As Jean-Sebastien suggested I took store-merger and modified it. I now need to start working on the multiplicity 0..n instead of the currently hardcoded references to two catalogs. Regards, Mario -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 3:51 PM To: tuscany-dev@ws.apache.org Subject: Re: Tutorial: Adding a Markeplace Scenario Antollini, Mario wrote: Hello jean-Sebastien, I was thinking about adding a Marketplace scenario to the Tutorial we will be presenting at JavaOne. By Marketplace I mean doing something similar to what Amazon does: offering third party retailers' products via Amazon's site. I think we can do that by offering multiple catalogs via a proxy catalog which consolidates all of them (i.e. data federation). What do you think? I will be looking the tutorial in detail in order to see how I can implement it. Regards, Mario Good idea! This could be a new module addition under java/sca/tutorial. You could wire a list of catalogs to a catalog aggregator service component for example, similar to what the current store-merger module does but with a reference with multiplicity 0..n instead of the currently hardcoded references to two catalogs. The easiest is probably to copy one of the modules (store-merger for example) into a new store-market or something like that as a starting point, adjust the POM etc, submit that in a JIRA and then start making the changes to turn it into a marketplace store. Let us know if have any questions, issues, or need any help when you do that. Thanks! -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585048#action_12585048 ] Vamsavardhana Reddy commented on TUSCANY-2165: -- Java Component Implementation Specification v 1.0 lines 358 to 365: 358 1.2.7. Semantics of an Unannotated Implementation 359 The section defines the rules for determining properties and references for a Java component 360 implementation that does not explicitly declare them using @Reference or @Property. 361 In the absence of @Property and @Reference annotations, the properties and references of a class are 362 defined according to the following rules: 363 1. Public setter methods that are not included in any interface specified by an @Service annotation. 364 2. Protected setter methods 365 3. Public or protected fields unless there is a public or protected setter method for the same name Does this mean that if either an @Property or @Reference annotation is used in the implementation, rest of the unannotated fields and setter methods should simply be ignored? If yes, (which is the current implementation in tuscany) b4 and b5 in org.apache.tuscany.sca.vtest.javaapi.annotations.reference.impl.AServiceImpl will never make into the componentType as references and there is no question of injection. We will need AnotherAServiceImpl in which none of the fields and setter methods are annotated so that b4 and b5 will be computed as references. Am I missing anything? Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2186) @OneWay over binding.ws arguments not being serialized properly
[
https://issues.apache.org/jira/browse/TUSCANY-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585074#action_12585074
]
Lou Amodeo commented on TUSCANY-2186:
-
I found that changing the RuntimeWireImpl as follows seems to fix the problem.
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.java (around line 295)
chain.addInterceptor(Phase.SERVICE, new NonBlockingInterceptor(workScheduler));
@OneWay over binding.ws arguments not being serialized properly
---
Key: TUSCANY-2186
URL: https://issues.apache.org/jira/browse/TUSCANY-2186
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Assignee: Raymond Feng
I am finding that @Oneway operations over binding.ws are not having method
arguments marshalled properly apparently due to a change in the sequence of
interceptors. Previously the NonBlockingInterceptor was being added after the
DataTransformationInterceptor. The data transformation needs to occur prior
to the thread switch to the non-blocking interceptor to allow Axiom to
marshall the message payload before the thread switch.
In the Tuscany revision level I have R634808 the
DataBindingRuntimeWireProcessor does this:
chain.addInterceptor(0, interceptor);
In the past the index of 0 would have put the databinding interceptor at the
front of the interceptor chain, ahead of the NonBlockingInterceptor (which
has already been added at this point). However in this Tuscany revision the
index is ignored and instead a new phase-based ordering mechanism is used.
The above call to addInterceptor obviously wasn't changed yet at this level
to replace the index with a phase. It has been changed in the trunk and now
looks like this:
String phase =
(wire.getSource().getContract() instanceof ComponentReference) ?
Phase.REFERENCE_INTERFACE
: Phase.SERVICE_INTERFACE;
chain.addInterceptor(phase, interceptor);
RuntimeWireImpl is doing this to add the NonBlockingInterceptor:
chain.addInterceptor(Phase.SERVICE_BINDING, new
NonBlockingInterceptor(workScheduler));
Here are the relevant phase definitions in PhaseManager:
private final static String[] SYSTEM_SERVICE_PHASES =
{Phase.SERVICE_BINDING, Phase.SERVICE_POLICY,
Phase.SERVICE_INTERFACE, Phase.SERVICE};
I assume this is an ordered list, so this means the NonBlockingInterceptor
(phase SERVICE_BINDING) is before the DataBindingInterceptor (phase
SERVICE_INTERFACE), which is still opposite of what we want to solve this
problem.
Thanks for your help!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585075#action_12585075 ] Vamsavardhana Reddy commented on TUSCANY-2165: -- Another thing I notice is that org.apache.tuscany.sca.vtest.javaapi.annotations.reference.BService interface does not have @Remotable annotation. So, any unannotated fields and setters will not result in references!! Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585101#action_12585101 ] Vamsavardhana Reddy commented on TUSCANY-2165: -- It is partly a problem with the testcase. The injection part works as is (also in the case of protected fields, which needs to be fixed). Will post a revised test and fix. Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2193) NPE when configuring WSDL interface on component ref when the component has a Composite impl
NPE when configuring WSDL interface on component ref when the component has a Composite impl Key: TUSCANY-2193 URL: https://issues.apache.org/jira/browse/TUSCANY-2193 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Scott Kurz Priority: Minor I noticed this with a more complicated example. To reproduce more simply maybe, go to the SVN dir: sca/itest/recursive and modify BComposite.composite so it looks like: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://sample; xmlns:sample=http://sample; name=BComposite component name=BComponent implementation.composite name=sample:CComposite/ reference name=PromotedRefX interface.wsdl interface=http://blah#wsdl.interface(Blah) / /reference Note that you can put any old WSDL in there. You shouldn't get far enough for it to even matter. You'll hit errors like: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.checkCompatibility(InterfaceContractMapperImpl.java:155) at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.isCompatible(InterfaceContractMapperImpl.java:271) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.reconcileReferences(CompositeConfigurationBuilderImpl.java:527) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:250) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:85) at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:97) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2165: - Attachment: TUSCANY-2165-revised-test.patch TUSCANY-2165-revised-test.patch: Updated testcase. Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor Attachments: TUSCANY-2165-revised-test.patch The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2165: - Attachment: TUSCANY-2165.patch TUSCANY-2165.patch: Reference is not injected for protected fields unless annotated with @Reference Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor Attachments: TUSCANY-2165-revised-test.patch, TUSCANY-2165.patch The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
[ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2165: - Patch Info: [Patch Available] Assignee: (was: Vamsavardhana Reddy) Unassigning so that a committer can pick up. Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Priority: Minor Attachments: TUSCANY-2165-revised-test.patch, TUSCANY-2165.patch The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
Vamsavardhana Reddy (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585048#action_12585048 ] Vamsavardhana Reddy commented on TUSCANY-2165: -- Java Component Implementation Specification v 1.0 lines 358 to 365: 358 1.2.7. Semantics of an Unannotated Implementation 359 The section defines the rules for determining properties and references for a Java component 360 implementation that does not explicitly declare them using @Reference or @Property. 361 In the absence of @Property and @Reference annotations, the properties and references of a class are 362 defined according to the following rules: 363 1. Public setter methods that are not included in any interface specified by an @Service annotation. 364 2. Protected setter methods 365 3. Public or protected fields unless there is a public or protected setter method for the same name Does this mean that if either an @Property or @Reference annotation is used in the implementation, rest of the unannotated fields and setter methods should simply be ignored? If yes, (which is the current implementation in tuscany) b4 and b5 in org.apache.tuscany.sca.vtest.javaapi.annotations.reference.impl.AServiceImpl will never make into the componentType as references and there is no question of injection. We will need AnotherAServiceImpl in which none of the fields and setter methods are annotated so that b4 and b5 will be computed as references. Am I missing anything? I believe section 1.2.7 is about implementations with no annotations at all. Therefore it does not apply if any annotations are present. Simon Java runtime should inject service references to field with common name in absence of @Reference - Key: TUSCANY-2165 URL: https://issues.apache.org/jira/browse/TUSCANY-2165 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ... * References may also be injected via public setter methods even when the * @Reference annotation is not present. However, the @Reference * annotation must be used in order to inject a reference onto a non public * field. In the case where there is no @Reference annotation, the name of * the reference is the same as the name of the field or setter. The vTest: org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 demonstrates this issue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2193) NPE when configuring WSDL interface on component ref when the component has a Composite impl
[
https://issues.apache.org/jira/browse/TUSCANY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585135#action_12585135
]
Scott Kurz commented on TUSCANY-2193:
-
I found the problem.
In CompositeConfigurationBuilderImpl.reconcileReferences() we do a check to see
if we want an incompatible intf warning:
// Reconcile interface
if (componentReference.getInterfaceContract() != null) {
if
(!componentReference.getInterfaceContract().equals(reference
.getInterfaceContract())) {
if
(!interfaceContractMapper.isCompatible(reference.getInterfaceContract(),
componentReference
.getInterfaceContract())) {
warning(Component reference interface incompatible
with reference interface: +...
In the case I described above, we are going to have a non-null IC from the
component reference (the WSDL IC). However, the reference IC wlil still be
null at this point. (The reason seems to be that the reference IC on the
composite impl does not get set until CompositeWireBuilderImpl.wireComposite).
So I'll leave it up to others whether it's best to put a null guard before
calling the IC mapper or if we should look to put a guard in the IC mapper impl
itself.
NPE when configuring WSDL interface on component ref when the component has a
Composite impl
Key: TUSCANY-2193
URL: https://issues.apache.org/jira/browse/TUSCANY-2193
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Reporter: Scott Kurz
Priority: Minor
I noticed this with a more complicated example.
To reproduce more simply maybe, go to the SVN dir: sca/itest/recursive
and modify BComposite.composite so it looks like:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
name=BComposite
component name=BComponent
implementation.composite name=sample:CComposite/
reference name=PromotedRefX
interface.wsdl interface=http://blah#wsdl.interface(Blah) /
/reference
Note that you can put any old WSDL in there. You shouldn't get far enough
for it to even matter.
You'll hit errors like:
java.lang.NullPointerException
at
org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.checkCompatibility(InterfaceContractMapperImpl.java:155)
at
org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.isCompatible(InterfaceContractMapperImpl.java:271)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.reconcileReferences(CompositeConfigurationBuilderImpl.java:527)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:250)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:85)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:97)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2194) When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown
[ https://issues.apache.org/jira/browse/TUSCANY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585136#action_12585136 ] Mark Combellack commented on TUSCANY-2194: -- The problem is actually in the org.apache.tuscany.sca.interfacedef.OverloadedOperationException class itself. The constructor takes the Opeation as a parameter but it does not specify a detailed message for the exception. Therefore, the exception will just output the exception name and no details about the overloaded method. When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown Key: TUSCANY-2194 URL: https://issues.apache.org/jira/browse/TUSCANY-2194 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: SVN revision 644273 on the root Linux Reporter: Mark Combellack Assignee: Mark Combellack Fix For: Java-SCA-Next When a @Remotable interface contains two methods with the same name, Tuscany will throw an OverloadedOperationException. The only problem is that when this exception is output to the console, it does not list the method name or class that has the problem. This makes finding the issue very hard as you don't know where to start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2194) When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown
When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown Key: TUSCANY-2194 URL: https://issues.apache.org/jira/browse/TUSCANY-2194 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: SVN revision 644273 on the root Linux Reporter: Mark Combellack Assignee: Mark Combellack Fix For: Java-SCA-Next When a @Remotable interface contains two methods with the same name, Tuscany will throw an OverloadedOperationException. The only problem is that when this exception is output to the console, it does not list the method name or class that has the problem. This makes finding the issue very hard as you don't know where to start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2194) When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown
[ https://issues.apache.org/jira/browse/TUSCANY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Combellack resolved TUSCANY-2194. -- Resolution: Fixed I've updated the text for the the OperationOverloadedException to include the method and class names. This should make fixing this issue easier for the user. The fix is in SVN revision 644358 in modules/interface I've also added a unit test in SVN revision 644365 in modules/interface-java Note: These changes are on the root. I have not rippled them up to the 1.2 branch When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown Key: TUSCANY-2194 URL: https://issues.apache.org/jira/browse/TUSCANY-2194 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: SVN revision 644273 on the root Linux Reporter: Mark Combellack Assignee: Mark Combellack Fix For: Java-SCA-Next When a @Remotable interface contains two methods with the same name, Tuscany will throw an OverloadedOperationException. The only problem is that when this exception is output to the console, it does not list the method name or class that has the problem. This makes finding the issue very hard as you don't know where to start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2193) NPE when configuring WSDL interface on component ref when the component has a Composite impl
[ https://issues.apache.org/jira/browse/TUSCANY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585144#action_12585144 ] Raymond Feng commented on TUSCANY-2193: --- I see the same problem when I look into TUSCANY-2189. NPE when configuring WSDL interface on component ref when the component has a Composite impl Key: TUSCANY-2193 URL: https://issues.apache.org/jira/browse/TUSCANY-2193 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Scott Kurz Priority: Minor I noticed this with a more complicated example. To reproduce more simply maybe, go to the SVN dir: sca/itest/recursive and modify BComposite.composite so it looks like: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://sample; xmlns:sample=http://sample; name=BComposite component name=BComponent implementation.composite name=sample:CComposite/ reference name=PromotedRefX interface.wsdl interface=http://blah#wsdl.interface(Blah) / /reference Note that you can put any old WSDL in there. You shouldn't get far enough for it to even matter. You'll hit errors like: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.checkCompatibility(InterfaceContractMapperImpl.java:155) at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.isCompatible(InterfaceContractMapperImpl.java:271) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.reconcileReferences(CompositeConfigurationBuilderImpl.java:527) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:250) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:85) at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:97) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference
Hi,
I think the SCA spec needs to define what java implementation classes
qualify for Unannotated Implementation.
I could write an component impl as follows:
public class MyServiceImpl implements MyService {
...
}
@Remotable
public interface MyService {
...
}
Is MyServiceImpl satisfying no annotations at all?
There is also a related JIRA opened in this area:
http://www.osoa.org/jira/browse/JAVA-17.
Thanks,
Raymond
--
From: Simon Nash [EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 7:30 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [jira] Commented: (TUSCANY-2165) Java runtime should inject
service references to field with common name in absence of @Reference
Vamsavardhana Reddy (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585048#action_12585048 ]
Vamsavardhana Reddy commented on TUSCANY-2165:
--
Java Component Implementation Specification v 1.0 lines 358 to 365:
358 1.2.7. Semantics of an Unannotated Implementation
359 The section defines the rules for determining properties and
references for a Java component
360 implementation that does not explicitly declare them using @Reference
or @Property.
361 In the absence of @Property and @Reference annotations, the
properties and references of a class are
362 defined according to the following rules:
363 1. Public setter methods that are not included in any interface
specified by an @Service annotation.
364 2. Protected setter methods
365 3. Public or protected fields unless there is a public or protected
setter method for the same name
Does this mean that if either an @Property or @Reference annotation is
used in the implementation, rest of the unannotated fields and setter
methods should simply be ignored? If yes, (which is the current
implementation in tuscany) b4 and b5 in
org.apache.tuscany.sca.vtest.javaapi.annotations.reference.impl.AServiceImpl
will never make into the componentType as references and there is no
question of injection. We will need AnotherAServiceImpl in which none of
the fields and setter methods are annotated so that b4 and b5 will be
computed as references.
Am I missing anything?
I believe section 1.2.7 is about implementations with no annotations
at all. Therefore it does not apply if any annotations are present.
Simon
Java runtime should inject service references to field with common name
in absence of
@Reference -
Key: TUSCANY-2165
URL: https://issues.apache.org/jira/browse/TUSCANY-2165
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Assignee: Vamsavardhana Reddy
Priority: Minor
The Java AnnotationsAPIs specification Lines 1407, 1408, 1409, 1410 ...
* References may also be injected via public setter methods even
when the
* @Reference annotation is not present. However, the @Reference
* annotation must be used in order to inject a reference onto a non
public
* field. In the case where there is no @Reference annotation, the
name of
* the reference is the same as the name of the field or setter.
The vTest:
org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2
demonstrates this issue
-
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]
Re: Verification Testing
Hi Kevin, I would like to contribute to this effort. Thanks! Kevin Williams [EMAIL PROTECTED] 03/19/2008 01:40 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc [EMAIL PROTECTED] Subject Verification Testing I am thinking of adding a new test bucket specifically for verification testing against the specification set. I believe it would add value to the project and may also be a place where developers new to Tuscany might contribute. Does this sound like a reasonable idea? Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tutorial: Adding a Markeplace Scenario
Hi,
The following snippet doesn't not change the reference multiplicity to be
0..n.
component name=StoreMarketCatalog
...
reference name=GoodsCatalog multiplicity=0..n
target=StoreMarketFruitsCatalog01 VegetablesCatalogWebService01/
...
/component
reference name=GoodsCatalog multiplicity=0..n .. further configures
the reference GoodsCatalog from the componentType (introspected from java
impl class). But it has to be compatible. For example, you can change the
multiplicity from 0..n (defined in componentTpype) to 1..n, 0..1 or 1..1,
but you cannot change it from 1..1 to 0..1, 0..n, or 1..n.
What matters is in the componentType. For example, if you have a java impl:
public class StoreMarketCatalogImpl ... {
@Reference(name=GoodsCatalog, required=false)
protected Catalog[] goodsCatalog; // or protected CollectionCatalog
goodsCatalog;
}
required=false and Catalog[] (or CollectionCatalog) makes the multiplicity
of GoodsCatalog reference 0..n.
Thanks,
Raymond
--
From: Antollini, Mario [EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 3:38 AM
To: tuscany-dev@ws.apache.org
Subject: RE: Tutorial: Adding a Markeplace Scenario
Hello,
I have modified the composite for the store-market module. I had never
worked with multiplicity before. Thus, I need to some help to check if
this code is OK.
What I did was to modify the StoreMarketCatalog component from
component name=StoreMarketCatalog
...
reference name=fruitsCatalog
target=StoreSupplierFruitsCatalog/ reference
name=vegetablesCatalog target=VegetablesCatalogWebService
binding.ws/
/reference
...
/component
To
component name=StoreMarketCatalog
...
reference name=GoodsCatalog multiplicity=0..n
target=StoreMarketFruitsCatalog01 VegetablesCatalogWebService01/
...
/component
So, the relevant parts of the composite look like this now:
...
component name=StoreMarketCatalog
implementation.java class=services.market.MarketCatalogImpl/
property name=currencyCodeUSD/property
service name=Catalog
t:binding.jsonrpc/
/service
reference name=GoodsCatalog multiplicity=0..n
target=StoreMarketFruitsCatalog01 VegetablesCatalogWebService01/
reference name=currencyConverter
target=StoreMarketCurrencyConverter/
/component
component name=StoreMarketFruitsCatalog01
implementation.java class=services.FruitsCatalogImpl/
property name=currencyCodeUSD/property
reference name=currencyConverter
target=StoreMarketCurrencyConverter/
/component
component name=VegetablesCatalogWebService01
binding.ws/
/component
...
Jean-Sebastien mentioned that the approach of hard-coding the components
in the composite would not be needed when using multiplicity. However,
the way I used multiplicity here still requires new stores to be added
to the composite whenever the store wants to add its catalog to the
marketplace.
Jean-Sebastien, is this what you had in mind when you mentioned
multiplicity or am I doing something wrong?
Regards,
Mario
-Original Message-
From: Antollini, Mario [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 6:28 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Tutorial: Adding a Markeplace Scenario
Hello,
I have created the new module and called it store-market (I uploaded
it to JIRA: https://issues.apache.org/jira/browse/TUSCANY-2163)
As Jean-Sebastien suggested I took store-merger and modified it.
I now need to start working on the multiplicity 0..n instead of the
currently hardcoded references to two catalogs.
Regards,
Mario
-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 3:51 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tutorial: Adding a Markeplace Scenario
Antollini, Mario wrote:
Hello jean-Sebastien,
I was thinking about adding a Marketplace scenario to the Tutorial we
will be presenting at JavaOne. By Marketplace I mean doing something
similar to what Amazon does: offering third party retailers' products
via Amazon's site.
I think we can do that by offering multiple catalogs via a proxy
catalog
which consolidates all of them (i.e. data federation).
What do you think? I will be looking the tutorial in detail in order
to
see how I can implement it.
Regards,
Mario
Good idea!
This could be a new module addition under java/sca/tutorial.
You could wire a list of catalogs to a catalog aggregator service
component for example, similar to what the current store-merger module
does but with a reference with multiplicity 0..n instead of the
currently hardcoded references to two catalogs.
The easiest is probably to copy one of the modules (store-merger for
example) into a new store-market or something like that as a starting
point, adjust the POM etc, submit that in a JIRA and then start making
the changes to turn it into a marketplace store.
Let us know if have any questions, issues, or need any help when you do
that.
Thanks!
--
Jean-Sebastien
[jira] Updated: (TUSCANY-2188) New tests for Java @Service annotaion
[ https://issues.apache.org/jira/browse/TUSCANY-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Kwan updated TUSCANY-2188: -- Attachment: patches.2.txt I updated - ServiceAnnotationTestCase.java about the comments - FServiceImpl.java for test atService8 Still want to know, What is the different between interfaces and class ? Are both same? * Line 1637 to 1638: * The service names of the defined services default to the names of the * interfaces or class, without the package name. New tests for Java @Service annotaion -- Key: TUSCANY-2188 URL: https://issues.apache.org/jira/browse/TUSCANY-2188 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Attachments: patch.txt, patches.2.txt, service.zip New tests for Java Common Annotations and APIs Specification of @Service annotation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (TUSCANY-2188) New tests for Java @Service annotaion
[ https://issues.apache.org/jira/browse/TUSCANY-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585175#action_12585175 ] gkwan edited comment on TUSCANY-2188 at 4/3/08 9:38 AM: --- I updated following by patch.2.txt - ServiceAnnotationTestCase.java about the comments - FServiceImpl.java for test atService8 Still want to know, What is the different between interfaces and class ? Are both same? * Line 1637 to 1638: * The service names of the defined services default to the names of the * interfaces or class, without the package name. was (Author: gkwan): I updated - ServiceAnnotationTestCase.java about the comments - FServiceImpl.java for test atService8 Still want to know, What is the different between interfaces and class ? Are both same? * Line 1637 to 1638: * The service names of the defined services default to the names of the * interfaces or class, without the package name. New tests for Java @Service annotaion -- Key: TUSCANY-2188 URL: https://issues.apache.org/jira/browse/TUSCANY-2188 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Attachments: patch.txt, patches.2.txt, service.zip New tests for Java Common Annotations and APIs Specification of @Service annotation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2181) Minor fixes to samples README and .html files
[ https://issues.apache.org/jira/browse/TUSCANY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2181. - Resolution: Fixed Minor fixes to samples README and .html files - Key: TUSCANY-2181 URL: https://issues.apache.org/jira/browse/TUSCANY-2181 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 While reviewing the 1.2 samples, I'm seeing typos and minor issues with the README and some of the .html files. I'll fix the ones I see carefully as I go through them. I'll make the fixes in both trunk and the 1.2 branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA 1.2] Release Status and RC plans
Luciano Resende wrote: Sure, so let me know when you are done, in the meantime I'll try to finish license reviews, etc. I'm done :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2188) New tests for Java @Service annotaion
[ https://issues.apache.org/jira/browse/TUSCANY-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585208#action_12585208 ] Kevin Williams commented on TUSCANY-2188: - Regarding: What is the different between interfaces and class ? Are both same? A service interface can be defined by either a Java Interface or a Java class and the naming default should be the same in either case. So if you used an Interface x.y.z.Calculator or a Class x.y.z.Calculator to define the Service interface then the service name should default to Calculator New tests for Java @Service annotaion -- Key: TUSCANY-2188 URL: https://issues.apache.org/jira/browse/TUSCANY-2188 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Attachments: patch.txt, patches.2.txt, service.zip New tests for Java Common Annotations and APIs Specification of @Service annotation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SDO 1.1 rc3 release
Now the bug seems to be fixed. I think it's ready to be voted : ) Adriano Crestani On Thu, Apr 3, 2008 at 12:49 AM, ant elder [EMAIL PROTECTED] wrote: The RC4a artifacts are now available at http://people.apache.org/~antelder/tuscany/sdo/1.1-RC4a/http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-RC4a/ I'll call a vote on releasing that late today, any reviews in the meantime welcomed. ...ant On Thu, Apr 3, 2008 at 8:58 AM, ant elder [EMAIL PROTECTED] wrote: Ok, i'm doing an RC4a right now to include the TUSCANY-2187 fix, will be up shortly, hopefully you'll have the endurance to try that too :) ...ant On Thu, Apr 3, 2008 at 8:50 AM, Adriano Crestani [EMAIL PROTECTED] wrote: No, I just tested the code you posted at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4 On Wed, Apr 2, 2008 at 11:27 PM, ant elder [EMAIL PROTECTED] wrote: Thats good, looks like we might be just about there now. Just to confirm - were you testing with the code which included the TUSCANY-2187 fix that Raymond had just committed? ...ant On Thu, Apr 3, 2008 at 7:55 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I found the problem. I was running the mvn command on impl folder and getting this failure, and not on the root folder. Strangely, I tried to run the mvn on the impl folder on another environment and it worked : ) It's probably a problem with my environment though So, the RC4 seems OK to me ; ) Adriano Crestani On Wed, Apr 2, 2008 at 9:16 PM, Adriano Crestani [EMAIL PROTECTED] wrote: mvn clean install didn't work either : ( Adriano Crestani On Wed, Apr 2, 2008 at 9:03 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just tried the 1.1-incubating branch with both IBM and SUN JDK 1.5.x. The build was successful. Did you run with mvn clean install? IIRC, when I was playing around different versions of surefire plugin this afternoon, I hit the same problem once in the OSGi test case. It seems to be a bit random. Anyway, I don't think it's a blocker. Thanks, Raymond -- From: Adriano Crestani [EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 9:28 PM To: tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] SDO 1.1 rc3 release Hi, I'm getting a test failure (the maven output below)* : ( *. Am I doing something wrong? Regards, Adriano Crestani --- T E S T S --- Running org.apache.tuscany.sdo.test.DataObjectGetListTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 sec Running org.apache.tuscany.sdo.test.NeverStaleChangeSummaryTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec Running org.apache.tuscany.sdo.test.XPathTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec Running org.apache.tuscany.sdo.test.DynamicTypesComparisonTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.tuscany.sdo.test.ImplSpecificTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.tuscany.sdo.test.HelperContextTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.tuscany.sdo.test.SubstitutionValuesTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.681 sec FA ILURE! Running org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec Running org.apache.tuscany.sdo.test.XMLSaveOptionsTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.154 sec Running org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec Running
[VOTE] SDO 1.1 release
Please review and vote on the SDO 1.1 release RC4a artifacts at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4ahttp://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc3/ The tag for the release is at: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/ KEYS file is at: https://svn.apache.org/repos/asf/incubator/tuscany/KEYS Many thanks to Adriano, Raymond, and Sebb for all their help reviewing and fixing the previous RCs. This one looks good so +1 from me! ...ant
Re: [VOTE] SDO 1.1 release
Note theres a gmail url cutNpaste problem in the url to the artifacts - they are at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4a - ending in 4a, the link in the previous email has the old rc3 url. ...ant On Thu, Apr 3, 2008 at 7:05 PM, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the SDO 1.1 release RC4a artifacts at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4ahttp://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc3/ The tag for the release is at: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/ KEYS file is at: https://svn.apache.org/repos/asf/incubator/tuscany/KEYS Many thanks to Adriano, Raymond, and Sebb for all their help reviewing and fixing the previous RCs. This one looks good so +1 from me! ...ant
Re: [VOTE] SDO 1.1 release
+1 from me ; ) On Thu, Apr 3, 2008 at 10:43 AM, ant elder [EMAIL PROTECTED] wrote: Note theres a gmail url cutNpaste problem in the url to the artifacts - they are at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4ahttp://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4a- ending in 4a, the link in the previous email has the old rc3 url. ...ant On Thu, Apr 3, 2008 at 7:05 PM, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the SDO 1.1 release RC4a artifacts at http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4ahttp://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4a http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc3/ The tag for the release is at: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/ KEYS file is at: https://svn.apache.org/repos/asf/incubator/tuscany/KEYS Many thanks to Adriano, Raymond, and Sebb for all their help reviewing and fixing the previous RCs. This one looks good so +1 from me! ...ant
[jira] Updated: (TUSCANY-2188) New tests for Java @Service annotaion
[ https://issues.apache.org/jira/browse/TUSCANY-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Kwan updated TUSCANY-2188: -- Attachment: FServiceImpl2.zip patches.3.txt patches.3.txt and FServiceImpl2.zip enhances test atService8 * ServiceAnnotationTestCase.java * FServiceImpl.java * service.composite + FServiceImpl2.java p.s. you may ignore patches.2.txt New tests for Java @Service annotaion -- Key: TUSCANY-2188 URL: https://issues.apache.org/jira/browse/TUSCANY-2188 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Attachments: FServiceImpl2.zip, patch.txt, patches.2.txt, patches.3.txt, service.zip New tests for Java Common Annotations and APIs Specification of @Service annotation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Questions on how much Tuscany supports SCA 1.0 Assembly Model Spec section 1.8
Hello, I am interested in knowing how Tuscany supports SCA Assembly Spec 1.0 section 1.8 1.8 SCA Definitions 2491 There are a variety of SCA artifacts which are generally useful and which are not specific to a 2492 particular composite or a particular component. These shared artifacts include intents, policy 2493 sets, bindings, binding type definitions and implementation type definitions. 2494 All of these artifacts within an SCA Domain are defined in a global, SCA Domain-wide file named 2495 definitions.xml. The definitions.xml file contains a definitions element that conforms to the 2496 following pseudo-schema snippet: 2497 ?xml version=1.0 encoding=ASCII? 2498 !-- Composite schema snippet -- 2499 definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; 2500 targetNamespace=xs:anyURI 2501 2502 sca:intent/* 2503 2504 sca:policySet/* 2505 2506 sca:binding/* 2507 2508 sca:bindingType/* 2509 2510 sca:implementationType/* 2511 2512 /definitions What interest me are: 1. on a high level, how many places Tuscany can honor definitions.xml? e.g. definitions.xml is in a system class library, and/or definitions.xml in a contribution that can be contributed to a SCA domain by using aEmbeddedSCADomain.getContributionService().contribute... I remember seeing a thread of discussion, will appreciate a link to the answers . 2. I assume regardless how definitions.xml is introduced into a domain, there is an aggregated view on the intents, policySets, bindings, bindingTypes, implementationTypes supported for the system. Is there some API/SPI somewhere to do a query and return the list? 3. What contents are supported for definitions.xml in Tuscany I understand we can define intents and policySets in definitions.xml today. How about binding , bindingType and implementationType. I understand Tuscany has extension points to register binding types and implementation types. I wonder if/how we plan to support using definitions.xml for implementation type and binding type and how the two will work together. E.g. if definitions.xml can introduce additional binding type or implementation type through contribution, it will mean the implementation of the new bindingType or implementationType can be in a contribution related classLibrary we can add and remove during the lifecycle of a domain... Looking forward to some answers. Yang. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-2188) New tests for Java @Service annotaion
[ https://issues.apache.org/jira/browse/TUSCANY-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Williams closed TUSCANY-2188. --- Resolution: Fixed Fix Version/s: Java-SCA-Next New tests for Java @Service annotaion -- Key: TUSCANY-2188 URL: https://issues.apache.org/jira/browse/TUSCANY-2188 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-SCA-Next Attachments: FServiceImpl2.zip, patch.txt, patches.2.txt, patches.3.txt, service.zip New tests for Java Common Annotations and APIs Specification of @Service annotation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Some questions for workspace module in Tuscany
Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using import namespace The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... 2. Some detailed questions related to what I see in the ContributionSPIsTestCase: I can see contribution can be added to workspace by workspace.getContributions().add(contribution); I am not sure if at this stage I will be able to get the composite model object that I need for scenario 1, or I need to go extra steps to get the Composite model resolved. e.g. I can see some code like: ListContribution dependencies = analyzer.buildContributionDependencies(workspace, workspace.getContributions().get(0)); is it needed for me to get the resolved model or it is just something to play with to get a dependency graph. 3. I can also see getting composite started will have more codes than using domain. One thing I realized that there is no association of a Node to a Domain. (sorry if I missed it ). I would assume the Node will be associated with a SCADomain as then we can call SCADomain.getService to locate the services hosted on the Domain. And also it will make it possible that we can have multiple domain in one single JVM , each may have different contributions , so its hosted services are different and behaviors are different as there can be different definitions.xml in a contribution for intent or policy or others.. // // run the chosen composite SCANode2Factory nodeFactory = SCANode2Factory.newInstance(); SCAContribution contribution0 = new SCAContribution(contributionsToDeploy.get(0).getURI(), contributionsToDeploy.get(0).getLocation()); SCAContribution contribution1 = new SCAContribution(contributionsToDeploy.get(1).getURI(), contributionsToDeploy.get(1).getLocation()); // FIXME - need a more flexible constructor on the node so we can pass in a // dynamic list of contributions SCANode2 node = nodeFactory.createSCANode(chosenDeployableLocation, contribution0, contribution1); node.start(); SCAClient client = (SCAClient)node; CalculatorService calculatorService = client.getService(CalculatorService.class, CalculatorServiceComponentA); 4. Another interest I have is about model validation for contribution or composite. I see another
Re: Verification Testing
I've some test cases for ComponentContext that I would like to contribute. Can someone please help me out with them? Thank you. Yee-Kang Chang/Toronto/[EMAIL PROTECTED] 04/03/2008 12:01 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: Verification Testing Hi Kevin, I would like to contribute to this effort. Thanks! Kevin Williams [EMAIL PROTECTED] 03/19/2008 01:40 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc [EMAIL PROTECTED] Subject Verification Testing I am thinking of adding a new test bucket specifically for verification testing against the specification set. I believe it would add value to the project and may also be a place where developers new to Tuscany might contribute. Does this sound like a reasonable idea? Thanks, --Kevin
[jira] Updated: (TUSCANY-2195) Test cases for ComponentContext API
[ https://issues.apache.org/jira/browse/TUSCANY-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Kang Chang updated TUSCANY-2195: Attachment: ComponentContext.zip Hi Kevin, Attached is my contribution. Please take a look. Thanks. Test cases for ComponentContext API --- Key: TUSCANY-2195 URL: https://issues.apache.org/jira/browse/TUSCANY-2195 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Attachments: ComponentContext.zip Contributions for ComponentContext API testing can be attached here -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Verification Testing
Hi Yee-Kang, I just created TUSCANY-2195 to accept and track testing for ComponentContext. You can attach your contribution there. Thanks, --Kevin On Thu, Apr 3, 2008 at 3:55 PM, Yee-Kang Chang [EMAIL PROTECTED] wrote: I've some test cases for ComponentContext that I would like to contribute. Can someone please help me out with them? Thank you. Yee-Kang Chang/Toronto/[EMAIL PROTECTED] 04/03/2008 12:01 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: Verification Testing Hi Kevin, I would like to contribute to this effort. Thanks! Kevin Williams [EMAIL PROTECTED] 03/19/2008 01:40 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc [EMAIL PROTECTED] Subject Verification Testing I am thinking of adding a new test bucket specifically for verification testing against the specification set. I believe it would add value to the project and may also be a place where developers new to Tuscany might contribute. Does this sound like a reasonable idea? Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2195) Test cases for ComponentContext API
Test cases for ComponentContext API --- Key: TUSCANY-2195 URL: https://issues.apache.org/jira/browse/TUSCANY-2195 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Contributions for ComponentContext API testing can be attached here -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2196) passing Java bean using a JSON binding
passing Java bean using a JSON binding
--
Key: TUSCANY-2196
URL: https://issues.apache.org/jira/browse/TUSCANY-2196
Project: Tuscany
Issue Type: Bug
Components: Java SCA JSON-RPC Binding Extension
Affects Versions: Java-SCA-1.1
Environment: Windows xp2
Reporter: Ashwini Kumar J
Fix For: Java-SCA-Next
The service is exposed over JSON binding and will return a java bean as a
response but as per my knowledge the bean is not properly converted to json
object as shown in the smd below:
{SMDVersion:.1,objectName:EmployeeBOService,serviceType:JSON-RPC,serviceURL:http://localhost:8080/employee-det/EmployeeJSONService,methods:[{name:fetchEmployeeData,parameters:[{name:param0,type:STRING}]}]}
Response:
[object Object]
Console output is:
Apr 4, 2008 11:23:07 AM com.metaparadigm.jsonrpc.BeanSerializer analyzeBean
INFO: analyzing com.infosys.poc.employeedata.EmployeeData
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
