[jira] Updated: (TUSCANY-1483) Static SDO generator: problem with elements named internal*
[ https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1483: - Attachment: 1483-withTestCaseInToolsTest.patch Acted on previous comments. Static SDO generator: problem with elements named internal* --- Key: TUSCANY-1483 URL: https://issues.apache.org/jira/browse/TUSCANY-1483 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Daniel Peter Priority: Minor Fix For: Java-SDO-Next Attachments: 1483-withTestCase.patch, 1483-withTestCaseInToolsTest.patch, 1483.patch, test1483.xsd Hi, I run into a problem with the static generated SDOs, when having a xsd with the following two elements: xsd:element name=abc type=xsd:integer / xsd:element name=internalAbc type=xsd:integer / In the generated Impl class this leads twice to the same constant INTERNAL_ABC. The xsd elements might simply be renamed in order to avoid this clash, but there might be situations where this is not possible. The generator could use a different, less probable prefix (e.g. ___INTERNAL_). Thanks, Daniel. -- 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-1987) Build break in osgi-implementation itest
[ https://issues.apache.org/jira/browse/TUSCANY-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559401#action_12559401 ] Rajini Sivaram commented on TUSCANY-1987: - Felix have provided a proper fix for this issue (http://www.mail-archive.com/[EMAIL PROTECTED]/msg03002.html). This is available from the latest Felix snapshot (1.1.0-SNAPSHOT). At the moment, we are using Felix release 1.0.1. There are some other changes required to Tuscany to move to the newer Felix version, so I will provide another patch to remove the workaround introduced by this one and switch to the latest Felix release. For this release of Tuscany, it would be better to stay with this patch. Tuscany could move to the newer version of Felix when the next version of Felix is released, rather than switch to using the current snapshots (unless the failures reappear). Build break in osgi-implementation itest Key: TUSCANY-1987 URL: https://issues.apache.org/jira/browse/TUSCANY-1987 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Environment: Daily build Reporter: Jean-Sebastien Delfino Assignee: Simon Laws Priority: Blocker Fix For: Java-SCA-1.1 Attachments: implementation-osgi-patch.txt See http://vmbuild.apache.org/continuum/buildResult.action?buildId=37962projectId=277 Error in the osgi-implementation itest, breaking the daily build. I think that this is the random break issue I've seen several times on Linux already discussed with Rajini on the tuscany-dev list a while ago. Rajini was not seeing that issue on Windows and I was seeing it randomly on Linux. I'm putting this issue in the SCA 1.1 release category as I believe it'll probably happen on 1.1 as well. -- 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 runtimes
Jean-Sebastien Delfino wrote: Simon Nash wrote: [snip] a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc) [snip] b) applications, containing only the code and other artifacts required for the application itself [snip] Drop contribution jars into a directory which are then picked up automatically and all contained composites are run [snip] Webapp Construct a webapp Add dependencies (using maven?) for tuscany jars Configure web.xml to include the Tuscany filters [snip] I've been thinking about how to provide useful input here but I'm still a little puzzled as it mixes different topics in one thread. I've left a few snippets above to try to illustrate that, and there's more (about distro packaging for example) in other responses to the thread. Here are the topics I think I've seen: - Does the app developer need to know what Tuscany and dependency JARs are required by his SCA contributions? - Under which circumstances does the app packager want to package the Tuscany and dependency JARs with the application artifacts. - Which containers are we supporting and what kind of integration with them? Tomcat is just one example, Geronimo, JMS providers, embedded Jetty are others. - Does the app developer need to know ahead of time which container integration his app is going to be deployed to. For example can I use the EJB, WS and JMS bindings together in one app, and which container integration is going to support that? - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? Would it make sense to spawn separate threads for these different topics? With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1987) Build break in osgi-implementation itest
[ https://issues.apache.org/jira/browse/TUSCANY-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-1987: Fix Version/s: (was: Java-SCA-1.1) Java-SCA-Next Thanks for the update Rajini. I'll move this JIRA out of 1.1 now and assign to Java-SCA-Next so we remember to follow up. Build break in osgi-implementation itest Key: TUSCANY-1987 URL: https://issues.apache.org/jira/browse/TUSCANY-1987 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Environment: Daily build Reporter: Jean-Sebastien Delfino Assignee: Simon Laws Priority: Blocker Fix For: Java-SCA-Next Attachments: implementation-osgi-patch.txt See http://vmbuild.apache.org/continuum/buildResult.action?buildId=37962projectId=277 Error in the osgi-implementation itest, breaking the daily build. I think that this is the random break issue I've seen several times on Linux already discussed with Rajini on the tuscany-dev list a while ago. Rajini was not seeing that issue on Windows and I was seeing it randomly on Linux. I'm putting this issue in the SCA 1.1 release category as I believe it'll probably happen on 1.1 as well. -- 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-1992) Two versions of stax-api available on some web-apps web-inf\lib folder.
[ https://issues.apache.org/jira/browse/TUSCANY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-1992: Fix Version/s: (was: Java-SCA-1.1) Java-SCA-Next Need to look at for the next release so moving to Java-SCA-Next Two versions of stax-api available on some web-apps web-inf\lib folder. --- Key: TUSCANY-1992 URL: https://issues.apache.org/jira/browse/TUSCANY-1992 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Reporter: Luciano Resende Fix For: Java-SCA-Next stax-api-1.0.1.jar and stax-api-1.0-2.jar are both present in our RC1 distribution, and some webapps are adding them both in the web-inf\lib. I see the issue in calculator-webapp, but we might investigate if other apps are also seeing the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA runtimes
On Jan 15, 2008 5:01 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: [snip] a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc) [snip] b) applications, containing only the code and other artifacts required for the application itself [snip] Drop contribution jars into a directory which are then picked up automatically and all contained composites are run [snip] Webapp Construct a webapp Add dependencies (using maven?) for tuscany jars Configure web.xml to include the Tuscany filters [snip] I've been thinking about how to provide useful input here but I'm still a little puzzled as it mixes different topics in one thread. I've left a few snippets above to try to illustrate that, and there's more (about distro packaging for example) in other responses to the thread. Here are the topics I think I've seen: - Does the app developer need to know what Tuscany and dependency JARs are required by his SCA contributions? - Under which circumstances does the app packager want to package the Tuscany and dependency JARs with the application artifacts. - Which containers are we supporting and what kind of integration with them? Tomcat is just one example, Geronimo, JMS providers, embedded Jetty are others. - Does the app developer need to know ahead of time which container integration his app is going to be deployed to. For example can I use the EJB, WS and JMS bindings together in one app, and which container integration is going to support that? - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? Would it make sense to spawn separate threads for these different topics? -- Jean-Sebastien All these topics seem related to me so so far i think it helps having the one thread about them. Not every email needs to be about them all, just snip out text leaving the bit you want to comment on, threaded news readers make it easy enough to keep track of the discussion. I'd rather have you participate though so do feel welcome to start other related threads. I think we need to keep in mind the bigger overall picture when thinking about these details, if we've been getting too much into the implementation detail would help to step back a bit - the following are the things i think we're trying to do here: 1) applications to contain only the code and other artifacts required for the application itself not Tuscany internals - simple sca contribution jars 2) some sort of runtime(s) which can run those application contribution jars, so that could be things like standalone (command prompt), from testcases, in a webapp, or some customization of something like Tomcat/Geronimo/WebSphere/JBoss etc I think we also need: 3) Those runtimes need to be distributed but the Tuscany download page should have a small number of downloads so its easy for users to work out which to choose 4) To make it easy for newbies to run things so at least one distribution should have prebuilt samples so they can be run out-of-the box without having to be compiled/built and for things to work without having to do much/any messing about with installation/configuration/customizing. 5) Ideally the easy to use distribution is not so large. Do all those sound reasonable? Does anyone want to add/remove/modify anything? ...ant
[jira] Created: (TUSCANY-1996) ConversationEndedException is not thrown.
ConversationEndedException is not thrown. - Key: TUSCANY-1996 URL: https://issues.apache.org/jira/browse/TUSCANY-1996 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Environment: Revision: 596254 Reporter: Ben Smith Fix For: Java-SCA-Next ConversationEndedException is not thrown if you reuse a service after you have ended the conversation or the conversation has expired. Instead it starts a new conversation with the same conversation id. This can be seen in the conversationPreInvoke method in the JDKInvocationHandler. Where conversations are re-used even if they are in the ended state. Ben -- 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: [Java SDO] What should we be attacking?
Have a couple of question about release - What will be the name of the Java SDO release? After checking Java-SDO-Next and Java-SDO-CTS-Next from ASF-JIRA and referring to http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html I have tried to gather a list of all JIRAs (Fixed, Open,...) at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project Also, referring again to - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html, Below are in-progress JIRAs- TUSCANY-1360 TUSCANY-1483 TUSCANY-1293 Are there any other in-progress JIRAs? So we are left with below ones - Simple Starters === TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests Is anybody working on any from the above list? Also please take a look at the cwiki link above to see if any other JIRAs from there are of interest and can be made part of the release. Any other issues/features missed so far in above which can be included? === Regards, Amita On Jan 16, 2008 1:47 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hey Amita, that's great! I guess collating the state of the fixed and unfixed JIRAs, and producing a definitive list of what's going to be in and out is the first step. I think the states and marked fix levels on the JIRAs are all as they should be, so that should be a relatively smooth operation. I'll try to find pointers to the best reference information later in the day and post them. Kelvin. On 16/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I would like to do Release Management activities for this SDO release. It will be a good learning for me. Appreciate your help. Regards, Amita On Jan 15, 2008 6:42 PM, kelvin goodson [EMAIL PROTECTED] wrote: It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: What should we be concentrating our efforts on in SDO Java. I posted a while back to suggest we think about the content of a next release. We've had a few fixes go in recently, but I'd like to see more consideration of release content before we crank the handle. It would be great to see a balance of new features and bug fixes. For my part I want to get back to ... TUSCANY-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot mapping framework to convert DataObjects to and from Java objects as soon as I can. And I believe that at least 1527 can move beyond proof of concept in my sandbox, and become part of the trunk. I've been taking a pass through the SDO java JIRA backlog, and seeing from my perspective what's simple / tricky / big / high priority etc, etc. Of course simplicity is in the eye of the beholder, for example, I don't view the OSGi topic as simple as I don't have experience there, but someone out there may find it so; if so please speak up. The same goes for priority, etc. As you might imagine, in my estimation there are no simple high priority JIRAs left, but there are a few simple medium priority ones, or simple low priority ones that would be good to just get out of the way. These are Simple Starters === TUSCANY-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil:
Re: [Java SDO] What should we be attacking?
Hi Amita, looking at the size of the list of fixed JIRAs and the balance of improvements/New features to bug fixes I would have thought this would warrant a title of Tuscany SDO Java 1.1-incubating I'll respond about the pending JIRAs a bit later. Kelvin. On 16/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Have a couple of question about release - What will be the name of the Java SDO release? After checking Java-SDO-Next and Java-SDO-CTS-Next from ASF-JIRA and referring to http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html I have tried to gather a list of all JIRAs (Fixed, Open,...) at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project Also, referring again to - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html, Below are in-progress JIRAs- TUSCANY-1360 TUSCANY-1483 TUSCANY-1293 Are there any other in-progress JIRAs? So we are left with below ones - Simple Starters === TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests Is anybody working on any from the above list? Also please take a look at the cwiki link above to see if any other JIRAs from there are of interest and can be made part of the release. Any other issues/features missed so far in above which can be included? === Regards, Amita On Jan 16, 2008 1:47 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hey Amita, that's great! I guess collating the state of the fixed and unfixed JIRAs, and producing a definitive list of what's going to be in and out is the first step. I think the states and marked fix levels on the JIRAs are all as they should be, so that should be a relatively smooth operation. I'll try to find pointers to the best reference information later in the day and post them. Kelvin. On 16/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I would like to do Release Management activities for this SDO release. It will be a good learning for me. Appreciate your help. Regards, Amita On Jan 15, 2008 6:42 PM, kelvin goodson [EMAIL PROTECTED] wrote: It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: What should we be concentrating our efforts on in SDO Java. I posted a while back to suggest we think about the content of a next release. We've had a few fixes go in recently, but I'd like to see more consideration of release content before we crank the handle. It would be great to see a balance of new features and bug fixes. For my part I want to get back to ... TUSCANY-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot mapping framework to convert DataObjects to and from Java objects as soon as I can. And I believe that at least 1527 can move beyond proof of concept in my sandbox, and become part of the trunk. I've been taking a pass through the SDO java JIRA backlog, and seeing from my perspective what's simple / tricky / big / high priority etc, etc. Of course simplicity is in the eye of the beholder, for example, I don't view the OSGi topic as simple as I don't have experience there, but someone out there may find it so; if so please speak up. The same goes for priority, etc. As you might imagine, in my estimation there are no simple high priority JIRAs
[VOTE] Release Tuscany Java SCA 1.1-incubating (RC2)
Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC2/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC2/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. Can I ask you to choose a selection of platforms in order to test the webapp samples. In the RELEASE_NOTES we reference - Tomcat 6.0.14 - Geronimo 2.0.2 Tomcat6 jee5 - WebSphere 6.1 fix pack 11 If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch and/or raise jira's targeting the 1.1 release. Vote early, vote often! Thanks, Simon
[jira] Commented: (TUSCANY-1996) ConversationEndedException is not thrown.
[ https://issues.apache.org/jira/browse/TUSCANY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559593#action_12559593 ] Simon Nash commented on TUSCANY-1996: - This behavior is correct for the case of explicitly ending the conversation, but not for the case of the conversation timing out. The following is from the SCA Java Annotations and APIs 1.00 errata at http://www.osoa.org/display/Main/Errata+for+Java+Annotations+and+APIs+V1.00 5. Resolve contradiction regarding ConversationEndedException Description: Section 1.6.2.2 @EndsConversation (lines 409-420) states that when a method is called on a conversational interface after an @EndsConversation has been called, a ConversationEndedException is thrown. This contradicts section 1.6.5 Conversation Lifetime Summary / Ending conversations, lines 494-495, where it states that after an @EndsConversation method has been called (on a service reference) , then a new conversation will automatically be started. ...and... (lines 498-499) if the conversation has timed out, a ConversationEndedException is thrown. Solution: Replace lines 417-420 at the end of section 1.6.2.2 with the following: If a conversation is ended with an explicit outbound call to an @EndsConversation method or a call to ServiceReference.endConversation(), then any subsequent call to an operation on the service reference will start a new conversation. If the conversation ends for any other reason (e.g. a timeout occurred), then until ServiceReference.getConversation().end() is called, the ConversationEndedException will be thrown by any conversational operation. ConversationEndedException is not thrown. - Key: TUSCANY-1996 URL: https://issues.apache.org/jira/browse/TUSCANY-1996 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Environment: Revision: 596254 Reporter: Ben Smith Fix For: Java-SCA-Next ConversationEndedException is not thrown if you reuse a service after you have ended the conversation or the conversation has expired. Instead it starts a new conversation with the same conversation id. This can be seen in the conversationPreInvoke method in the JDKInvocationHandler. Where conversations are re-used even if they are in the ended state. Ben -- 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-1963) callback-ws-client sample fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/TUSCANY-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559605#action_12559605 ] Simon Nash commented on TUSCANY-1963: - Applied the fix to trunk under revision r612527. callback-ws-client sample fails with IndexOutOfBoundsException -- Key: TUSCANY-1963 URL: https://issues.apache.org/jira/browse/TUSCANY-1963 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.1, Java-SCA-Next Reporter: Raymond Feng Assignee: Simon Nash Fix For: Java-SCA-1.1 Buildfile: build.xml run: [java] Jan 11, 2008 11:35:41 AM org.apache.tuscany.sca.node.impl.SCADomainProxyImpl init [java] INFO: Domain will be started stand-alone as domain URL is not provided [java] Jan 11, 2008 11:35:41 AM org.apache.tuscany.sca.domain.impl.SCADomainImpl registerNode [java] INFO: Registered node: http://rfengt60p:4407 at endpoint http://rfengt60p:4407 [java] Jan 11, 2008 11:35:41 AM org.apache.tuscany.sca.node.impl.SCADomainProxyImpl createRuntime [java] INFO: Domain management configured from file:/C:/Apache/tuscany-sca-1.1-incubating/modules/tuscany-node-impl-1.1-incubating.jar [java] Exception in thread main org.apache.tuscany.sca.node.NodeException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:157) [java] at myapp.MyClientImpl.main(MyClientImpl.java:50) [java] Caused by: org.apache.tuscany.sca.node.NodeException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:230) [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:136) [java] at org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54) [java] at org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:149) [java] ... 1 more [java] Caused by: org.apache.tuscany.sca.domain.DomainException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.createRuntime(SCADomainProxyImpl.java:299) [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.addNode(SCADomainProxyImpl.java:350) [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:225) [java] ... 4 more [java] Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:756) [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.createRuntime(SCADomainProxyImpl.java:256) [java] ... 6 more [java] Caused by: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.getFactory(DefaultProviderFactoryExtensionPoint.java:182) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:195) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider.init(RuntimeSCAServiceBindingProvider.java:88) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createServiceBindingProvider(RuntimeSCABindingProviderFactory.java:60) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createServiceBindingProvider(RuntimeSCABindingProviderFactory.java:39) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:195) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addServiceBindingProvider(CompositeActivatorImpl.java:408) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:690) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:748) [java] ... 7 more [java] Caused by: java.lang.reflect.InvocationTargetException [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Embedded tomcat classloading issue
Hi, I ran into a classloading issue with embedded Tomcat. In the helloworld-ws-reference test case, we use SCATestCaseRunner to run the service with binding.ws in a new classloader (CL2) derived from the client-side classloader (CL1). When the embedded tomcat is started, it creates a WebAppClassLoader (CL3) and uses it as the Thread context classloader. The WebAppClassLoader first tries to find a class in the system classloader (which is CL1) before it delegates to its parent (which is set to be CL2). As a result, the JAXBContextImpl is loaded by CL1 instead of CL2 and it causes a ClassCastException against the JAXBContext interface loaded by CL2. In our usage of embedded tomcat, the application is not really a web application. We mostly use the tomcat as an HTTP server. I propose that we replace the heavy WebAppLoader (which handles dynamic reloading too) with an internal implementation which provides CL2 as the classloader. I have tested the code locally. If there is no objection, I'll commit it. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.
Axis binding does not allow external configuration to increase the number of the maximum connections opened. Key: TUSCANY-1997 URL: https://issues.apache.org/jira/browse/TUSCANY-1997 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Environment: Solaris , Windows , Websphere , Tomcat Reporter: Catalin Boloaja In a high volume situation the default setting for Axis2 is 2 connections per host. The default protocol being HTTP 1.1 , this means that only 2 POST requests can be issued at the same time. -- 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]
R1.1 build from a clean repo, was Fwd: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2)
Was anyone sucessful on building the source distribution starting from a clean maven repo ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Jan 16, 2008 4:56 AM Subject: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2) To: tuscany-dev tuscany-dev@ws.apache.org Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC2/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC2/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. Can I ask you to choose a selection of platforms in order to test the webapp samples. In the RELEASE_NOTES we reference - Tomcat 6.0.14 - Geronimo 2.0.2 Tomcat6 jee5 - WebSphere 6.1 fix pack 11 If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch and/or raise jira's targeting the 1.1 release. Vote early, vote often! Thanks, Simon -- 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]
binding.jms reference to non-SCA service
Hi All, Using Tuscany 1.1 RC2 I'm attempting to construct a simple example of an SCA application, which references a remote JMS service, which in a simple case exposes a request type Queue. This is to proxy/facade a pre-existing JMS solution with Tuscany. My SCDL declares a reference to a remote weblogic queue (though I don't believe the provider should matter) as follows: reference name=JMSService promote=JMSClient/jmsService interface.java interface=com.example.JMSService/ binding.jms initialContextFactory=weblogic.jndi.WLInitialContextFactory jndiURL=t3://localhost:7001 destination name=jms/TestRequest create=never / connectionFactory name=jms/TestRequestConnectionFactory / /binding.jms /reference My client attempts to send a String message this remote JMS reference, though when attempted I get the following stack: [java] org.osoa.sca.ServiceUnavailableException: Service not found for component JMSClient reference service (bindingURI=null operation=process). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable Can anyone provide any insight into this issue? Any help would be greatly appreciated, client and log can be at: http://davesowerby.org/jms-reference-client.log http://davesowerby.org/jms-reference-client.zip Cheers, Dave. -- Dave Sowerby MEng MBCS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1998) Can't do a full build from the source distribution with a clean maven repo
Can't do a full build from the source distribution with a clean maven repo -- Key: TUSCANY-1998 URL: https://issues.apache.org/jira/browse/TUSCANY-1998 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.1 This is due to some duplicity in saxon dependencies. We decided to use saxon 8.7, but some modules are downloading and installing the saxon 9.x release and maven is using that in some cases. Removing the following seems to fix the issue : - remove modules/saxon project - remove reference to saxon project from databinding-saxom - remove saxon download ant script from implementation-xquery -- 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] Release Tuscany Java SCA 1.1-incubating (RC2)
Binary distribution looks ok, I have tested all the webapps on the following host environments : - Tomcat 5.5.x, Tomcat 6.0.x, Jetty 6.1.x, WAS 6.1 FixPack 9 I had issues trying to compile the source distribution from a clean maven repo, and I could only get a clean build after removing all references to saxon 9.x dependencies (TUSCANY-1998). I also noticed TUSCANY-1984. I'll commit a fix for these issues on the R1.1 branch. -1 to release RC2 given these issues. [1] https://issues.apache.org/jira/browse/TUSCANY-1998 [2] https://issues.apache.org/jira/browse/TUSCANY-1984 On Jan 16, 2008 4:56 AM, Simon Laws [EMAIL PROTECTED] wrote: Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC2/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC2/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. Can I ask you to choose a selection of platforms in order to test the webapp samples. In the RELEASE_NOTES we reference - Tomcat 6.0.14 - Geronimo 2.0.2 Tomcat6 jee5 - WebSphere 6.1 fix pack 11 If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch and/or raise jira's targeting the 1.1 release. Vote early, vote often! Thanks, Simon -- 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] Resolved: (TUSCANY-1984) Maven build of tools\wsdl2java fails unless using 'clean' option
[ https://issues.apache.org/jira/browse/TUSCANY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1984. -- Resolution: Fixed Fix Version/s: Java-SCA-1.1 Fixed under revision #612683 Maven build of tools\wsdl2java fails unless using 'clean' option - Key: TUSCANY-1984 URL: https://issues.apache.org/jira/browse/TUSCANY-1984 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Reporter: ant elder Assignee: Luciano Resende Fix For: Java-SCA-1.1 Building tools\wsdl2java alwasy fails with compile errors unless you use the Maven clean option. To recrate: mvn clean install -o mvn -o the first one always works, the second one always fails. -- 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] Assigned: (TUSCANY-1984) Maven build of tools\wsdl2java fails unless using 'clean' option
[ https://issues.apache.org/jira/browse/TUSCANY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1984: Assignee: Luciano Resende Maven build of tools\wsdl2java fails unless using 'clean' option - Key: TUSCANY-1984 URL: https://issues.apache.org/jira/browse/TUSCANY-1984 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Reporter: ant elder Assignee: Luciano Resende Fix For: Java-SCA-1.1 Building tools\wsdl2java alwasy fails with compile errors unless you use the Maven clean option. To recrate: mvn clean install -o mvn -o the first one always works, the second one always fails. -- 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: R1.1 build from a clean repo, was Fwd: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2)
Hi, I just did a top-down build for the src distro against a clean local maven repo and it was successful. I don't see the build issues that Luciano reported. Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Wednesday, January 16, 2008 3:12 PM Subject: R1.1 build from a clean repo, was Fwd: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2) Was anyone sucessful on building the source distribution starting from a clean maven repo ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Jan 16, 2008 4:56 AM Subject: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2) To: tuscany-dev tuscany-dev@ws.apache.org Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC2/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC2/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. Can I ask you to choose a selection of platforms in order to test the webapp samples. In the RELEASE_NOTES we reference - Tomcat 6.0.14 - Geronimo 2.0.2 Tomcat6 jee5 - WebSphere 6.1 fix pack 11 If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch and/or raise jira's targeting the 1.1 release. Vote early, vote often! Thanks, Simon -- 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]
[jira] Updated: (TUSCANY-1998) Can't do a full build from the source distribution with a clean maven repo
[ https://issues.apache.org/jira/browse/TUSCANY-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1998: - Attachment: tuscany-1998.patch Removing the following seems to fix the issue : - remove modules/saxon project - remove reference to saxon project from databinding-saxom - remove saxon download ant script from implementation-xquery - remove saxon download ant script from samples/quote-xquery Clean build from 1.1 branch Clean build from source distribution generated from the 1.1 branch Need to do some testing with samples that have saxon dependency just to double check Can't do a full build from the source distribution with a clean maven repo -- Key: TUSCANY-1998 URL: https://issues.apache.org/jira/browse/TUSCANY-1998 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.1 Attachments: tuscany-1998.patch This is due to some duplicity in saxon dependencies. We decided to use saxon 8.7, but some modules are downloading and installing the saxon 9.x release and maven is using that in some cases. Removing the following seems to fix the issue : - remove modules/saxon project - remove reference to saxon project from databinding-saxom - remove saxon download ant script from implementation-xquery -- 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: R1.1 build from a clean repo, was Fwd: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2)
Just in case others see the same issue I was seeing, I have attached a patch for TUSCANY-1998 BTW, did you have a straight clean build on the first try ? [1] https://issues.apache.org/jira/browse/TUSCANY-1998 On Jan 16, 2008 8:24 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I just did a top-down build for the src distro against a clean local maven repo and it was successful. I don't see the build issues that Luciano reported. Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Wednesday, January 16, 2008 3:12 PM Subject: R1.1 build from a clean repo, was Fwd: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2) Was anyone sucessful on building the source distribution starting from a clean maven repo ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Jan 16, 2008 4:56 AM Subject: [VOTE] Release Tuscany Java SCA 1.1-incubating (RC2) To: tuscany-dev tuscany-dev@ws.apache.org Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC2/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC2/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. Can I ask you to choose a selection of platforms in order to test the webapp samples. In the RELEASE_NOTES we reference - Tomcat 6.0.14 - Geronimo 2.0.2 Tomcat6 jee5 - WebSphere 6.1 fix pack 11 If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch and/or raise jira's targeting the 1.1 release. Vote early, vote often! Thanks, Simon -- 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] -- 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]
