[jira] Commented: (TUSCANY-2166) Tuscany eclipse library buildpath exceeds max Windows command line length
[ https://issues.apache.org/jira/browse/TUSCANY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583555#action_12583555 ] Jean-Sebastien Delfino commented on TUSCANY-2166: - For this to work, I need to make a small change to the node launcher to allow test programs for example to get an SCA node from the launcher instead of creating the SCA node directly (as creating the SCA node directly would again require all the runtime JARs to be on their Eclipse buildpath or runtime classpath). Tuscany eclipse library buildpath exceeds max Windows command line length - Key: TUSCANY-2166 URL: https://issues.apache.org/jira/browse/TUSCANY-2166 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Adding the Tuscany library from the Tuscany Eclipse plugin to a Java project breaks it as its buildpath exceeds the limit of the Windows command line length, preventing any programs to be launched from that project. The fix is pretty simple, all the runtime JARs configured in the Tuscany library should not be there anyway. Only the API JARs and the node launcher JAR need to be on the buildpath. -- 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]
TUSCANY-2166 - Tuscany plugin buildpath issues on Windows
The buildpath configured by the Tuscany plugin causes issues on Windows, as it currently places all the runtime JARs on the path of the Eclipse library created for the Tuscany runtime, and that path then exceeds the length of the Windows command line (preventing programs to be launched from a project using the Tuscany library). I am working on it (see the comments in JIRA TUSCANY-2166) and hoping to get a proper fix for that issue before the next RC. Luciano, when are you planning to cut it? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2167) Cleanup SCA Sample dependencies
Cleanup SCA Sample dependencies --- Key: TUSCANY-2167 URL: https://issues.apache.org/jira/browse/TUSCANY-2167 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29677.html -- 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]
[SCA 1.2] Release Status and RC plans
I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 -- 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: TUSCANY-2166 - Tuscany plugin buildpath issues on Windows
I have just created a Release Status and RC plans thread, we can discuss the plans to cut the next rc there. On Sun, Mar 30, 2008 at 11:20 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: The buildpath configured by the Tuscany plugin causes issues on Windows, as it currently places all the runtime JARs on the path of the Eclipse library created for the Tuscany runtime, and that path then exceeds the length of the Windows command line (preventing programs to be launched from a project using the Tuscany library). I am working on it (see the comments in JIRA TUSCANY-2166) and hoping to get a proper fix for that issue before the next RC. Luciano, when are you planning to cut it? -- 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA 1.2] SCA Sample dependencies
I have created TUSCANY-2167 to track this issue, and I'm now evaluating our calculator sample, and calculator-webapp sample to see where all the dependencies are coming from. One thing I noticed is that policy-xml is bringing a lot of ws-security related dependencies to these applications, and I'm now trying to move this dependencies to a policy-xml-ws module that would be available only when the application is using the ws-binding. I'd also take a look in other dependencies and see if I can cleanup them before our next RC. Please let me know if you have questions and/or comments. [1] https://issues.apache.org/jira/browse/TUSCANY-2167 On Fri, Mar 28, 2008 at 6:42 PM, haleh mahbod [EMAIL PROTECTED] wrote: Should this mvn command be put in the development guide for samples so anyone creating a new sample runs these commands and gets rid of unnecessary dependencies? On 3/28/08, Raymond Feng [EMAIL PROTECTED] wrote: Try mvn dependency:analyze. It analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, March 28, 2008 1:02 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA 1.2] SCA Sample dependencies Luciano Resende wrote: I was looking at some sample applications dependencies last night, and realized that our simple calculator-webapp is huge and with a lot of unnecessary dependencies being dragged to it's WEB-INF\lib. This might cause the impression that SCA is heavy, when it's not. Should we spend some time around reviewing these dependencies before next RC ? +1 I'd suggest to start with calculator (not even the webapp version), I can see dependencies on Xalan, Xerces, Axiom there, no idea why they are required. I've traced Xalan to assembly-xml, and removing it from the pom doesn't seem to break it. I think we need a thorough review of the dependencies that have progressively been added to the core runtime, and see if they're all really needed or just oversights that can be cleaned up. -- 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] -- 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]
[jira] Created: (TUSCANY-2168) Incorrect level of commons-httpclient in distribution
Incorrect level of commons-httpclient in distribution - Key: TUSCANY-2168 URL: https://issues.apache.org/jira/browse/TUSCANY-2168 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Priority: Critical Fix For: Java-SCA-1.2 When I build the distribution I get commons-httpclient-2.0.1 in the distro lib. The bindings that use that the httpclient require commons-httpclient-3.0.1 and fail with various exceptions like ClassNotFound and NoSuchMethod. -- 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-1659) SDO DateConversion test cases fail under linux
[ https://issues.apache.org/jira/browse/TUSCANY-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583587#action_12583587 ] Adriano Crestani commented on TUSCANY-1659: --- These failures have nothing to do with Linux at all. It's failing because when the Date object is formatted by a SimpleDateObject, the time zone is formatted as GTM +-HH:mm format, and not as the abbreviation format (for example: PDT). However, the DataHelperImpl.toDate() is expecting a time zone formatted only as abbreviation, probably because the sdo date format defines it on its spec, but it's not really clear about it. Unfortunately, it seems you cannot define whether the time zone is formatted as GMT format or abbreviation format. It seems env-dependent, because I'm getting the same problem on Windows XP. On XP, the problem seems to be a bug reported at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6390869. It happens when you check or not the option 'Automatically adjust clock for daylight saving changes' on XP date/time settings, when it's checked, the time zone is formatted as abbreviation, otherwise it's formatted as GMT format. I think there are 2 solutions, I could replace the GMT +-HH:mm format by the abbreviation format on the String returned by the SimpleDateFormat.format() method, but it would fix only the testcases, and each SDO user will still get trouble with it. Or I can modify the toDate() method to also accept the GMT format, but I'm not sure it would be according SDO spec. I have raised some question about whether SDO should accept GMT format or not at: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29706.html Adriano Crestani SDO DateConversion test cases fail under linux -- Key: TUSCANY-1659 URL: https://issues.apache.org/jira/browse/TUSCANY-1659 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Linux Ubuntu 7.0.4 Reporter: Luciano Resende Assignee: Adriano Crestani Fix For: Java-SDO-Next Attachments: tuscany-1659.tgz The following tests are failing under revision #571238 Tests in error: testConversionsFromDate(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromDateTime(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromDuration(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromYear(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromYearMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromYearMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) Looks like working ok in windows. -- 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-2169) Saxon download does not work when you are not using the default Maven local repository directory
Saxon download does not work when you are not using the default Maven local repository directory Key: TUSCANY-2169 URL: https://issues.apache.org/jira/browse/TUSCANY-2169 Project: Tuscany Issue Type: Bug Components: Build System Environment: SVN trunk revision 642924 Linux Reporter: Mark Combellack Assignee: Mark Combellack Priority: Minor Fix For: Java-SCA-Next By default, Maven uses the directory home/.m2/repository (where home is your home directory) for it's local repository. Maven also supports using a user specified local repository directory using the -Dmaven.repo.local=/some/other/directory on the Maven command line. The Saxon module will download the required release of Saxon and copy it into the Maven local repository. However, this does not work if you are using a custom local Maven repository directory. -- 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: GSoC project idea - Tuscany SCA support in the Geronimo Admin console
Hi, First of all, I would like to thank the tuscany community for the massive support given me to improve my proposal. I applied the modifications recommended in this thread. I updated the wiki page[1] and the Google Web App. Hopefully this will be the finalized proposal. But your ideas and comments are gladly welcome, since we have few more hours to wrap up. thanks! /thilina [1] - http://wiki.apache.org/general/ThilinaBuddhika/GSoC2008/Tuscany_SCA_Support_in_the_Geronimo_Admin_Console On Mon, Mar 31, 2008 at 9:55 AM, Thilina Buddhika [EMAIL PROTECTED] wrote: Hi Jean-Sebastien, thanks a lot for the feedback. Absolutely it is really helpful. I'll work on the improvements suggested by you. thanks! /thilina On Mon, Mar 31, 2008 at 3:49 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Thilina Buddhika wrote: Hi, I have done some slight modifications to the proposal. I will keep on improving it in next two days, as I am getting more feedback from the community and I am digging more into Tuscany and Geronimo. I submitted it as a proposal for GSoC. I will keep the Apache wiki page [1] up to date with the modifications I will be doing to the proposal, so that everyone can review it. thanks! / thilina [1] - http://wiki.apache.org/general/ThilinaBuddhika/GSoC2008/Tuscany_SCA_Support_in_the_Geronimo_Admin_Console Hi Thilina, The proposal looks really good to me! I just have a few minor comments and ideas. An SCA domain contains the following: - SCA contributions - a domain composite configuring and assembling top level SCA components - policy configuration - an allocation of SCA components to nodes/runtimes An SCA domain admin application should ideally cover these four aspects. I'll let you think about how you want to stage them in the project. A comment on an SCA domain is hosted on an application server runtime like Geronimo. Although a domain admin application can be hosted on a single app server like Geronimo, an SCA domain is wider than a single runtime, as SOA solutions usually involve more than a single central JEE server :), with components distributed on multiple runtimes in a network (Geronimo, Tomcat, standalone Tuscany, other app servers etc.). So for a simple and friendly user experience, the domain administrator should be able to deploy, validate, start/stop components running on other runtimes in the domain, directly from your Geronimo-based admin application, without having to juggle with the other admin applications of the individual servers. I think that it will really make a big difference in terms of usability. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2166) Tuscany eclipse library buildpath exceeds max Windows command line length
[ https://issues.apache.org/jira/browse/TUSCANY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2166. - Resolution: Fixed Fixed in SVN revision 642941. Eclipse projects now only have the API and launcher JARs on their buildpath. Tuscany eclipse library buildpath exceeds max Windows command line length - Key: TUSCANY-2166 URL: https://issues.apache.org/jira/browse/TUSCANY-2166 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Adding the Tuscany library from the Tuscany Eclipse plugin to a Java project breaks it as its buildpath exceeds the limit of the Windows command line length, preventing any programs to be launched from that project. The fix is pretty simple, all the runtime JARs configured in the Tuscany library should not be there anyway. Only the API JARs and the node launcher JAR need to be on the buildpath. -- 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: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 I was working on TUSCANY-2166, and just fixed it. Any help with TUSCANY-2146 and 2150 will be appreciated, and unless it's a problem in my build environment TUSCANY-2168 looks like a blocker as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2169) Saxon download does not work when you are not using the default Maven local repository directory
[ https://issues.apache.org/jira/browse/TUSCANY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583607#action_12583607 ] Mark Combellack commented on TUSCANY-2169: -- There are a few problems: * Maven local repository directory is hard coded so does not work with custom Maven local repository directories * The custom Maven local repository directory was not being passed into the Maven commands for installing the artefacts. Saxon download does not work when you are not using the default Maven local repository directory Key: TUSCANY-2169 URL: https://issues.apache.org/jira/browse/TUSCANY-2169 Project: Tuscany Issue Type: Bug Components: Build System Environment: SVN trunk revision 642924 Linux Reporter: Mark Combellack Assignee: Mark Combellack Priority: Minor Fix For: Java-SCA-Next By default, Maven uses the directory home/.m2/repository (where home is your home directory) for it's local repository. Maven also supports using a user specified local repository directory using the -Dmaven.repo.local=/some/other/directory on the Maven command line. The Saxon module will download the required release of Saxon and copy it into the Maven local repository. However, this does not work if you are using a custom local Maven repository directory. -- 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-2169) Saxon download does not work when you are not using the default Maven local repository directory
[ https://issues.apache.org/jira/browse/TUSCANY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Combellack resolved TUSCANY-2169. -- Resolution: Fixed Fixed in SVN revision 642939 Saxon download does not work when you are not using the default Maven local repository directory Key: TUSCANY-2169 URL: https://issues.apache.org/jira/browse/TUSCANY-2169 Project: Tuscany Issue Type: Bug Components: Build System Environment: SVN trunk revision 642924 Linux Reporter: Mark Combellack Assignee: Mark Combellack Priority: Minor Fix For: Java-SCA-Next By default, Maven uses the directory home/.m2/repository (where home is your home directory) for it's local repository. Maven also supports using a user specified local repository directory using the -Dmaven.repo.local=/some/other/directory on the Maven command line. The Saxon module will download the required release of Saxon and copy it into the Maven local repository. However, this does not work if you are using a custom local Maven repository directory. -- 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: Removing definitions
On 3/27/08, Greg Dritschler [EMAIL PROTECTED] wrote: I'm not sure I'm getting the multi-threading thing, could you say a bit more about it? -- Jean-Sebastien [EMAIL PROTECTED] Thread 1 and thread 2 call ContributionService.contribute. Each contribution contains a defintions.xml file so both threads try to add policy sets etc. Since SCADefinitions uses unsynchronized ArrayLists this is exposed to failure. SCADefinitionsUtil also has some code that isn't thread safe. Greg Hi, I am new to Tuscany Community and trying to catch up. Right now am going through the code to get a feel of it and this threading issue seems to something simple that I can fix to try a hand with Tuscany. Can I create a JIRA for the threading issue alone and attach a patch ? -- Thanks Regards, Ramkumar Ramalingam
[jira] Created: (TUSCANY-2170) Synchronizing the access to SCADefinitions
Synchronizing the access to SCADefinitions -- Key: TUSCANY-2170 URL: https://issues.apache.org/jira/browse/TUSCANY-2170 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: SVN revision 642920 - Windows Reporter: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html -- 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-2170) Synchronizing the access to SCADefinitions
[ https://issues.apache.org/jira/browse/TUSCANY-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583638#action_12583638 ] Ramkumar Ramalingam commented on TUSCANY-2170: -- The current implementation SCADefinitionsImpl.java uses java ArrayList to store the list of policy sets, intents, binding types etc. I believe Instead of synchronizing the methods that does the operations like clear/addAll. I believe the best solution would be to replace the ArrayList with a Vector. Please suggest me if this one is the right approach. Thanks. Synchronizing the access to SCADefinitions -- Key: TUSCANY-2170 URL: https://issues.apache.org/jira/browse/TUSCANY-2170 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: SVN revision 642920 - Windows Reporter: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html -- 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: Removing definitions
Hi Ramkumar, Welcome to Tuscany! Yes, this is a good simple start. Please go ahead and create a JIRA for this. Also would like to see you discuss the alternatives you have in mind for this. Thanks - Venkat On Mon, Mar 31, 2008 at 3:58 PM, Ramkumar R [EMAIL PROTECTED] wrote: On 3/27/08, Greg Dritschler [EMAIL PROTECTED] wrote: I'm not sure I'm getting the multi-threading thing, could you say a bit more about it? -- Jean-Sebastien [EMAIL PROTECTED] Thread 1 and thread 2 call ContributionService.contribute. Each contribution contains a defintions.xml file so both threads try to add policy sets etc. Since SCADefinitions uses unsynchronized ArrayLists this is exposed to failure. SCADefinitionsUtil also has some code that isn't thread safe. Greg Hi, I am new to Tuscany Community and trying to catch up. Right now am going through the code to get a feel of it and this threading issue seems to something simple that I can fix to try a hand with Tuscany. Can I create a JIRA for the threading issue alone and attach a patch ? -- Thanks Regards, Ramkumar Ramalingam
Re: Interested in Apache Tuscany support for CORBA, GSoC program
Thanks for your reply. This example proposal is a good reference on how GSoC application should look like. I've made major changes to my proposal, but some paragraphs still requires some attention: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Apache+Tuscany+CORBA+support%2C+GSoC+proposal I'll be glad to hear any comments, still I have few hours to work on it. 2008/3/30, Luciano Resende [EMAIL PROTECTED]: Hey Wojtek Very good to hear from your interest in Tuscany and in GSoC. One thing I'd suggest in your proposal would be to get more info about a breakdown of milestones/activities in the proposal, take a look at this one as an example [1] [1] http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Allow_Google_Android_applications_to_easily_consume_business_services On Sun, Mar 30, 2008 at 7:21 AM, Wojtek Janiszewski [EMAIL PROTECTED] wrote: Hi, I would like introduce myself and the reason why I am here. I'm an IT student at Polish Japanese Institute of Information Technology in Warsaw, Poland. While I'm interested in programming and heard some encouragements to try Google Summer of Code this year I decided to qualify for Apache Tuscany support for CORBA project. I've already got some clues from my possible mentors (Ant Elder, Raymond Feng) and started to edit wiki: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Apache+Tuscany+CORBA+support Any comments are welcome. Thanks, Wojtek - 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/ - 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]
Subscribing to OASIS sca-j mailing list
I sent an e-mail to [EMAIL PROTECTED] and the mail bounced back. Can someone tell me if this is the right e-mail address? Thanks in advance. ++Vamsi
Strange problem with conversational service when using binding.ws
Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) 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 $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) 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.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke( PassByValueInterceptor.java:108) 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 $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) 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.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: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget( Axis2BindingInvoker.java:120) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:89) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:78) ... 36 more Has anyone reported this problem? Otherwise I will create a JIRA. ++Vamsi
[jira] Created: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the binding
model object is created by CompositeConfigurationBuilderImpl.createSCABinding()
which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is no
code to resolve the IntentAttachPointType to the real one. As a result the
PolicyComputer uses the unresolved IntentAttachPointType model and does not
realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html
--
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-2172) Removing a contribution that has a definitions.xml file leaves the definitions in place
Removing a contribution that has a definitions.xml file leaves the definitions in place --- Key: TUSCANY-2172 URL: https://issues.apache.org/jira/browse/TUSCANY-2172 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Reporter: Greg Dritschler A contribution may contain a definitions.xml document that defines intents and/or policy sets. When such a contribution is removed, I would expect these definitions to be removed from the runtime. Discussed on tuscany-dev here: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29138.html -- 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: SDO Date format
Adriano,
All these formats are only allowed for convenience of entry. When a date
is serialized it is converted to the canonical format. Take a look at
class ModelFactoryImpl:
public String convertDateToString(Object instanceValue)
{
if (instanceValue == null)
{
return null;
}
SimpleDateFormat f = new SimpleDateFormat(
-MM-dd'T'HH:mm:ss'.'SSS'Z');
f.setTimeZone(TimeZone.getTimeZone(GMT));
return f.format((Date)instanceValue);
}
Frank.
[EMAIL PROTECTED] wrote on 03/30/2008 03:27:33 AM:
Surfing on net I found this:
Time zones
...
More recent (post 1.5.0) versions of openadaptor use Java TimeZone
objects,
so the string must be understood by that class (either GMT±hh:mm
Europe/London - note that three letter abbreviations such as CST are
frowned
upon, as there are no standards and many ambiguities - is that US
Central
Standard Time or China Standard Time?). If the timezone is not
recognised,
then the JVM local timezone is assumed. or descriptive:
This text is located at the bottom of [1]. Relying on this text, should
SDO
use time zone abbreviations instead of GMT +-HH:mm format?
[1] https://openadaptor.openadaptor.org/pg/dates_times_and_timezones.htm
Adriano Crestani
On Sat, Mar 29, 2008 at 10:39 PM, Adriano Crestani
[EMAIL PROTECTED] wrote:
I have some doubts about if it's acceptable or not, because the Java
SDO
specs defines the following format: -MM-dd'T'HH:mm:ss'.'SSS'Z'
. But
when I look at the testcases, it test many date strings that are not
exactly
in this format:
// Ensure that strings that should be recognized by toDate do not
// result in a null Date value.
public void testToDateFormats() throws Exception
{
String[] validStrings =
{
2006-03-31T03:30:45.123Z,
-2006-03-31T03:30:45.1Z,
2006-03-31T03:30:45Z,
2006-03-31T03:30:45.123,
2006-03-31T03:30:45.1,
-2006-03-31T03:30:45,
2006-03-31T03:30:45.123 EDT,
2006-03-31T03:30:45.1 EDT,
2006-03-31T03:30:45 EDT,
---05 PST,
---04,
--12 GMT,
--12,
--08-08 EST,
--08-08,
1976-08-08 PDT,
1976-08-08,
88-12 CST,
1988-12,
2005 CDT,
1999,
P2006Y 08M 10D T 12H 24M 07S,
P2006Y 10D T 12H,
-P2006Y 08M 10D T 07S.2,
P08M 10D T 07H,
-P 04M 10DT12H 24S.88,
PT12H
};
for (int i = 0; i validStrings.length; i++)
{
assertNotNull(DataHelper.toData() should not return null
for
' + validStrings[i] + '.,
data_helper.toDate(validStrings[i]));
}
}
Am I missing something?
Thanks in advance,
Adriano Crestani
On Sat, Mar 29, 2008 at 5:55 PM, Adriano Crestani
[EMAIL PROTECTED] wrote:
Hi,
What is the time zone format used in datetime SDO string? Only the
time
zone abbreviation, like for example: PST, or it also accepts
GTM, like for
example: GMT -04:00?
Thanks in advance,
Adriano Crestani
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
[
https://issues.apache.org/jira/browse/TUSCANY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Venkatakrishnan reassigned TUSCANY-2171:
Assignee: Venkatakrishnan
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the
binding model object is created by
CompositeConfigurationBuilderImpl.createSCABinding() which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is
no code to resolve the IntentAttachPointType to the real one. As a result
the PolicyComputer uses the unresolved IntentAttachPointType model and does
not realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html
--
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: Adding SVN version to Java files
Luciano Resende wrote: If Mark is willing to check the missing files, +1 for the updates. I do find this useful from time to time. I also agree that developers should configure their IDE and SVN to proper add the tags and any necessary SVN properties to make this work. On Thu, Mar 27, 2008 at 9:44 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: +0.5 These numbers are expected to help in quickly getting to the revision in which these files are modified. So, if the last revision on the file just added this header, it is not of much use. I would suggest that instead of making a change to just add these headers, we add these headers in the new files and any existing files as we add/modify files. This is a practice I follow for my Geronimo commits. Also, the committer's machine should have the the subversion client properties set appropriately so that these svn:keywords get added to the newly created files. These settings help in avoiding explicitly adding the svn:keywords on newly created files. See [1]. [1] http://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html ++Vamsi On Fri, Mar 28, 2008 at 2:25 AM, Mark Combellack [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't used this information yet, probably because it's not always reliably available. If we were all maintaining it with our checkins, I think I would find it useful. I am happy to get myself set up correctly to add it to files that I create. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subscribing to OASIS sca-j mailing list
Vamsavardhana Reddy wrote: I sent an e-mail to [EMAIL PROTECTED] and the mail bounced back. Can someone tell me if this is the right e-mail address? Thanks in advance. ++Vamsi Vamsi, While the archives of all OASIS technical committee mail lists are public, subscription to the mail lists is not (I don't know why this is so). So to get a subscription to a mail list, you need to join the TC (you can do this purely as an Observer), which is described here: http://www.oasis-open.org/committees/join.php?wg_abbrev=sca-j Once you join the TC you are automatically subscribed to its mailing list. If I can help with this process, let me know. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2173) Add style formatter and template information to website Coding Guidelines
Add style formatter and template information to website Coding Guidelines --- Key: TUSCANY-2173 URL: https://issues.apache.org/jira/browse/TUSCANY-2173 Project: Tuscany Issue Type: Improvement Components: Website Environment: All browsers Reporter: Dan Becker Priority: Minor Incorporate more specific Eclipse style formatter and template notes to the external web site. The external web site at http://cwiki.apache.org/TUSCANY/sca-java-development-guide.html#SCAJavaDevelopmentGuide-CodingGuidelines contains useful coding guidelines. There are additional Eclipse-specific guidelines on the internal wiki at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Code+Style+Formatters+and+Templates It would be useful if the Eclipse Style Formatter and Eclipse Templates (which are in the Tuscany build/repository) be mentioned in the external site. In other words, append the information from the second link above to the first link above. -- 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-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
[
https://issues.apache.org/jira/browse/TUSCANY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583714#action_12583714
]
Venkatakrishnan commented on TUSCANY-2171:
--
I've been trying to see how this can be done neatly but am only able to go as
far as follows :-
- First users should not be able to override the 'bindingType' for a binding.
It comes with the definitions.xml that accompanies a binding extension. The
reason is that only a binding extension knows best what it always provides or
may provide.
- The SCABinding extension provides a definitions.xml and in it the bindingtype
definition as well. During loading of this definitions.xml, I propose we
(atleast for now) set the bindingType as a static field of SCABindingImpl.
Does that sound like a fix for now ?
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the
binding model object is created by
CompositeConfigurationBuilderImpl.createSCABinding() which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is
no code to resolve the IntentAttachPointType to the real one. As a result
the PolicyComputer uses the unresolved IntentAttachPointType model and does
not realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html
--
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
I've just committed fixes for TUSCANY-1948 and TUSCANY-1974 to trunk in r643022, r643023 and r643024, the changes seem ok from the testing i've done so how about including these in 1.2? ...ant On Mon, Mar 31, 2008 at 8:12 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA 1.2] SCA Sample dependencies
Luciano Resende wrote: I have created TUSCANY-2167 to track this issue, and I'm now evaluating our calculator sample, and calculator-webapp sample to see where all the dependencies are coming from. One thing I noticed is that policy-xml is bringing a lot of ws-security related dependencies to these applications, and I'm now trying to move this dependencies to a policy-xml-ws module that would be available only when the application is using the ws-binding. I'd also take a look in other dependencies and see if I can cleanup them before our next RC. Please let me know if you have questions and/or comments. +1 for removing unecessary dependencies and refactoring modules where necessary, as in the security case you described. Thanks for taking a look at this. Moving ws-security dependencies to policy-xml-ws is better than having them in policy-xml, though this doesn't seem quite right if someone is trying to use a different policy (not security) with the Web Service binding. Should they be in policy-xml-ws-security? To get the full benefit of this, it would also be necessary to refactor binding-ws-axis2 so that it does not pull in all the ws-security stuff. On the more general point of sample dependencies, I think it would be a very valuable exercise to use the samples to create dependency profiles of what is really needed to run each sample (with bogus dependencies removed). When we have this information, I think it would be useful to look for clustering between different samples to establish profiles of groups of dependencies that are typically needed together. We might be able to come up with a partially ordered tree containing functional units for Tuscany SCA Java, and indicate for each node in the tree which samples it enables. These functional units would typically be larger than a single maven module. I'm expecting that we might have between 12 and 20 functional units in the whole of Tuscany SCA Java. Here's a illustration of what I mean: tuscany-core [runs: calculator, simple-callback] tuscany-ws [runs: helloworld-ws-referenceservice, simple-callback-ws] tuscany-ws-security [runs: helloworld-ws-referenceservice-secure] tuscany-jms [runs: helloworld-referenceservice-jms] tuscany-webapp [runs: calculator-webapp] tuscany-script [runs: calculator-script] etc. I don't know how deeply nested this would be, or whether it's a simple tree (as shown above) or a graph where some samples would require multiple functional units from different branches of the tree. For example, the sample calculator-ws-webapp might require bringing in the functional units tuscany-ws and tuscany-webapp. Simon [1] https://issues.apache.org/jira/browse/TUSCANY-2167 On Fri, Mar 28, 2008 at 6:42 PM, haleh mahbod [EMAIL PROTECTED] wrote: Should this mvn command be put in the development guide for samples so anyone creating a new sample runs these commands and gets rid of unnecessary dependencies? On 3/28/08, Raymond Feng [EMAIL PROTECTED] wrote: Try mvn dependency:analyze. It analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, March 28, 2008 1:02 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA 1.2] SCA Sample dependencies Luciano Resende wrote: I was looking at some sample applications dependencies last night, and realized that our simple calculator-webapp is huge and with a lot of unnecessary dependencies being dragged to it's WEB-INF\lib. This might cause the impression that SCA is heavy, when it's not. Should we spend some time around reviewing these dependencies before next RC ? +1 I'd suggest to start with calculator (not even the webapp version), I can see dependencies on Xalan, Xerces, Axiom there, no idea why they are required. I've traced Xalan to assembly-xml, and removing it from the pom doesn't seem to break it. I think we need a thorough review of the dependencies that have progressively been added to the core runtime, and see if they're all really needed or just oversights that can be cleaned up. -- 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]
Re: Subscribing to OASIS sca-j mailing list
Thanks Mike. ++Vamsi On Mon, Mar 31, 2008 at 8:25 PM, Mike Edwards [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: I sent an e-mail to [EMAIL PROTECTED] and the mail bounced back. Can someone tell me if this is the right e-mail address? Thanks in advance. ++Vamsi Vamsi, While the archives of all OASIS technical committee mail lists are public, subscription to the mail lists is not (I don't know why this is so). So to get a subscription to a mail list, you need to join the TC (you can do this purely as an Observer), which is described here: http://www.oasis-open.org/committees/join.php?wg_abbrev=sca-j Once you join the TC you are automatically subscribed to its mailing list. If I can help with this process, let me know. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New SCA JEE spec draft and Tuscany JSP taglib available
I don't think this has been mentioned on tuscany-dev before so FYI - there's now a draft of the SCA JEE spec available on the OSOA website at : http://www.osoa.org/download/attachments/35/SCA_JAVAEE_integration_v0_9.pdf?version=1 Lots of interesting things in there, anyone interested in helping implement any of it? One bit I liked was section 5.4.4 about using JSPs with SCA, what we currently have in Tuscany is a bit clunky so i've committed some code to support the taglib as described in that section. So now in a JSP you don't need any code for the SCADomain you just declare the taglib: %@ taglib uri=http://www.osog.org/sca/sca.tld; prefix=sca % and then define SCA references with: sca:reference name=CalculatorServiceComponent type= calculator.CalculatorService / I've updated the calclulator webapp sample to demonstrate this - https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp/src/main/webapp/calc.jsp This seems so much better than our old approach I'd like to change all our JSP samples to work like this, what do you guys think? ...ant
Re: [SCA 1.2] Release Status and RC plans
Hi, I'm fixing TUSCANY-2150 now. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, March 31, 2008 2:59 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA 1.2] Release Status and RC plans Luciano Resende wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 I was working on TUSCANY-2166, and just fixed it. Any help with TUSCANY-2146 and 2150 will be appreciated, and unless it's a problem in my build environment TUSCANY-2168 looks like a blocker as well. -- 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]
[jira] Assigned: (TUSCANY-2150) samples/helloworld-ws-servicereference-jms
[ https://issues.apache.org/jira/browse/TUSCANY-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-2150: - Assignee: Raymond Feng samples/helloworld-ws-servicereference-jms --- Key: TUSCANY-2150 URL: https://issues.apache.org/jira/browse/TUSCANY-2150 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Environment: WinXP SP2, IBM JDK 5 Reporter: Simon Laws Assignee: Raymond Feng Fix For: Java-SCA-1.2 Running helloworld-ws-service-jms gives rise to... C:\simon\tuscany\release\sca-r1.2-rc2\tuscany-sca-1.2-incubating\samples\hellowo rld-ws-service-jmsant run Buildfile: build.xml run: [java] 27-Mar-2008 10:57:15 org.apache.tuscany.sca.binding.ws.axis2.Axis2Se rviceProvider start [java] INFO: Axis2 JMS URL=jms:/queue.sample?transport.jms.ConnectionFactor yJNDIName=QueueConnectionFactoryjava.naming.factory.initial=org.apache.activemq .jndi.ActiveMQInitialContextFactoryjava.naming.provider.url=tcp://localhost:616 19 [java] Exception in thread main org.osoa.sca.ServiceRuntimeException: org .apache.axis2.transport.jms.AxisJMSException: Error connecting to JMS connection factory : QueueConnectionFactory [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:264) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC ADomain.java:69) [java] at helloworld.HelloWorldServer.main(HelloWorldServer.java:33) [java] Caused by: org.apache.axis2.transport.jms.AxisJMSException: Error co nnecting to JMS connection factory : QueueConnectionFactory [java] at org.apache.axis2.transport.jms.JMSListener.handleException(JM SListener.java:420) [java] at org.apache.axis2.transport.jms.JMSListener.initializeConnecti onFactories(JMSListener.java:256) [java] at org.apache.axis2.transport.jms.JMSListener.init(JMSListener.j ava:109) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider. start(Axis2ServiceProvider.java:285) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingPr ovider.start(Axis2ServiceBindingProvider.java:94) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.s tart(CompositeActivatorImpl.java:520) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.in it(DefaultSCADomain.java:226) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.i nit(DefaultSCADomain.java:109) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:230) [java] ... 2 more [java] Caused by: javax.naming.NoInitialContextException: Cannot instantiat e class: org.apache.activemq.jndi.ActiveMQInitialContextFactory [Root exception is java.lang.ClassNotFoundException: org.apache.activemq.jndi.ActiveMQInitialCon textFactory] [java] at javax.naming.spi.NamingManager.getInitialContext(NamingManage r.java:669) [java] at javax.naming.InitialContext.getDefaultInitCtx(InitialContext. java:259) [java] at javax.naming.InitialContext.init(InitialContext.java:235) [java] at javax.naming.InitialContext.init(InitialContext.java:209) [java] at org.apache.axis2.transport.jms.JMSConnectionFactory.createIni tialContext(JMSConnectionFactory.java:189) [java] at org.apache.axis2.transport.jms.JMSConnectionFactory.connect(J MSConnectionFactory.java:170) [java] at org.apache.axis2.transport.jms.JMSListener.initializeConnecti onFactories(JMSListener.java:253) [java] ... 9 more [java] Caused by: java.lang.ClassNotFoundException: org.apache.activemq.jnd i.ActiveMQInitialContextFactory [java] at java.lang.Class.forName(Class.java:163) [java] at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelp er12.java:57) [java] at javax.naming.spi.NamingManager.getInitialContext(NamingManage r.java:666) [java] ... 15 more [java] Java Result: 1 -- 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: Reporting errors for illegal SCA annotations (TUSCANY-2140)
Jean-Sebastien Delfino wrote: Mike Edwards wrote: ant elder wrote: I agree with that and having recently spent time helping people new to Tuscany and seen the problems they've had I think it would be much more helpful to fail. Could we have a lenient mode which can be used when debugging in eclipse? But I think the default should be strict so when you deploy a Tuscany webapp it fails if there are issues. ...ant Wouldn't it be better to output warnings rather than simply stop? In the cases your talking about, were there any warning messages? Wouldn't such messages have helped? Yours, Mike. +1, it looks like you and I are on the same page but in minority. Also, annotations are just one way of configuring things. XML is another one, should we really prevent an application to start if an XML element is misplaced? I think that all the people who want to throw an exception and stop when an annotation is misplaced or misconfigured should be given a little exercise, just for the fun of it: Try to develop a real application, go yourself through the steps of writing it, debugging, fixing, rebuilding, deploying etc. Then come back and tell everybody again what you'd prefer, warning messages, error messages, or exceptions that prevent the application to start. Good luck in advance :) I prefer to be given error diagnostics as early in the development cycle as possible. IMO, compile-time errors are better than runtime errors, and deployment-time or configuration-time errors (where these can be detected) are better than runtime errors. The above is my view, but it seems from this discussion that this is one of those religious issues where personal preference is a big factor. Unfortunately, supporting both approaches takes more work as Tuscany would need to have code to detect errors early for the strict folls as well as code to detect the same errors later for the relaxed folks. And the documentation would need to explain both approaches with examples of how each error shows up in both strict and relaxed modes. This would increase complexity as well as cost. So on balance I'd say pick one approach based on the majority view, and make sure the real users get to vote as well as the Tuscany developers :-) Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Verification Testing
Kevin Williams wrote: I think that named annotations would be more clear since there is not a direct mapping from line number to compliance point. A compliance point may cover n lines or a single line may have n compliance points. In that case you could produce a separate compliance document that maps between compliance points and spec line numbers in a one-many or many-one fashion as necessary. Simon On Fri, Mar 28, 2008 at 9:47 AM, Simon Nash [EMAIL PROTECTED] wrote: Kevin Williams wrote: I'd like to add an annotated version of the SCA Java Common Annotations and APIs specification somewhere in the project so that I can reference individual functional requirements from the tests. Does it make sense to add this as an attachment to the Java SCA Documentation wiki page? If the references are from the tests to the spec, it should be possible to use spec line numbers and not modify the spec. Is there some problem with this? Simon Thanks, --Kevin On Thu, Mar 20, 2008 at 11:22 AM, Kevin Williams [EMAIL PROTECTED] wrote: I would like to tie individual tests in this new suite to specific functional requirements from the specifications. The best way to do this may be to reference named requirements from annotated versions of the specs. Would it make sense to store these annotated versions somewhere in the project? Thanks, --Kevin On Thu, Mar 20, 2008 at 3:21 AM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: +1 ++Vamsi On Wed, Mar 19, 2008 at 11:10 PM, Kevin Williams [EMAIL PROTECTED] wrote: 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interested in Apache Tuscany support for CORBA, GSoC program
Wojtek Janiszewski wrote: Thanks for your reply. This example proposal is a good reference on how GSoC application should look like. I've made major changes to my proposal, but some paragraphs still requires some attention: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Apache+Tuscany+CORBA+support%2C+GSoC+proposal I'll be glad to hear any comments, still I have few hours to work on it. Hi Wojtek, You still have a week :) it looks like the student application deadline just got extended to April 7 [1]. [1] http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/9fa88f31aa401f70 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TUSCANY-1974, was Re: [SCA 1.2] Release Status and RC plans
Hi Ant, In this JIRA, you added a comments that this was little risky, how comfortable are you with adding this into SCA 1.2 ? Have you tested this with other webapps and no side effects ? On Mon, Mar 31, 2008 at 8:31 AM, ant elder [EMAIL PROTECTED] wrote: I've just committed fixes for TUSCANY-1948 and TUSCANY-1974 to trunk in r643022, r643023 and r643024, the changes seem ok from the testing i've done so how about including these in 1.2? ...ant On Mon, Mar 31, 2008 at 8:12 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TUSCANY-1974, was Re: [SCA 1.2] Release Status and RC plans
Not risky - just that when I added the fix to the jira I'd not done much testing at all other than to confirm it fixed the problem, i've done a bit more testing now and all the samples i've tried seem ok. I'm away right now so cant try every sample and demo we have though sorry. ...ant On Mon, Mar 31, 2008 at 5:19 PM, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ant, In this JIRA, you added a comments that this was little risky, how comfortable are you with adding this into SCA 1.2 ? Have you tested this with other webapps and no side effects ? On Mon, Mar 31, 2008 at 8:31 AM, ant elder [EMAIL PROTECTED] wrote: I've just committed fixes for TUSCANY-1948 and TUSCANY-1974 to trunk in r643022, r643023 and r643024, the changes seem ok from the testing i've done so how about including these in 1.2? ...ant On Mon, Mar 31, 2008 at 8:12 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SDO 1.1 rc3 release
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
[jira] Resolved: (TUSCANY-2150) samples/helloworld-ws-servicereference-jms
[ https://issues.apache.org/jira/browse/TUSCANY-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-2150. --- Resolution: Fixed Fixed under r643083 (1.2 branch) and r643081 (trunk) samples/helloworld-ws-servicereference-jms --- Key: TUSCANY-2150 URL: https://issues.apache.org/jira/browse/TUSCANY-2150 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Environment: WinXP SP2, IBM JDK 5 Reporter: Simon Laws Assignee: Raymond Feng Fix For: Java-SCA-1.2 Running helloworld-ws-service-jms gives rise to... C:\simon\tuscany\release\sca-r1.2-rc2\tuscany-sca-1.2-incubating\samples\hellowo rld-ws-service-jmsant run Buildfile: build.xml run: [java] 27-Mar-2008 10:57:15 org.apache.tuscany.sca.binding.ws.axis2.Axis2Se rviceProvider start [java] INFO: Axis2 JMS URL=jms:/queue.sample?transport.jms.ConnectionFactor yJNDIName=QueueConnectionFactoryjava.naming.factory.initial=org.apache.activemq .jndi.ActiveMQInitialContextFactoryjava.naming.provider.url=tcp://localhost:616 19 [java] Exception in thread main org.osoa.sca.ServiceRuntimeException: org .apache.axis2.transport.jms.AxisJMSException: Error connecting to JMS connection factory : QueueConnectionFactory [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:264) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC ADomain.java:69) [java] at helloworld.HelloWorldServer.main(HelloWorldServer.java:33) [java] Caused by: org.apache.axis2.transport.jms.AxisJMSException: Error co nnecting to JMS connection factory : QueueConnectionFactory [java] at org.apache.axis2.transport.jms.JMSListener.handleException(JM SListener.java:420) [java] at org.apache.axis2.transport.jms.JMSListener.initializeConnecti onFactories(JMSListener.java:256) [java] at org.apache.axis2.transport.jms.JMSListener.init(JMSListener.j ava:109) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider. start(Axis2ServiceProvider.java:285) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingPr ovider.start(Axis2ServiceBindingProvider.java:94) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.s tart(CompositeActivatorImpl.java:520) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.in it(DefaultSCADomain.java:226) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.i nit(DefaultSCADomain.java:109) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:230) [java] ... 2 more [java] Caused by: javax.naming.NoInitialContextException: Cannot instantiat e class: org.apache.activemq.jndi.ActiveMQInitialContextFactory [Root exception is java.lang.ClassNotFoundException: org.apache.activemq.jndi.ActiveMQInitialCon textFactory] [java] at javax.naming.spi.NamingManager.getInitialContext(NamingManage r.java:669) [java] at javax.naming.InitialContext.getDefaultInitCtx(InitialContext. java:259) [java] at javax.naming.InitialContext.init(InitialContext.java:235) [java] at javax.naming.InitialContext.init(InitialContext.java:209) [java] at org.apache.axis2.transport.jms.JMSConnectionFactory.createIni tialContext(JMSConnectionFactory.java:189) [java] at org.apache.axis2.transport.jms.JMSConnectionFactory.connect(J MSConnectionFactory.java:170) [java] at org.apache.axis2.transport.jms.JMSListener.initializeConnecti onFactories(JMSListener.java:253) [java] ... 9 more [java] Caused by: java.lang.ClassNotFoundException: org.apache.activemq.jnd i.ActiveMQInitialContextFactory [java] at java.lang.Class.forName(Class.java:163) [java] at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelp er12.java:57) [java] at javax.naming.spi.NamingManager.getInitialContext(NamingManage r.java:666) [java] ... 15 more [java] Java Result: 1 -- 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-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
[
https://issues.apache.org/jira/browse/TUSCANY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583772#action_12583772
]
Jean-Sebastien Delfino commented on TUSCANY-2171:
-
A simpler fix is to pass the Definitions model object to the builder and then
look for the BindingType of the SCABinding in that Definitions object.
There is no need to create a proxy to an unresolved BindingType model object
and then try to resolve it later in your scenario. That kind of deferred
resolution is only relevant at read time when the SCA artifacts being read are
presented in a random order and you need to defer the resolution of references
to objects that have not been read yet...
In your case here, everything including BindingTypes has been read way before,
you just need to pass that Definitions model to the builder so that it can get
the correct BindingType for the SCABinding from it and point to it.
Hope this helps.
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the
binding model object is created by
CompositeConfigurationBuilderImpl.createSCABinding() which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is
no code to resolve the IntentAttachPointType to the real one. As a result
the PolicyComputer uses the unresolved IntentAttachPointType model and does
not realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html
--
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
Hi, I fixed TUSCANY-2150 in both 1.2 branch and trunk. I had to work around an Axis2 issue too (https://issues.apache.org/jira/browse/AXIS2-3685). Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Monday, March 31, 2008 8:54 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA 1.2] Release Status and RC plans Hi, I'm fixing TUSCANY-2150 now. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, March 31, 2008 2:59 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA 1.2] Release Status and RC plans Luciano Resende wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 I was working on TUSCANY-2166, and just fixed it. Any help with TUSCANY-2146 and 2150 will be appreciated, and unless it's a problem in my build environment TUSCANY-2168 looks like a blocker as well. -- 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]
Re: Adding SVN version to Java files
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? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding SVN version to Java files
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
Re: Adding SVN version to Java files
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-2146) Array index out of range in binding-notification sample
[ https://issues.apache.org/jira/browse/TUSCANY-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-2146: - Assignee: Raymond Feng Array index out of range in binding-notification sample --- Key: TUSCANY-2146 URL: https://issues.apache.org/jira/browse/TUSCANY-2146 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Environment: WinXP SP2, IBM JDK5 Reporter: Simon Laws Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-1.2 To reproduce run up binding-notification-broker binding-notification-producer binding-notification-consumer As per the associate README Enter some message into the broker, e.g ABC and hit enter. I see the following exception Then [java] java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 1 [java] at org.apache.tuscany.sca.core.databinding.wire.PassByValueInter ceptor.copy(PassByValueInterceptor.java:155) [java] at org.apache.tuscany.sca.core.databinding.wire.PassByValueInter ceptor.invoke(PassByValueInterceptor.java:106) [java] at org.apache.tuscany.sca.binding.notification.NotificationServi ceBindingProvider.invoke(NotificationServiceBindingProvider.java:263) [java] at org.apache.tuscany.sca.binding.notification.NotificationServi ceBindingProvider.handle(NotificationServiceBindingProvider.java:244) [java] at org.apache.tuscany.sca.binding.notification.util.Notification Servlet.doPost(NotificationServlet.java:76) [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [java] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder. java:487) [java] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandle r.java:362) [java] at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandle r.java:181) [java] at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandle r.java:726) [java] at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrappe r.java:139) [java] at org.mortbay.jetty.Server.handle(Server.java:324) [java] at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection .java:505) [java] at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpC onnection.java:842) [java] at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) [java] at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:2 11) [java] at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:3 80) [java] at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEnd Point.java:395) [java] at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.ja va:61) [java] at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$Decora tingWork.run(ThreadPoolWorkManager.java:214) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread PoolExecutor.java:665) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool Executor.java:690) [java] at java.lang.Thread.run(Thread.java:801) -- 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: Reporting errors for illegal SCA annotations (TUSCANY-2140)
Hi Folks, +1 for warnings when the application is developed. +1 for Errors when you put the application into production. The trick is to know the difference between deployment for UT vs. deployment for real. :-) Dave - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, March 31, 2008 11:56 AM Subject: Re: Reporting errors for illegal SCA annotations (TUSCANY-2140) Jean-Sebastien Delfino wrote: Mike Edwards wrote: ant elder wrote: I agree with that and having recently spent time helping people new to Tuscany and seen the problems they've had I think it would be much more helpful to fail. Could we have a lenient mode which can be used when debugging in eclipse? But I think the default should be strict so when you deploy a Tuscany webapp it fails if there are issues. ...ant Wouldn't it be better to output warnings rather than simply stop? In the cases your talking about, were there any warning messages? Wouldn't such messages have helped? Yours, Mike. +1, it looks like you and I are on the same page but in minority. Also, annotations are just one way of configuring things. XML is another one, should we really prevent an application to start if an XML element is misplaced? I think that all the people who want to throw an exception and stop when an annotation is misplaced or misconfigured should be given a little exercise, just for the fun of it: Try to develop a real application, go yourself through the steps of writing it, debugging, fixing, rebuilding, deploying etc. Then come back and tell everybody again what you'd prefer, warning messages, error messages, or exceptions that prevent the application to start. Good luck in advance :) I prefer to be given error diagnostics as early in the development cycle as possible. IMO, compile-time errors are better than runtime errors, and deployment-time or configuration-time errors (where these can be detected) are better than runtime errors. The above is my view, but it seems from this discussion that this is one of those religious issues where personal preference is a big factor. Unfortunately, supporting both approaches takes more work as Tuscany would need to have code to detect errors early for the strict folls as well as code to detect the same errors later for the relaxed folks. And the documentation would need to explain both approaches with examples of how each error shows up in both strict and relaxed modes. This would increase complexity as well as cost. So on balance I'd say pick one approach based on the majority view, and make sure the real users get to vote as well as the Tuscany developers :-) Simon - 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] Resolved: (TUSCANY-2146) Array index out of range in binding-notification sample
[ https://issues.apache.org/jira/browse/TUSCANY-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-2146. --- Resolution: Fixed Fixed under r643103 (1.2) and r643102 (trunk) Array index out of range in binding-notification sample --- Key: TUSCANY-2146 URL: https://issues.apache.org/jira/browse/TUSCANY-2146 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Environment: WinXP SP2, IBM JDK5 Reporter: Simon Laws Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-1.2 To reproduce run up binding-notification-broker binding-notification-producer binding-notification-consumer As per the associate README Enter some message into the broker, e.g ABC and hit enter. I see the following exception Then [java] java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 1 [java] at org.apache.tuscany.sca.core.databinding.wire.PassByValueInter ceptor.copy(PassByValueInterceptor.java:155) [java] at org.apache.tuscany.sca.core.databinding.wire.PassByValueInter ceptor.invoke(PassByValueInterceptor.java:106) [java] at org.apache.tuscany.sca.binding.notification.NotificationServi ceBindingProvider.invoke(NotificationServiceBindingProvider.java:263) [java] at org.apache.tuscany.sca.binding.notification.NotificationServi ceBindingProvider.handle(NotificationServiceBindingProvider.java:244) [java] at org.apache.tuscany.sca.binding.notification.util.Notification Servlet.doPost(NotificationServlet.java:76) [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [java] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder. java:487) [java] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandle r.java:362) [java] at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandle r.java:181) [java] at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandle r.java:726) [java] at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrappe r.java:139) [java] at org.mortbay.jetty.Server.handle(Server.java:324) [java] at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection .java:505) [java] at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpC onnection.java:842) [java] at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) [java] at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:2 11) [java] at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:3 80) [java] at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEnd Point.java:395) [java] at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.ja va:61) [java] at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$Decora tingWork.run(ThreadPoolWorkManager.java:214) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread PoolExecutor.java:665) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool Executor.java:690) [java] at java.lang.Thread.run(Thread.java:801) -- 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: Adding SVN version to Java files
I already have my IDE set up to add the headers automatically for a while. I'm +1 on Mark's proposal as he's volunteering :-). My stance is that this header is nice to have but not mandatory. BTW, this header is updated by SVN (not by developers) whenever a commit is made. Please see: http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html. There is no extra burden for developers to keep it up-to-date if the header is already set in the src code. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Monday, March 31, 2008 11:55 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Re: Adding SVN version to Java files 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA 1.2] Release Status and RC plans
I fixed TUSCANY-2146 too. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, March 31, 2008 2:59 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA 1.2] Release Status and RC plans Luciano Resende wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 I was working on TUSCANY-2166, and just fixed it. Any help with TUSCANY-2146 and 2150 will be appreciated, and unless it's a problem in my build environment TUSCANY-2168 looks like a blocker as well. -- 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]
Re: Reporting errors for illegal SCA annotations (TUSCANY-2140)
scabooz wrote: Hi Folks, +1 for warnings when the application is developed. +1 for Errors when you put the application into production. The trick is to know the difference between deployment for UT vs. deployment for real. :-) Dave And the other trick is to allow processing of artifacts with errors to proceed as well in dev, debug and admin scenarios as well. For example we should be able to load a composite with errors in it, in the admin tool, to show these errors to the administrator and allow him to fix them. Basically it's the same idea as a with Java editor. A Java editor that wouldn't allow you to edit Java classes with errors wouldn't be very useful :) That means: Not throwing an exception that stops everything on the first error, but instead report errors through the monitors that we already have in various places in the code. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
@OneWay over binding.ws problems and problems with supporting iTest
Hi, I am seeing an issue where @OneWay operations over binding.ws are not
having the parameters serialized properly. I tried to verify that an iTest
existed for this case but found that the oneway iTest appears not to be
operational and it wouldn't catch the problem that I am seeing. From the
oneway iTest service impl below you can see that the method argument count
is not being referenced. In my
situation my argument is a string and the value passed into the method is
null resulting in a NPE. I tried uncommenting the
code below to see if count was being de-serialized properly but when i run
the iTest i get a messsage indicatding no tests were found to run. So
this is a 2-part issue. a) are there any working tests using a @OneWay
over binding.ws that prove method parameters are being serialized properly?
b) Is this iTest working?Thanks!
package org.apache.tuscany.sca.itest.oneway.impl;
import org.apache.tuscany.sca.itest.oneway.OneWayService;
/**
* The service for the oneway itest
*
* @version $Rev: 537240 $ $Date: 2007-05-11 18:35:03 +0100 (Fri, 11 May
2007) $
*/
public class OneWayServiceImpl implements OneWayService {
public static int callCount = 0;
public void doSomething(int count){
synchronized(this){
callCount++;
}
//System.out.println(Service: doSomething + count + callCount = +
callCount);
//System.out.flush();
}
}
Re: Reporting errors for illegal SCA annotations (TUSCANY-2140)
Yep. Deployment for UT usually involves all the traditional IT roles, just in development mode. By the time the application gets through its initial lifecycle phases, subsequent lifecycle phases need to be more strict. The admin role early in the lifecycle should be very lenient as you said. The admin role after deployment into production should be very strict. The runtime impl/model has no way of differentiating. There is a desire to use the same the implementation code in the runtime in all phases of the lifecycle, so it's usually best to be lenient in the runtime, and let the hosting environment take care of knowing when to be strict. I got the impression that you might have thought we were disagreeing, but we're in violent agreement I think. To net it out, Tuscany should be lenient in the model classes (warnings) which enables a hosting environment with more context to react properly. Dave - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, March 31, 2008 3:27 PM Subject: Re: Reporting errors for illegal SCA annotations (TUSCANY-2140) scabooz wrote: Hi Folks, +1 for warnings when the application is developed. +1 for Errors when you put the application into production. The trick is to know the difference between deployment for UT vs. deployment for real. :-) Dave And the other trick is to allow processing of artifacts with errors to proceed as well in dev, debug and admin scenarios as well. For example we should be able to load a composite with errors in it, in the admin tool, to show these errors to the administrator and allow him to fix them. Basically it's the same idea as a with Java editor. A Java editor that wouldn't allow you to edit Java classes with errors wouldn't be very useful :) That means: Not throwing an exception that stops everything on the first error, but instead report errors through the monitors that we already have in various places in the code. -- 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]
[jira] Created: (TUSCANY-2174) Policy related test cases should be moved to a policy iTest module
Policy related test cases should be moved to a policy iTest module
--
Key: TUSCANY-2174
URL: https://issues.apache.org/jira/browse/TUSCANY-2174
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
Fix For: Java-SCA-Next
We currently have many policy related tests around assembly-xml,
definitions-xml, etc
These tests are producing multiple warnings because it need high level
dependencies on low level modules
I'd suggest we move all these type of tests to a iTest, where we can have all
the necessary dependencies in use
Below is the set of warnings I get while compiling assembly-xml
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}interface.java cannot be
processed. ([row,col,system-id]:
[26,9,file:/home/lresende/apache/tuscany/java-sca-1.2/modules/assembly-xml/target/test-classes/org/apache/tuscany/sca/assembly/xml/CalculatorComponent.constrainingType])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}interface.java cannot be
processed. ([row,col,system-id]:
[30,9,file:/home/lresende/apache/tuscany/java-sca-1.2/modules/assembly-xml/target/test-classes/org/apache/tuscany/sca/assembly/xml/CalculatorComponent.constrainingType])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://extension}testExtension cannot be processed. ([row,col
{unknown-source}]: [30,5])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://extension}testExtension cannot be processed. ([row,col
{unknown-source}]: [33,9])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}interface.java cannot be
processed. ([row,col {unknown-source}]: [34,9])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}binding.ws cannot be
processed. ([row,col {unknown-source}]: [37,9])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://extension}testExtension cannot be processed. ([row,col
{unknown-source}]: [41,10])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}binding.ws cannot be
processed. ([row,col {unknown-source}]: [42,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://extension}testExtension cannot be processed. ([row,col
{unknown-source}]: [49,9])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}interface.java cannot be
processed. ([row,col {unknown-source}]: [51,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}binding.ws cannot be
processed. ([row,col {unknown-source}]: [53,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://extension}testExtension cannot be processed. ([row,col
{unknown-source}]: [59,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}interface.java cannot be
processed. ([row,col {unknown-source}]: [60,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}binding.ws cannot be
processed. ([row,col {unknown-source}]: [62,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}implementation.java cannot
be processed. ([row,col {unknown-source}]: [71,9])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}interface.java cannot be
processed. ([row,col {unknown-source}]: [76,13])
Mar 31, 2008 1:06:42 PM
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor
read
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}implementation.java cannot
be
[jira] Assigned: (TUSCANY-2168) Incorrect level of commons-httpclient in distribution
[ https://issues.apache.org/jira/browse/TUSCANY-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-2168: - Assignee: Raymond Feng Incorrect level of commons-httpclient in distribution - Key: TUSCANY-2168 URL: https://issues.apache.org/jira/browse/TUSCANY-2168 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-1.2 When I build the distribution I get commons-httpclient-2.0.1 in the distro lib. The bindings that use that the httpclient require commons-httpclient-3.0.1 and fail with various exceptions like ClassNotFound and NoSuchMethod. -- 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-2168) Incorrect level of commons-httpclient in distribution
[ https://issues.apache.org/jira/browse/TUSCANY-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-2168. --- Resolution: Fixed Fixed under r643144 in 1.2 branch. Incorrect level of commons-httpclient in distribution - Key: TUSCANY-2168 URL: https://issues.apache.org/jira/browse/TUSCANY-2168 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-1.2 When I build the distribution I get commons-httpclient-2.0.1 in the distro lib. The bindings that use that the httpclient require commons-httpclient-3.0.1 and fail with various exceptions like ClassNotFound and NoSuchMethod. -- 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] Reopened: (TUSCANY-1840) Bootstrapping a subset of Tuscany runtime to support object modeling in tools
[ https://issues.apache.org/jira/browse/TUSCANY-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Zhou reopened TUSCANY-1840: Reopening this issue and Richard will add more information into the JIRA. Bootstrapping a subset of Tuscany runtime to support object modeling in tools - Key: TUSCANY-1840 URL: https://issues.apache.org/jira/browse/TUSCANY-1840 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Environment: Windows or Linux Reporter: Sean Zhou Fix For: Java-SCA-Next When adopting Tuscany object models in a tooling environment, a subset of Tuscany runtime requires bootstrap such as creating extension points and factories. Currently there are no standard API methods or classes for Tuscany bootstrapping for modeling. -- 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-2169) Saxon download does not work when you are not using the default Maven local repository directory
[ https://issues.apache.org/jira/browse/TUSCANY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583855#action_12583855 ] Raymond Feng commented on TUSCANY-2169: --- The donwload ant task is a workaround as the saxon 9.0.0.2 artifacts are not uploaded in the public repos. Now we created a tuscany maven repo at http://svn.apache.org/repos/asf/incubator/tuscany/maven. We can declare it in the pom.xml and remove the tuscany-saxon module as well as the download scripts. Saxon download does not work when you are not using the default Maven local repository directory Key: TUSCANY-2169 URL: https://issues.apache.org/jira/browse/TUSCANY-2169 Project: Tuscany Issue Type: Bug Components: Build System Environment: SVN trunk revision 642924 Linux Reporter: Mark Combellack Assignee: Mark Combellack Priority: Minor Fix For: Java-SCA-Next By default, Maven uses the directory home/.m2/repository (where home is your home directory) for it's local repository. Maven also supports using a user specified local repository directory using the -Dmaven.repo.local=/some/other/directory on the Maven command line. The Saxon module will download the required release of Saxon and copy it into the Maven local repository. However, this does not work if you are using a custom local Maven repository directory. -- 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-1840) Bootstrapping a subset of Tuscany runtime to support object modeling in tools
[ https://issues.apache.org/jira/browse/TUSCANY-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583868#action_12583868 ] Richard Mah commented on TUSCANY-1840: -- We only wish to bootstrap parts of Tuscany required to use the model objects. For example, in our current bootstraping code, creating and registering STAX processors, document processors, the various extension points, etc... Our current use of the Tuscany model involves the loading, use, and persistence of Tuscany model objects. For example: -Load contributions from a sca-contribution.xml or sca-contribution-generated.xml into a Tuscany model Contribution object. -Load composites from a .composite file into a Tuscany assembly model Composite object. -Edit the Contribution and Composite objects. -Write the Contribution object back to the sca-contribution.xml or sca-contribution-generated.xml file. -Write the Composite object back to the .composite file. -Load up WSDL and Java resources into the corresponding Tuscany model objects. In the future, we'll be adding loading/writing .componentType and .definitions along with policy sets and intents to our list of Tuscany usage. Additionally, we require the ability to specify the various ModuleActivators (for example, WSDLInterfaceRuntimeModuleActivator, etc...) other than the current way of specifying them on the classpath. For example, some api to set the list of ModuleActivators. Bootstrapping a subset of Tuscany runtime to support object modeling in tools - Key: TUSCANY-1840 URL: https://issues.apache.org/jira/browse/TUSCANY-1840 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Environment: Windows or Linux Reporter: Sean Zhou Fix For: Java-SCA-Next When adopting Tuscany object models in a tooling environment, a subset of Tuscany runtime requires bootstrap such as creating extension points and factories. Currently there are no standard API methods or classes for Tuscany bootstrapping for modeling. -- 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-2175) Plugin does properly log errors and release its progress monitor
Plugin does properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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: Reporting errors for illegal SCA annotations (TUSCANY-2140)
scabooz wrote: Yep. Deployment for UT usually involves all the traditional IT roles, just in development mode. By the time the application gets through its initial lifecycle phases, subsequent lifecycle phases need to be more strict. The admin role early in the lifecycle should be very lenient as you said. The admin role after deployment into production should be very strict. The runtime impl/model has no way of differentiating. There is a desire to use the same the implementation code in the runtime in all phases of the lifecycle, so it's usually best to be lenient in the runtime, and let the hosting environment take care of knowing when to be strict. I got the impression that you might have thought we were disagreeing, but we're in violent agreement I think. To net it out, Tuscany should be lenient in the model classes (warnings) which enables a hosting environment with more context to react properly. Dave +1 we are in agreement :) not sure everybody on the list agrees though. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can we include the fix for TUSCANY-2175 in 1.2?
I committed fixes for annoying issues with the plugin (TUSCANY-2175) in trunk SVN revision 643158. It's a no risk fix so I'd like to merge it into the 1.2 branch if possible. Let me know. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2175) Plugin does properly log errors and release its progress monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583883#action_12583883 ] Jean-Sebastien Delfino commented on TUSCANY-2175: - I committed fixes for annoying issues with the plugin (TUSCANY-2175) in trunk SVN revision 643158. It's a no risk fix so I'd like to merge it into the 1.2 branch if possible. Plugin does properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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-2175) Plugin does not properly log errors and release its progress monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-2175: Summary: Plugin does not properly log errors and release its progress monitor (was: Plugin does properly log errors and release its progress monitor) Plugin does not properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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: Can we include the fix for TUSCANY-2175 in 1.2?
Sure, go ahead. I looked into the commit logs and it looks ok and very isolated. On Mon, Mar 31, 2008 at 2:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I committed fixes for annoying issues with the plugin (TUSCANY-2175) in trunk SVN revision 643158. It's a no risk fix so I'd like to merge it into the 1.2 branch if possible. Let me know. Thanks. -- 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange problem with conversational service when using binding.ws
Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) 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 $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) 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.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke( PassByValueInterceptor.java:108) 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 $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) 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.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: org.apache.axis2.AxisFault: An unknown message label has been encountered: In
Re: GSoc08 Applications: Integrate Google services in SCA compositions + Allow Google Android applications to easily consume business services
Hi, Following Jean-Sebastien's comments I've added a Use case to my draft proposal for the Integrate Google services in SCA compositions GSoc08 project. I also revised the deliverables to make sure they were aligned with the overall idea. The proposal can be found at: http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Integrate_Google_services_in_SCA_compositions I greatly appreciate your comments on the Use case (now that the GSoc deadline has been extended). I'm worried that it might not be realistic. I'm also wondering if I should include a similar Use case for the Android project. I briefly revised the proposal for this project as well, comments or suggestions are also welcome. The proposal can be found here: http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Allow_Google_Android_applications_to_easily_consume_business_services In preparation for final submission of the proposals I have posted the updated content on the GSoc webapp. I would like to thank Jean-Sebastien again for his valuable help and most insightful comments. best, -oscar Oscar Castañeda Student of Delft University of Technology http://homepage.mac.com/o.castaneda/ On Mon, Mar 31, 2008 at 12:49 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Oscar Castaneda wrote: Hi, I've posted an update to the draft proposal for the Integrate Google services in SCA compositions GSoc08 project. It can be found at: http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Integrate_Google_services_in_SCA_compositions I would like to thank Jean-Sebastien for his comments, they were really insightful and helped me re-think the project breakdown. You're welcome :) The proposal looks very good to me. Oscar and I have already chatted about it so It would be great if others on tuscany-dev could give feedback too with their perspective. Thanks. Another small comment: Maybe add one or two examples composing GData services (search, calendar, contact, and/or spreadsheet) and other services out there (events, news, weather etc) to do something useful or fun? I don't have a great idea right now though :) Maybe others on the list can think of something... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2176) implementation-ejb JARs missing from assembly
implementation-ejb JARs missing from assembly - Key: TUSCANY-2176 URL: https://issues.apache.org/jira/browse/TUSCANY-2176 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The implementation-ejb and implementation-ejb modules are missing from the distro assembly, preventing the EJB part of the tutorial to work (and actually causing more issues in it as that breaks some wires and the domain admin does not tolerate that kind of errors very well at the moment). -- 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-2177) Incorrect dependencies in tutorial not reported by admin
Incorrect dependencies in tutorial not reported by admin - Key: TUSCANY-2177 URL: https://issues.apache.org/jira/browse/TUSCANY-2177 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 The tutorial/assets module currently has incorrect dependency imports. These dependency errors are not correctly reported by the domain admin. The fix is very minor and risk free: - remove the incorrect imports from tutorial/assets/META-INF/sca-contribution.xml - display dependency problems on the admin contributions page (the logic was all there to get the list of problems but they were just not displayed) I'll try to get the fix in the 1.2 release as it's really useful to see contribution dependency errors. -- 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: GSoc08 Applications: Integrate Google services in SCA compositions + Allow Google Android applications to easily consume business services
Hi Oscar, The proposal is really good. It look likes what I was trying to do a week ago. Unfortunately, I had no success yet on running the calculator sample on SCA due to a lot of Android platform limitations has and a poor support from Android community : ( But for sure, with your help, we can get this sample running soon : ) Just let me know if you have some doubts or other ideas/suggestions : ) Welcome on board ; ) Adriano Crestani On Mon, Mar 31, 2008 at 3:17 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi, Following Jean-Sebastien's comments I've added a Use case to my draft proposal for the Integrate Google services in SCA compositions GSoc08 project. I also revised the deliverables to make sure they were aligned with the overall idea. The proposal can be found at: http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Integrate_Google_services_in_SCA_compositions I greatly appreciate your comments on the Use case (now that the GSoc deadline has been extended). I'm worried that it might not be realistic. I'm also wondering if I should include a similar Use case for the Android project. I briefly revised the proposal for this project as well, comments or suggestions are also welcome. The proposal can be found here: http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Allow_Google_Android_applications_to_easily_consume_business_services In preparation for final submission of the proposals I have posted the updated content on the GSoc webapp. I would like to thank Jean-Sebastien again for his valuable help and most insightful comments. best, -oscar Oscar Castañeda Student of Delft University of Technology http://homepage.mac.com/o.castaneda/ On Mon, Mar 31, 2008 at 12:49 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Oscar Castaneda wrote: Hi, I've posted an update to the draft proposal for the Integrate Google services in SCA compositions GSoc08 project. It can be found at: http://wiki.apache.org/general/OscarCastaneda/GSoC2008/Integrate_Google_services_in_SCA_compositions I would like to thank Jean-Sebastien for his comments, they were really insightful and helped me re-think the project breakdown. You're welcome :) The proposal looks very good to me. Oscar and I have already chatted about it so It would be great if others on tuscany-dev could give feedback too with their perspective. Thanks. Another small comment: Maybe add one or two examples composing GData services (search, calendar, contact, and/or spreadsheet) and other services out there (events, news, weather etc) to do something useful or fun? I don't have a great idea right now though :) Maybe others on the list can think of something... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2177) Incorrect dependencies in tutorial not reported by admin
[ https://issues.apache.org/jira/browse/TUSCANY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2177. - Resolution: Fixed Incorrect dependencies in tutorial not reported by admin - Key: TUSCANY-2177 URL: https://issues.apache.org/jira/browse/TUSCANY-2177 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 The tutorial/assets module currently has incorrect dependency imports. These dependency errors are not correctly reported by the domain admin. The fix is very minor and risk free: - remove the incorrect imports from tutorial/assets/META-INF/sca-contribution.xml - display dependency problems on the admin contributions page (the logic was all there to get the list of problems but they were just not displayed) I'll try to get the fix in the 1.2 release as it's really useful to see contribution dependency errors. -- 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-2176) implementation-ejb JARs missing from assembly
[ https://issues.apache.org/jira/browse/TUSCANY-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2176. - Resolution: Fixed implementation-ejb JARs missing from assembly - Key: TUSCANY-2176 URL: https://issues.apache.org/jira/browse/TUSCANY-2176 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The implementation-ejb and implementation-ejb modules are missing from the distro assembly, preventing the EJB part of the tutorial to work (and actually causing more issues in it as that breaks some wires and the domain admin does not tolerate that kind of errors very well at the moment). -- 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-1659) SDO DateConversion test cases fail under linux
[ https://issues.apache.org/jira/browse/TUSCANY-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani resolved TUSCANY-1659. --- Resolution: Fixed Fixed on revision 643224. I created a SDOSimpleDateFormat that extends the SimpleDateFormat. This new class ensures the time zone is in the abbreviation format. If it's not, it looks for its abbreviation format. SDO DateConversion test cases fail under linux -- Key: TUSCANY-1659 URL: https://issues.apache.org/jira/browse/TUSCANY-1659 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Linux Ubuntu 7.0.4 Reporter: Luciano Resende Assignee: Adriano Crestani Fix For: Java-SDO-Next Attachments: tuscany-1659.tgz The following tests are failing under revision #571238 Tests in error: testConversionsFromDate(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromDateTime(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromDuration(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromYear(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromYearMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromYearMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) Looks like working ok in windows. -- 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
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
