[jira] Created: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SCA 1.2.1 release
Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . -- Thanks Nishant Joshi
[jira] Commented: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598229#action_12598229 ] Mike Edwards commented on TUSCANY-2328: --- Ashwini, Thanks for catching this one. Do you have a test case that shows this problem, please? I'd be very grateful if you could attach it to this JIRA. equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards reassigned TUSCANY-2328: - Assignee: Mike Edwards equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani Assignee: Mike Edwards In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2329) itests for validation messages
[ https://issues.apache.org/jira/browse/TUSCANY-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2329: - Attachment: TUSCANY-2329-Part1.patch itests for validation messages -- Key: TUSCANY-2329 URL: https://issues.apache.org/jira/browse/TUSCANY-2329 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2329-Part1.patch itests for validation messages introduced through monitors (with TUSCANY-2277) for various processors during read and resolve phase of the composite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2329) itests for validation messages
itests for validation messages -- Key: TUSCANY-2329 URL: https://issues.apache.org/jira/browse/TUSCANY-2329 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next itests for validation messages introduced through monitors (with TUSCANY-2277) for various processors during read and resolve phase of the composite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: TUSCANY-2277 validation messages
Thanks Simon, itests for these validation messages are now available with TUSCANY-2329. On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote: I've just checked in Ram's patch to convert validation messages (i.e. those messages indicating that the user have provided invalid input of some form) to resource bundles and pass them through the Monitor. We need to take account of this change as we change or add code to do with validation. Primarily the change; - Pushes down a Monitor object to various parts of code that produce validation type messages. - Creates a problem object to hold any reported warning or error (sometimes there a convenience error() or warning() operation has been added if there are a lot of messages in a file) -- Each problem is identified by an id string -- The id string references into a resource bundle where the full message has been moved to. There is now a resource bundle in each module that raises validation messages - Passes the Problem on to the Monitor object Our default Monitor object simply passes the message to the JDK logger at the moment but you could imagine a Monitor that collects them all together for later analysis. Currently the majority of the exceptions that are thrown during validation are still there so I guess we need to go through taking out the ones that are not now absolutely necessary. The next job! With this done we have catalogs of all of the errors/warnings that a user is likely to come across (and examples of why the occur in the validation itests) which should help our documentation somewhat. Big thanks to Ram Simon -- Thanks Regards, Ramkumar Ramalingam
Re: SCA 1.2.1 release
Nishant Joshi wrote: Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . Hi Nishant, The work to fix TUSCANY-2251 has turned out bigger than expected. It's one of those cases where the first 80%-90% can be done quite quickly but supporting the final 10%-20% of cases turns up many issues, some of which require changes in other parts of the code. I'm preparing a (large) checkin to update the new generator code so that it handles most of the cases (perhaps 95%). This should be enough to get the full build to run with the new code. However, I wouldn't consider the new code to be ready to release at that point. It will need quite a bit of further testing and a few more updates to take care of the remaining 5% of cases. Some of these cases will require discussion on the list to agree how they should be handled. Also, the new code will need testing by people other than myself with their scenarios to make sure that it does not break cases that worked with the previous Java2WSDL generator. For all these reasons, I think it will take about another 3 weeks to get the new generator code to the state that I would be happy to see it enabled in a release. Regarding TUSCANY-2304, from other emails I see that Ant has sent you a patched version of tuscany-sca-all-1.2-incubating.jar that contains the fix for your problem. Can you explain why you need a new release in addition to this patch? Simon
[jira] Created: (TUSCANY-2330) Calculator sample running in OSGi
Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Small OSGi sample for the main build?
I've submitted a patch to add the sample (Jira 2330). 2008/5/20 ant elder [EMAIL PROTECTED]: Sounds good to me. ...ant On Mon, May 19, 2008 at 9:50 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, I now have the Calculator sample running using all the great work Rajini did to use Equinox, 1 bundle per third-party library, and absolute jar paths. It results in 119 bundles, uses 19MB and takes about 50 seconds to run. If folks are ok with this, I will create a Jira and submit it as a patch for inclusion in the samples main build. Regards, Graham. 2008/5/19 Graham Charters [EMAIL PROTECTED]: Hi Rajini, 2008/5/18 Rajini Sivaram [EMAIL PROTECTED]: Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. That's great, thanks! I'll take a look and give it a go with the Calculator sample. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. I agree about the performance point. I think 1 minute is a small sacrifice. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. I noticed you'd switched over. I'll try the same. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment,
[jira] Updated: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Charters updated TUSCANY-2330: - Attachment: calculator-osgi-sample.patch Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next Attachments: calculator-osgi-sample.patch Original Estimate: 2h Remaining Estimate: 2h It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2283) Conversation should end due to non-business exception
[ https://issues.apache.org/jira/browse/TUSCANY-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-2283. - Resolution: Fixed Fix committed at r658275. I've enabled the vtest also. Conversation should end due to non-business exception - Key: TUSCANY-2283 URL: https://issues.apache.org/jira/browse/TUSCANY-2283 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Laws Fix For: Java-SCA-Next The Java APIs and Annotations spec states: 487 A conversation ends, and any state associated with the conversation is freed up, when: ... 492 • Any non-business exception is thrown by a conversational operation This is not happening as illustrated by the vtest: org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.LifetimeTestCase.lifetime11 It is currently @Ignore(d) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2331) Got expection where the wsdl defines an operation without input
Got expection where the wsdl defines an operation without input --- Key: TUSCANY-2331 URL: https://issues.apache.org/jira/browse/TUSCANY-2331 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Gilbert Kwan Got following exception in running where the wsdl defines an operation without input parameter. java.lang.IllegalArgumentException: Pass-by-value is not supported for the given object at org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy(JavaBeansDataBinding.java:102) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.copy(DefaultDataBindingExtensionPoint.java:171) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:235) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copyFault(PassByValueInterceptor.java:130) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:115) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy7.getB1Name(Unknown Source) at org.apache.tuscany.sca.vtest.wsbinding.nowsdl.NoWsdlTestCase.testNoWsdl(NoWsdlTestCase.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.NotSerializableException: org.apache.axiom.om.impl.llom.OMElementImpl at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1113) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1439) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1382) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414) at java.lang.Throwable.writeObject(Throwable.java:320) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:972) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1431) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1382) at
[jira] Updated: (TUSCANY-2331) Got expection where the wsdl defines an operation without input
[ https://issues.apache.org/jira/browse/TUSCANY-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Kwan updated TUSCANY-2331: -- Attachment: BService.wsdl Got expection where the wsdl defines an operation without input --- Key: TUSCANY-2331 URL: https://issues.apache.org/jira/browse/TUSCANY-2331 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Gilbert Kwan Attachments: BService.wsdl Got following exception in running where the wsdl defines an operation without input parameter. java.lang.IllegalArgumentException: Pass-by-value is not supported for the given object at org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy(JavaBeansDataBinding.java:102) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.copy(DefaultDataBindingExtensionPoint.java:171) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:235) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copyFault(PassByValueInterceptor.java:130) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:115) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy7.getB1Name(Unknown Source) at org.apache.tuscany.sca.vtest.wsbinding.nowsdl.NoWsdlTestCase.testNoWsdl(NoWsdlTestCase.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.NotSerializableException: org.apache.axiom.om.impl.llom.OMElementImpl at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1113) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1439) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1382) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414) at java.lang.Throwable.writeObject(Throwable.java:320) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at
[jira] Commented: (TUSCANY-2331) Got expection where the wsdl defines an operation without input
[ https://issues.apache.org/jira/browse/TUSCANY-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598337#action_12598337 ] Gilbert Kwan commented on TUSCANY-2331: --- Surely will do it later. Understand that the limited information at the description may not enough, but just hope someone can look into it in advance if possible. Thanks Got expection where the wsdl defines an operation without input --- Key: TUSCANY-2331 URL: https://issues.apache.org/jira/browse/TUSCANY-2331 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Gilbert Kwan Attachments: BService.wsdl Got following exception in running where the wsdl defines an operation without input parameter. java.lang.IllegalArgumentException: Pass-by-value is not supported for the given object at org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy(JavaBeansDataBinding.java:102) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.copy(DefaultDataBindingExtensionPoint.java:171) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:235) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copyFault(PassByValueInterceptor.java:130) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:115) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy7.getB1Name(Unknown Source) at org.apache.tuscany.sca.vtest.wsbinding.nowsdl.NoWsdlTestCase.testNoWsdl(NoWsdlTestCase.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.NotSerializableException: org.apache.axiom.om.impl.llom.OMElementImpl at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1113) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1439) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1382) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1467) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414) at java.lang.Throwable.writeObject(Throwable.java:320) at
Re: [DISCUSS] Declaring extensions as being available in the domain
Thanks thats helpful. Let me take this to the extreme so you can point out where it loses the plot to help me understand what you're saying: The idea is eventually there might be standardized interfaces for all the SCA runtime plug points, many of the Tuscany things for the various SCDL and SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have in org.apache.tuscany.sca namespace might one day be standardized interfaces, just like the org.osoa.sca.* interfaces for application Java implementations to use, and there would be a standard way to define new binidng and implementation extensions in the definitions.xml. Anyone could make an SCA contribution that would add a binding or implementation type which once contributed to an SCA domain then other contributions in the domain could use in their SCA assemblies. And this new binding contribution would work in any runtime that supported SCA just like application SCA contributions should. So as a simple example, say a file binding that component service or references could use to read and write to a file system. That could be packaged in a regular jar which has a meta-inf/definitions.xml along the lines of: definitions ... bindingType type=binding.file ... ...elements and attributes defining the binding.file schema and implementation classes ... /bindingType /definitions and all the file binding implementation classes within that file binding contribution jar would implement only standard interfaces, nothing at all Tuscany specific in the contribution. The splitting out all the various Tuscany SCDL classes and SPIs points into interfaces happened when we did the 0.90 rewrite so binding and implementation type extensions can now be written using only interfaces, but the pluggablity mechanism is still quite Tuscany specific. So is whats being suggested with this definitions.xml work starting on the road to coming up with a less Tuscany specific way of doing that, it would still be in a Tuscany namespace for now just as the various Tuscany SPI interfaces are, but in the future all this would be defined in some SCA spec , but it would just be a refactor in Tuscany to move to that spec namespace instead of a complete rewrite? Is that anything like what you had in mind? ...ant On Thu, May 15, 2008 at 7:32 PM, scabooz [EMAIL PROTECTED] wrote: I might be the 'they', not sure. This is a very hard email thread to follow so let me try to articulate some ideas. First, bindingType and implementationType were introduced by the SCA Policy FW spec because that spec was the first to need a bit of metadata describing bindings from a typing perspective so that policy could be provided by the type and didn't have to be repeated on every binding instance. Implementation types was an obvious next stop on the journey. The text was driven into the Assembly spec as the result of a realization that these two concepts would be needed by SCA extenders who wish to add bindings and new kinds of components into any SCA runtime that was implemented by some another party. The assembly spec group decided (rightly IMHO) NOT to dive more deeply into filling out these concepts in V1.0. It would be more appropriate to tackle these sorts of issues in a future revision of the technology. Second, Tuscany is an open community where the plethora of talent enables new innovative ideas to be explored. These extensibility points are a great place for Tuscany to experiment with different approaches. I think it would be fantastic if Tuscany could finish the work of the spec group and come up with a reasonable (and workable) model for extensibility and then propose it to the spec group. Building on this thought then is the assertion that bindingType is the starting point for 3rd parties to describe a binding implementation to a runtime not authored by the binding implementer. It would be naive to think that the current structure of bindingType, it's containment within a defintions.xml file or any other related aspect is off limits from change in this experiment. I'm not clear on what all the issues are that have been raised. I see a lot of mis-information and some emotion that's hard to sort through. I saw a strawman that looked like a good start in one of the emails but there seemed to be resistance that I didn't understand. The SCA bindingType and implementationType concepts have nothing to do with policy. Policy was the first functional area that happened to see the need for them. Dave - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 13, 2008 2:40 AM Subject: Re: [DISCUSS] Declaring extensions as being available in the domain On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though it is at the
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598433#action_12598433 ] Rajini Sivaram commented on TUSCANY-2330: - Graham, For some reason, I was expecting this to be an itest, but I notice you intended it to be a sample. That is good, since we currently dont have a sample which runs Tuscany under OSGi. So this module can be a sample as well as a sniff test for OSGi-based Tuscany. However, to enable this to be really used as a sample, it might help if code was simplified. Currently it uses the test harness from itest/osgi-tuscany which builds test bundles on-the-fly from the classes in the samples directories. I feel that is too complicated for use in a sample (yes, that is all my fault). It would be really nice to have a sample which simply does: 1. Create an OSGi runtime 2. Install and start Tuscany OSGi installer bundle 3. Install and start calculator bundle and away it goes and runs the calculator sample on Tuscany inside an OSGi runtime. Step 2 could be replaced later with whatever mechanism we choose to provide for installing Tuscany into OSGi. What do you think? I can help with the code if you like (but it will have to wait till the weekend). PS: Sorry, I should have noticed that you were referring to this as 'sample' all along. - Rajini Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next Attachments: calculator-osgi-sample.patch Original Estimate: 2h Remaining Estimate: 2h It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration
So, in the case where we replace the ODE Process Store module with one implemented by Tuscany, is this new module going to be responsible for handling all the versioning and matching a running process instance with the right BPEL process version ? Also, can the modules that handle deploy.xml and process store be implemented separately (e.g Tuscany would handle deploy.xml but still use ode process store module) ? Thanks Luciano On Mon, May 19, 2008 at 11:23 AM, Matthieu Riou [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 9:11 AM, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I am interested in getting rid of the need to have a physical deploy.xml file in the directory with a BPEL process file. Can I supply the same information to the ODE runtime through some other means, such as method parameters or some in-memory mechanism? The short answer is: yes, you can. The long answer is... a bit longer :) For the SCA integration, the SCA runtime has all the information contained in the deploy.xml file, but in another form. It would be great to relieve the developers from the need to create this file. Let me explain a bit how that works. The ODE runtime doesn't know anything about the file system, descriptors or even BPEL files. It just knows that something is supposed to call it, passing an interface implementation (ProcessConf [1]) that provides everything it needs (and a bit more actually). It's so dumb that it doesn't even know which processes it should know about, so every time the server is restarted, it expects to be called again with the same process definition information. Parrallely in ODE we have a process store that handles all the nitty gritty details of knowing where is what in which version and remembering it. The process store doesn't know about the runtime and the runtime doesn't know about the store. The advantage is that, in theory, you could pick different clustering models (one store / multiple servers, multiple stores / multiple servers) depending on how you want things to be arranged. The other advantage is that you can get rid of the store altogether if you have all the necessary information. When a new process is deployed (or undeployed, or retired, or ...), the store just produces an event. Same thing when the whole server is restarted, the store produces several events for each process the runtime should know about. These events are just relayed by the Integration Layer that binds the store and the runtime and implements external communication (all the interfaces Luciano has implemented). Getting back to Tuscany, what I'm thinking is that we should remove the store (and its events) from the equation. Tuscany would just let the runtime know when when a process is available by calling BpelServer.register(ProcessConf), providing its own implementation of ProcessConf. The current Tuscany integration layer already has a reference to the BpelServer, so that's easy. The caveat is that in this case, Tuscany will also need to compile the .bpel file to provide the CBP (Compiled Business Process) but that's fairly painless (see DeploymentUnitDir.compile(File) [2]). The net advantage of this for Tuscany will be a much better integration and much more control over the process lifecycle. So let me know what you think and I can help with your ProcessConf implementation. Cheers, Matthieu [1] http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ProcessConf.java [2] http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/DeploymentUnitDir.java Yours, Mike Edwards Apache Tuscany team. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration
Luciano Resende wrote: So, in the case where we replace the ODE Process Store module with one implemented by Tuscany, is this new module going to be responsible for handling all the versioning and matching a running process instance with the right BPEL process version ? Also, can the modules that handle deploy.xml and process store be implemented separately (e.g Tuscany would handle deploy.xml but still use ode process store module) ? Thanks Luciano Luciano, My reading of Matthieu's note is that what is necessary is simply that Tuscany must implement a ProcessConf class, rather than the whole process store. That can be prepared entirely from information which Tuscany has to hand, although as Matthieu points out, there are complex details within the ProcessConf implementation that will require us to re-use some ODE modules that compile the BPEL process file, but he says that doing that will not be too hard ;-) With Tuscany, the Process Store is not needed since Tuscany has the Domain configuration to drive things. Yours optimistically, Mike.
[jira] Resolved: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-2328. --- Resolution: Fixed Fix committed in 658449. Changed BPELImplementationProcessor to compare the QNames of the PortTypes using equals() rather than comparing the PortType elements themselves. equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani Assignee: Mike Edwards In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Running Tuscany/SCA in Google Android mobile platform
Hi Adriano, I was indeed using the sca modules not from the sandbox. As you suggested, I removed the tuscany-contribution-impl from my workspace and added the version you uploaded to the sandbox. Then, I uncommented the lines in org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator following the comments pointing out why those lines had been commented. I'm no longer getting the ClassNotFoundException. However, it's getting stuck somewhere else (before getting there I guess)...I think this is the case because before and after commenting the code I get the same error in the Android emulator, an InstantiationException [1]. I also started tinkering with retrotranslator. First I tried doing it with Ant, but it seems that in order to build I have to include the whole tuscany projects in a way similar to how I now have in Eclipse. I also tried making a jar out of org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator and then feeding it to retrotranslator but unfortunately it's not translating anything, as shown below. Voyager-2:Retrotranslator-1.2.6-bin ocastaneda$ java -jar retrotranslator-transformer-1.2.6.jar -srcjar JavaRuntimeModuleActivator.jar -target 1.5 -reflection safe -stripannot -classpath retrotranslator-android-1.2.6.jar Processing 136 file(s) in JavaRuntimeModuleActivator.jar. Transformed 0 file(s). There's also a maven plugin, so I might try that...but first I'll give Ant another go. Hopefully Google will release a new SDK soon, otherwise as you say...retrotranslator will have to be the workaround to proceed with our project ;-) Thanks again for all your help...I'm getting ready for the official start :-) [1] http://androidindelft.googlepages.com/20may2008.html On Fri, May 16, 2008 at 12:20 PM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Oscar, My mistake again, the eclipse project files of contribution-impl module were not uploaded, so you are probably using the modules you have downloaded from the sca modules. If you remove the tuscany-contribution-impl from your workspace and add this module from the sandbox it will probably work. Anyway, you will need to update your trunk again to get the project files I'm uploading right now ; ) OK, if you wanna try the retrotranslator as a solution here is a tip: most of the code that were using the Reflection API was commented on org.apache.tuscany.sca.implementation.java.module.JavaRuntimeModuleActivator class, you just need to edit this class and remove the commented code (it's described there). So, if you uncomment the code and the retrotranslador successfuly work, and I hope it will, you will reach the org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider constructor and it should run OK. Exactly on this constructor I'm getting a NPE when the code described above is commented. About the ant, go on and use it. Further we can evaluate better where we place it in the entire SCA build process. BTW, we even dont know if we will still be using the retrotranslator in future, right?! : ) Use the retrotranslator may help us a lot to workaround this problem for now and go on with our project ; ) Kind Regards, Adriano Crestani On Wed, May 14, 2008 at 2:57 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi Adriano, Thanks alot for your answers. I was able to build the entire workspace from your instructions. When running calculator-android as an Android application I'm getting a ClassNotFoundException [1] for org.apache.tuscany.sca.contribution.processor.impl.DexContributionProcessor. Is the exception you referred to in your original email? ...when you run the calculator-android project as an Android application you should get an exception, that was generated initially by a NPE thrown by org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider constructor. This is caused because the latest Android SDK does not support the Reflection API yet. So, the SCA cannot check the @Reference annotations (I commented the code which tries to read the annotations, so when the execution reach this constructor it throws the NPE). Searching for the class in the exception I'm getting I found org.apache.tuscany.sca.extensibility.ServiceDiscovery. In getServiceClasses it loads the service class I'm getting problems with when running calculator-android as an Android application: org.apache.tuscany.sca.contribution.processor.impl.DexContributionProcessor;type=application/x-dex I couldn't find the corresponding java file in my imported workspace and found that there is no package like org.apache.tuscany.sca.contribution.processor.impl. Am I missing something? Or are these the errors you would expect? I would like to get to the point where I get the exception you described and try to run retrotranslator from there. However, as I'm using the ADT plugin in eclipse
Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration
On Tue, May 20, 2008 at 2:12 PM, Mike Edwards [EMAIL PROTECTED] wrote: Luciano Resende wrote: So, in the case where we replace the ODE Process Store module with one implemented by Tuscany, is this new module going to be responsible for handling all the versioning and matching a running process instance with the right BPEL process version ? Also, can the modules that handle deploy.xml and process store be implemented separately (e.g Tuscany would handle deploy.xml but still use ode process store module) ? Thanks Luciano Luciano, My reading of Matthieu's note is that what is necessary is simply that Tuscany must implement a ProcessConf class, rather than the whole process store. That can be prepared entirely from information which Tuscany has to hand, although as Matthieu points out, there are complex details within the ProcessConf implementation that will require us to re-use some ODE modules that compile the BPEL process file, but he says that doing that will not be too hard ;-) With Tuscany, the Process Store is not needed since Tuscany has the Domain configuration to drive things. What mike says. I should just add that picking the right process version depending on what's already executing is handled by the runtime. The only thing that it will need is to know what is the definition for all the process versions that are still around (haven't been undeployed). You just need to keep these artifacts around and feed them to the engine (by calling register) as long as they're needed. If you want, I can code the method that compiles the BPEL file if you give me a signature that gets the file as parameter (I don't know how you would look it up in the filesystem). Cheers, Matthieu Yours optimistically, Mike.
Re: [DISCUSS] Declaring extensions as being available in the domain
Responses inline...for some reason my email client is mishandling the formatting, so I'll mark my responses with dab /dab Dave - Original Message - From: ant elder To: scabooz Cc: tuscany-dev@ws.apache.org Sent: Tuesday, May 20, 2008 2:03 PM Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Thanks thats helpful. Let me take this to the extreme so you can point out where it loses the plot to help me understand what you're saying: The idea is eventually there might be standardized interfaces for all the SCA runtime plug points, many of the Tuscany things for the various SCDL and SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have in org.apache.tuscany.sca namespace might one day be standardized interfaces, just like the org.osoa.sca.* interfaces for application Java implementations to use, and there would be a standard way to define new binidng and implementation extensions in the definitions.xml. dab Yes, that is the idea/theory. /dab Anyone could make an SCA contribution that would add a binding or implementation type which once contributed to an SCA domain then other contributions in the domain could use in their SCA assemblies. And this new binding contribution would work in any runtime that supported SCA just like application SCA contributions should. dab yes /dab So as a simple example, say a file binding that component service or references could use to read and write to a file system. That could be packaged in a regular jar which has a meta-inf/definitions.xml along the lines of: definitions ... bindingType type=binding.file ... ...elements and attributes defining the binding.file schema and implementation classes ... /bindingType /definitions and all the file binding implementation classes within that file binding contribution jar would implement only standard interfaces, nothing at all Tuscany specific in the contribution. dab Good. Only thing to add at this point is that the spec might decide that the jar should be an OSGI bundle. Would such a estriction help, or get in the way? /dab The splitting out all the various Tuscany SCDL classes and SPIs points into interfaces happened when we did the 0.90 rewrite so binding and implementation type extensions can now be written using only interfaces, but the pluggablity mechanism is still quite Tuscany specific. So is whats being suggested with this definitions.xml work starting on the road to coming up with a less Tuscany specific way of doing that, it would still be in a Tuscany namespace for now just as the various Tuscany SPI interfaces are, but in the future all this would be defined in some SCA spec , but it would just be a refactor in Tuscany to move to that spec namespace instead of a complete rewrite? dab Bingo. /dab Is that anything like what you had in mind? ...ant On Thu, May 15, 2008 at 7:32 PM, scabooz [EMAIL PROTECTED] wrote: I might be the 'they', not sure. This is a very hard email thread to follow so let me try to articulate some ideas. First, bindingType and implementationType were introduced by the SCA Policy FW spec because that spec was the first to need a bit of metadata describing bindings from a typing perspective so that policy could be provided by the type and didn't have to be repeated on every binding instance. Implementation types was an obvious next stop on the journey. The text was driven into the Assembly spec as the result of a realization that these two concepts would be needed by SCA extenders who wish to add bindings and new kinds of components into any SCA runtime that was implemented by some another party. The assembly spec group decided (rightly IMHO) NOT to dive more deeply into filling out these concepts in V1.0. It would be more appropriate to tackle these sorts of issues in a future revision of the technology. Second, Tuscany is an open community where the plethora of talent enables new innovative ideas to be explored. These extensibility points are a great place for Tuscany to experiment with different approaches. I think it would be fantastic if Tuscany could finish the work of the spec group and come up with a reasonable (and workable) model for extensibility and then propose it to the spec group. Building on this thought then is the assertion that bindingType is the starting point for 3rd parties to describe a binding implementation to a runtime not authored by the binding implementer. It would be naive to think that the current structure of bindingType, it's containment within a defintions.xml file or any other related aspect is off limits from change in this experiment. I'm not clear on what all the issues are that have been raised. I see a lot of mis-information and some emotion that's hard to sort
[GSoC] Coding phase Project Guidelines Suggestions
Just a reminder that the Coding Phase starts next week (May 27th). I'd like to encourage mentors to get their students in the release early, release often mode, and get patches submitted very frequently (every day or every other day)... This would also make review process much easier, as the amount of changes would be smaller. Also, we should all be maintaining technical discussion related to the GSoC projects in the public development mailing lists as this would help other members on the community to get involved, and jump with suggestion that can improve the final result of the GSoC project. Thanks -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: [GSoC] Next Steps for Students - Apache CLA
Looks like we are still missing CLA from : - Douglas Siqueira Leite - Haibo Zhao Have you guys submitted them already ? On Tue, May 6, 2008 at 4:11 AM, Wojtek Janiszewski [EMAIL PROTECTED] wrote: Hi Luciano, I've submitted CLA and now my full name (Wojciech Janiszewski) is listed on Unlisted CLAs Thanks, Wojtek 2008/4/30 Luciano Resende [EMAIL PROTECTED]: The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement (CLA). After some ASF wide discussions, its a common understanding that the students participating on the GSoC 2008 should sign a CLA. Please follow the link to Apache Licenses page [1], and look for Contributor License Agreements and follow the instructions to submit your CLA [2]. Please let us know when your name is listed on Unlisted CLAs section on the committers page [3]. [1] http://www.apache.org/licenses/ [2] http://www.apache.org/licenses/icla.txt [3] http://people.apache.org/~jim/committers.html -- 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/
