[jira] Resolved: (TUSCANY-2043) documentBaseURI is null when multiple wsdls in contribution with same namespace
[ https://issues.apache.org/jira/browse/TUSCANY-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-2043. - Resolution: Fixed I have put some changes in to solve the immediate issue. In particular the XSD aggregation now maintains all original XSD and the WSDL determination algorithm in the Axis2 providers now operates correctly when recursing into the aggregated types. I have raised http://issues.apache.org/jira/browse/TUSCANY-2045 to track the subsequent proposal for a more targeted approach to WSDL/XSD artifact resolution. documentBaseURI is null when multiple wsdls in contribution with same namespace -- Key: TUSCANY-2043 URL: https://issues.apache.org/jira/browse/TUSCANY-2043 Project: Tuscany Issue Type: Bug Reporter: Lou Amodeo Assignee: Simon Laws Fix For: Java-SCA-1.2 Attachments: helloworld-ws-asynch.jar I have a case where there are 2 wsdl files in the contribution with the same namespace. After the WSDL resolution the documentBaseURI attribute of the wsdl's DefinitionImpl is null. The is normally completed in the WebServiceBindingProcessor.resolve(). In this particular case there are 2 binding.ws elements in the contribution. One for the service and one for its callback binding. If I change the TNS of one of the WSDL files then the documnetBaseURI is filled in during the WebServiceBindingProcessor.resolve. So it appears there is in issue in the WSDL Model resolver when it finds multiple WSDL files with the same TNS. -- 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] Closed: (TUSCANY-2044) BUILD FAILURE : Building Apache Tuscany SCA RMI Host Extension Point
[ https://issues.apache.org/jira/browse/TUSCANY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan closed TUSCANY-2044. Resolution: Fixed Fixed by Raymond. The recent build has gone thro for this module. Thanks Raymond. BUILD FAILURE : Building Apache Tuscany SCA RMI Host Extension Point Key: TUSCANY-2044 URL: https://issues.apache.org/jira/browse/TUSCANY-2044 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan [INFO] [INFO] Building Apache Tuscany SCA RMI Host Extension Point [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/host-rmi/target [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/host-rmi/target/classes [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/host-rmi/target/test-classes [INFO] Deleting directory /home/continuum/data/working-directory/277/modules/host-rmi/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 7 source files to /home/continuum/data/working-directory/277/modules/host-rmi/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 1 source file to /home/continuum/data/working-directory/277/modules/host-rmi/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /home/continuum/data/working-directory/277/modules/host-rmi/target/surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.host.rmi.RMIHostImplTestCase Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.111 sec FAILURE! testFindServiceBadHost(org.apache.tuscany.sca.host.rmi.RMIHostImplTestCase) Time elapsed: 0.969 sec ERROR! java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:334) at sun.rmi.registry.RegistryImpl.lookup(RegistryImpl.java:104) at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source) at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:386) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:250) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343) at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at org.apache.tuscany.sca.host.rmi.DefaultRMIHost.findService(DefaultRMIHost.java:113) at org.apache.tuscany.sca.host.rmi.RMIHostImplTestCase.testFindServiceBadHost(RMIHostImplTestCase.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at
[jira] Created: (TUSCANY-2046) BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests
BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests --- Key: TUSCANY-2046 URL: https://issues.apache.org/jira/browse/TUSCANY-2046 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan [INFO] [INFO] Building Apache Tuscany SCA Multiple WSDL File Support Integration Tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 4 source files to /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 2 source files to /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.itest.ManualWSDLTestCase org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.host.http.ServletMappingException: java.net.BindException: Address already in use at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at org.apache.tuscany.sca.itest.ManualWSDLTestCase.init(ManualWSDLTestCase.java:41) 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.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Caused by: org.apache.tuscany.sca.host.http.ServletMappingException: java.net.BindException: Address already in use at org.apache.tuscany.sca.http.jetty.JettyServer.addServletMapping(JettyServer.java:207) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(Axis2ServiceProvider.java:244) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start(Axis2ServiceBindingProvider.java:94) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:484) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) ... 20 more Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) at
[jira] Assigned: (TUSCANY-2046) BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests
[ https://issues.apache.org/jira/browse/TUSCANY-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-2046: --- Assignee: Simon Laws BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests --- Key: TUSCANY-2046 URL: https://issues.apache.org/jira/browse/TUSCANY-2046 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assignee: Simon Laws [INFO] [INFO] Building Apache Tuscany SCA Multiple WSDL File Support Integration Tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 4 source files to /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 2 source files to /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.itest.ManualWSDLTestCase org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.host.http.ServletMappingException: java.net.BindException: Address already in use at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at org.apache.tuscany.sca.itest.ManualWSDLTestCase.init(ManualWSDLTestCase.java:41) 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.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Caused by: org.apache.tuscany.sca.host.http.ServletMappingException: java.net.BindException: Address already in use at org.apache.tuscany.sca.http.jetty.JettyServer.addServletMapping(JettyServer.java:207) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(Axis2ServiceProvider.java:244) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start(Axis2ServiceBindingProvider.java:94) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:484) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221) at
[jira] Created: (TUSCANY-2047) Address FIXME in SCABindingProcessor constructor
Address FIXME in SCABindingProcessor constructor Key: TUSCANY-2047 URL: https://issues.apache.org/jira/browse/TUSCANY-2047 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-1.2 Currently the SCABindingProcessor sports two contructors. Only one is required and will allows this binding processor to be loaded using the usual extension loading mechanism. So this change should remove the constuctor marked with FIXME and reorder the various parts of the ReallySmallRuntime and ReallySmallRuntime builder to ensure that the SCABindingProcess is correctly loaded -- 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-2046) BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests
[ https://issues.apache.org/jira/browse/TUSCANY-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569262#action_12569262 ] Simon Laws commented on TUSCANY-2046: - Have updated the itest/wsdl-multiple to use port 8085 rather than port 8080. I'll resolve this JIRA if the next build gets past this test. BUILD FAILURE : Apache Tuscany SCA Multiple WSDL File Support Integration Tests --- Key: TUSCANY-2046 URL: https://issues.apache.org/jira/browse/TUSCANY-2046 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assignee: Simon Laws [INFO] [INFO] Building Apache Tuscany SCA Multiple WSDL File Support Integration Tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes [INFO] Deleting directory /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 4 source files to /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 2 source files to /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /home/continuum/data/working-directory/277/itest/wsdl-multiple/target/surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.itest.ManualWSDLTestCase org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.host.http.ServletMappingException: java.net.BindException: Address already in use at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at org.apache.tuscany.sca.itest.ManualWSDLTestCase.init(ManualWSDLTestCase.java:41) 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.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Caused by: org.apache.tuscany.sca.host.http.ServletMappingException: java.net.BindException: Address already in use at org.apache.tuscany.sca.http.jetty.JettyServer.addServletMapping(JettyServer.java:207) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(Axis2ServiceProvider.java:244) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start(Axis2ServiceBindingProvider.java:94) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:484) at
[jira] Assigned: (TUSCANY-2047) Address FIXME in SCABindingProcessor constructor
[ https://issues.apache.org/jira/browse/TUSCANY-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-2047: --- Assignee: Simon Laws Address FIXME in SCABindingProcessor constructor Key: TUSCANY-2047 URL: https://issues.apache.org/jira/browse/TUSCANY-2047 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: Simon Laws Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-1.2 Currently the SCABindingProcessor sports two contructors. Only one is required and will allows this binding processor to be loaded using the usual extension loading mechanism. So this change should remove the constuctor marked with FIXME and reorder the various parts of the ReallySmallRuntime and ReallySmallRuntime builder to ensure that the SCABindingProcess is correctly loaded -- 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-2047) Address FIXME in SCABindingProcessor constructor
[ https://issues.apache.org/jira/browse/TUSCANY-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-2047. - Resolution: Fixed Changes applied referring to this JIRA Address FIXME in SCABindingProcessor constructor Key: TUSCANY-2047 URL: https://issues.apache.org/jira/browse/TUSCANY-2047 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: Simon Laws Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-1.2 Currently the SCABindingProcessor sports two contructors. Only one is required and will allows this binding processor to be loaded using the usual extension loading mechanism. So this change should remove the constuctor marked with FIXME and reorder the various parts of the ReallySmallRuntime and ReallySmallRuntime builder to ensure that the SCABindingProcess is correctly loaded -- 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]
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=51065projectId=277 Build statistics: State: Error Previous State: Failed Started at: Fri 15 Feb 2008 04:04:02 -0800 Finished at: Fri 15 Feb 2008 05:03:09 -0800 Total time: 59m 7s Build Trigger: Schedule Build Number: 45 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: antelder @ Fri 15 Feb 2008 03:26:52 -0800 Comment: JMS support for a temporary response destination Files changed: /incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/impl/JMSBinding.java ( 628019 ) /incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/JMSBindingInvoker.java ( 628019 ) Changed: antelder @ Fri 15 Feb 2008 03:28:19 -0800 Comment: Add itest for temporary response destinations Files changed: /incubator/tuscany/java/sca/itest/jms/src/main/resources/dynamic ( 628020 ) /incubator/tuscany/java/sca/itest/jms/src/main/resources/dynamic/client.composite ( 628020 ) /incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/DynamicReplyQTestCase.java ( 628020 ) Changed: antelder @ Fri 15 Feb 2008 03:46:33 -0800 Comment: Simplify by using a temp response queue Files changed: /incubator/tuscany/java/sca/samples/helloworld-jms-webapp/README ( 628028 ) /incubator/tuscany/java/sca/samples/helloworld-jms-webapp/src/main/webapp/META-INF/HelloWorld.composite ( 628028 ) /incubator/tuscany/java/sca/samples/helloworld-jms-webapp/src/main/webapp/hello.jsp ( 628028 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1025 Failures: 4 Total time: 1832220 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=51065projectId=277 Build statistics: State: Error Previous State: Failed Started at: Fri 15 Feb 2008 04:04:02 -0800 Finished at: Fri 15 Feb 2008 05:03:09 -0800 Total time: 59m 7s Build Trigger: Schedule Build Number: 45 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: antelder @ Fri 15 Feb 2008 03:26:52 -0800 Comment: JMS support for a temporary response destination Files changed: /incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/impl/JMSBinding.java ( 628019 ) /incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/JMSBindingInvoker.java ( 628019 ) Changed: antelder @ Fri 15 Feb 2008 03:28:19 -0800 Comment: Add itest for temporary response destinations Files changed: /incubator/tuscany/java/sca/itest/jms/src/main/resources/dynamic ( 628020 ) /incubator/tuscany/java/sca/itest/jms/src/main/resources/dynamic/client.composite ( 628020 ) /incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/DynamicReplyQTestCase.java ( 628020 ) Changed: antelder @ Fri 15 Feb 2008 03:46:33 -0800 Comment: Simplify by using a temp response queue Files changed: /incubator/tuscany/java/sca/samples/helloworld-jms-webapp/README ( 628028 ) /incubator/tuscany/java/sca/samples/helloworld-jms-webapp/src/main/webapp/META-INF/HelloWorld.composite ( 628028 ) /incubator/tuscany/java/sca/samples/helloworld-jms-webapp/src/main/webapp/hello.jsp ( 628028 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1025 Failures: 4 Total time: 1832220 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at
[jira] Assigned: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-2042:
---
Assignee: Simon Laws
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Assignee: Simon Laws
Fix For: Java-SCA-Next
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
[jira] Closed: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-2042.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.2
I just tried this with the Auto generation part of itest/wsdl-multiple. I
stopped the Axis2ServiceBindingProvider in the debugger at the code where the
WSDL is generated...
if (contract == null) {
contract = service.getInterfaceContract().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
Look at the contract generated for the Java interface...
public interface HelloWorldService {
public void getGreetings(String name);
}
Both request and response messages are generated. I am on Axis2 1.3.
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Assignee: Simon Laws
Fix For: Java-SCA-1.2
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput:
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=51091projectId=277 Build statistics: State: Error Previous State: Building Started at: Fri 15 Feb 2008 07:06:27 -0800 Finished at: Fri 15 Feb 2008 08:04:19 -0800 Total time: 57m 51s Build Trigger: Schedule Build Number: 45 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: slaws @ Fri 15 Feb 2008 05:07:00 -0800 Comment: TUSCANY-2046 Make itest use port 8085 rather than 8080 Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/auto-wsdl.composite ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/manual-wsdl.composite ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldCallback.wsdl ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldService.wsdl ( 628050 ) Changed: slaws @ Fri 15 Feb 2008 05:14:14 -0800 Comment: TUSCANY-2047 Address a FIXME in the SCABindingProcessor to allow the binding processor to be loaded through the normal extension loading process rather than being created explicitly in the ReallySmallRuntime. In theory this would make it easier for people to provide their own binding.sca implementation. Files changed: /incubator/tuscany/java/sca/modules/binding-sca/src/main/java/org/apache/tuscany/sca/binding/sca/impl/SCABindingFactoryImpl.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/main/java/org/apache/tuscany/sca/binding/sca/xml/SCABindingProcessor.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java ( 628054 ) /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/ReallySmallRuntime.java ( 628054 ) /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/ReallySmallRuntimeBuilder.java ( 628054 ) Changed: slaws @ Fri 15 Feb 2008 05:15:58 -0800 Comment: Make the satic Domain instance protected so that I can get at it from a class that extends the domain. Files changed: /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/SCADomain.java ( 628057 ) Changed: slaws @ Fri 15 Feb 2008 05:42:24 -0800 Comment: Add some traps around the domain cleanup to remove some null pointer exceptions from the continuum output to make the real error a little clearer Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/AutoWSDLTestCase.java ( 628063 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/ManualWSDLTestCase.java ( 628063 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1023 Failures: 0 Total time: 932533 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=51091projectId=277 Build statistics: State: Error Previous State: Building Started at: Fri 15 Feb 2008 07:06:27 -0800 Finished at: Fri 15 Feb 2008 08:04:19 -0800 Total time: 57m 51s Build Trigger: Schedule Build Number: 45 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: slaws @ Fri 15 Feb 2008 05:07:00 -0800 Comment: TUSCANY-2046 Make itest use port 8085 rather than 8080 Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/auto-wsdl.composite ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/manual-wsdl.composite ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldCallback.wsdl ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldService.wsdl ( 628050 ) Changed: slaws @ Fri 15 Feb 2008 05:14:14 -0800 Comment: TUSCANY-2047 Address a FIXME in the SCABindingProcessor to allow the binding processor to be loaded through the normal extension loading process rather than being created explicitly in the ReallySmallRuntime. In theory this would make it easier for people to provide their own binding.sca implementation. Files changed: /incubator/tuscany/java/sca/modules/binding-sca/src/main/java/org/apache/tuscany/sca/binding/sca/impl/SCABindingFactoryImpl.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/main/java/org/apache/tuscany/sca/binding/sca/xml/SCABindingProcessor.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java ( 628054 ) /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/ReallySmallRuntime.java ( 628054 ) /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/ReallySmallRuntimeBuilder.java ( 628054 ) Changed: slaws @ Fri 15 Feb 2008 05:15:58 -0800 Comment: Make the satic Domain instance protected so that I can get at it from a class that extends the domain. Files changed: /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/SCADomain.java ( 628057 ) Changed: slaws @ Fri 15 Feb 2008 05:42:24 -0800 Comment: Add some traps around the domain cleanup to remove some null pointer exceptions from the continuum output to make the real error a little clearer Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/AutoWSDLTestCase.java ( 628063 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/ManualWSDLTestCase.java ( 628063 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1023 Failures: 0 Total time: 932533 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at
AW: [jira] Commented: (TUSCANY-2028) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter)
Hi Simon, yes, with version 1.1 it works fine. I also readded the test with contribute to Apache flag set. Thanks a lot for your effort! Bye, Daniel -Ursprüngliche Nachricht- Von: Simon Laws (JIRA) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 15. Februar 2008 16:22 An: Stucky, Daniel, M-ED Betreff: [jira] Commented: (TUSCANY-2028) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) [ https://issues.apache.org/jira/browse/TUSCANY-2028?page=com.at lassian.jira.plugin.system.issuetabpanels:comment-tabpanelfoc usedCommentId=12569286#action_12569286 ] Simon Laws commented on TUSCANY-2028: - Hi Daniel I ran up your test case against the latest code in trunk and and this is the result I see... Gamma:start(), conversationId=d94c7a1a-8f4e-417e-befd-91145ebcaff6 Alpha: Conversation to gamma exists. conversationId=d94c7a1a-8f4e-417e-befd-91145ebcaff6 Gamma:doSomething(), conversationId=d94c7a1a-8f4e-417e-befd-91145ebcaff6 Alpha: Conversation to gamma exists. conversationId=d94c7a1a-8f4e-417e-befd-91145ebcaff6 Gamma:stop(), conversationId=d94c7a1a-8f4e-417e-befd-91145ebcaff6 I then when back and ran it against previous versions.. 1.0.1 (which you are using) run: [java] Starting ... [java] test.composite ready !!! [java] Gamma:start(), conversationId=db6b5594-fcb5-48b7-a1ef-6636baa3ec8c [java] Alpha: Conversation to gamma is null [java] Gamma:doSomething(), conversationId=ddaa67c3-34a5-4083-a41c-3d306f8a3ab0 [java] Alpha: Conversation to gamma exists. conversationId=ddaa67c3-34a5-4083-a41c-3d306f8a3ab0 [java] Gamma:stop(), conversationId=ddaa67c3-34a5-4083-a41c-3d306f8a3ab0 [java] Stopping ... [java] finished. Looks duff 1.1 run: [java] Starting ... [java] test.composite ready !!! [java] Gamma:start(), conversationId=9a211f55-176e-4eef-aaa2-c423f1f9f938 [java] Alpha: Conversation to gamma exists. conversationId=9a211f55-176e-4eef-aaa2-c423f1f9f938 [java] Gamma:doSomething(), conversationId=9a211f55-176e-4eef-aaa2-c423f1f9f938 [java] Alpha: Conversation to gamma exists. conversationId=9a211f55-176e-4eef-aaa2-c423f1f9f938 [java] Gamma:stop(), conversationId=9a211f55-176e-4eef-aaa2-c423f1f9f938 [java] Stopping ... [java] finished. Looks OK So it seems that a fix went in for this between 1.0.1 and 1.1. Can you try with 1.1 or the latest code from trunk to confirm. Thanks for the great test case by the way. It let me very easily confirm this. Would you be willing to re-add it to this JIRA with the contribute to Apache flag set. If so I'll add it to our callable reference itests so that we keep an eye on this specific scenario. Simon Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) -- Key: TUSCANY-2028 URL: https://issues.apache.org/jira/browse/TUSCANY-2028 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: test.zip I have 3 components: Alpha, Beta and Gamma, where Gamma's Interface is marked with @Conversational and @Scope(CONVERSATION). I want Alpha to call a method on Beta that creates a conversation with Gamma and returns a reference to Gamma. Then I want to reuse that conversation to Gamma from Alpha. Therefore I let Alpha call method Beta.getRef(). Inside this method, a reference to Gamma is created via componentContext.getServiceReference() and the conversation is initialized by calling method Gamma.init(). Beta.getRef() returns a CallableReferenceGamma. So far it works, but as soon as I call a method on that reference from within Alpha, a new Conversation is initialized, the Conversation created between Beta and Gamma is not reused. See the original post on the mailing list: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/% [EMAIL PROTECTED] e And the answer by Simon Laws: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/% [EMAIL PROTECTED] -- 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] Closed: (TUSCANY-2028) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter)
[ https://issues.apache.org/jira/browse/TUSCANY-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-2028. --- Resolution: Fixed Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.2 Great, thanks Daniel. Also thanks for the test I'll go ahead and merge it into the itest. Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) -- Key: TUSCANY-2028 URL: https://issues.apache.org/jira/browse/TUSCANY-2028 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Simon Laws Fix For: Java-SCA-1.2 Attachments: test.zip, test.zip I have 3 components: Alpha, Beta and Gamma, where Gamma's Interface is marked with @Conversational and @Scope(CONVERSATION). I want Alpha to call a method on Beta that creates a conversation with Gamma and returns a reference to Gamma. Then I want to reuse that conversation to Gamma from Alpha. Therefore I let Alpha call method Beta.getRef(). Inside this method, a reference to Gamma is created via componentContext.getServiceReference() and the conversation is initialized by calling method Gamma.init(). Beta.getRef() returns a CallableReferenceGamma. So far it works, but as soon as I call a method on that reference from within Alpha, a new Conversation is initialized, the Conversation created between Beta and Gamma is not reused. See the original post on the mailing list: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] And the answer by Simon Laws: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] -- 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-2028) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter)
[ https://issues.apache.org/jira/browse/TUSCANY-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569295#action_12569295 ] Daniel Stucky commented on TUSCANY-2028: Yes, I tested it with version 1.1 the test now completes as expected.. Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) -- Key: TUSCANY-2028 URL: https://issues.apache.org/jira/browse/TUSCANY-2028 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: test.zip, test.zip I have 3 components: Alpha, Beta and Gamma, where Gamma's Interface is marked with @Conversational and @Scope(CONVERSATION). I want Alpha to call a method on Beta that creates a conversation with Gamma and returns a reference to Gamma. Then I want to reuse that conversation to Gamma from Alpha. Therefore I let Alpha call method Beta.getRef(). Inside this method, a reference to Gamma is created via componentContext.getServiceReference() and the conversation is initialized by calling method Gamma.init(). Beta.getRef() returns a CallableReferenceGamma. So far it works, but as soon as I call a method on that reference from within Alpha, a new Conversation is initialized, the Conversation created between Beta and Gamma is not reused. See the original post on the mailing list: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] And the answer by Simon Laws: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] -- 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-2028) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter)
[ https://issues.apache.org/jira/browse/TUSCANY-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Stucky updated TUSCANY-2028: --- Attachment: test.zip Readded for test integration Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) -- Key: TUSCANY-2028 URL: https://issues.apache.org/jira/browse/TUSCANY-2028 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: test.zip, test.zip I have 3 components: Alpha, Beta and Gamma, where Gamma's Interface is marked with @Conversational and @Scope(CONVERSATION). I want Alpha to call a method on Beta that creates a conversation with Gamma and returns a reference to Gamma. Then I want to reuse that conversation to Gamma from Alpha. Therefore I let Alpha call method Beta.getRef(). Inside this method, a reference to Gamma is created via componentContext.getServiceReference() and the conversation is initialized by calling method Gamma.init(). Beta.getRef() returns a CallableReferenceGamma. So far it works, but as soon as I call a method on that reference from within Alpha, a new Conversation is initialized, the Conversation created between Beta and Gamma is not reused. See the original post on the mailing list: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] And the answer by Simon Laws: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] -- 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: Support for Atom using Apache Abdera
I have created a JIRA to track this issue, and will try start some investigation on this area. [1] http://issues.apache.org/jira/browse/TUSCANY-2048 On Tue, Oct 16, 2007 at 8:21 AM, Luciano Resende [EMAIL PROTECTED] wrote: On the following thread [1] there was mentioned that we might want to start using Apache Abdera to support our Feed integration story. - Support for Atom using Apache Abdera Abdera just released their 0.3.0, I've started to look at it and it looks pretty good. I think we should try to port our Atom/RSS binding to it and see how it compares with the Rome library which we are currently using. My understanding is that Abdera does not support RSS yet, and I guess this is ok with us, but I just want to trigger some discussion to see what others thing about the subject, [1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg01979.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error adding user to a given role in Continuum (vmbuild1)
I have created a JIRA to track this issue : https://issues.apache.org/jira/browse/INFRA-1525 On Fri, Feb 15, 2008 at 4:57 AM, sebb [EMAIL PROTECTED] wrote: On 15/02/2008, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to give user (svkrish) more karma towards the Tuscany build project at vmbuild1 continuum, but when I click on edit roles, I keep getting the following message : Current User: Luciano Resende HTTP ERROR: 500 org.codehaus.plexus.redback.role.model.ModelRole cannot be cast to org.codehaus.plexus.redback.rbac.Role RequestURI=/continuum/security/assignments.action Any ideas ? Any help would be appreciated !!! FYI: I had the exact same problem. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Given that this interface allows an Invoker to implement an allowsPassByReference method, could we rename PassByValueAware to PassByReferenceInvoker? [EMAIL PROTECTED] wrote: Author: rfeng Date: Fri Feb 15 12:26:39 2008 New Revision: 628163 URL: http://svn.apache.org/viewvc?rev=628163view=rev Log: Add the PassByValueAware as an optional SPI for Invoker/Intercetors to support Pass-by-value -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA and Databases
John Hunt wrote: Dear All, I have a question around SCA and Java embedded in a database. How feasible is it to embedded SCA within say the Java VM running within an Oracle database, either to provide a service or as a client to call a service. I have a scenario in mind that goes essentially like this: 1. Some database logic (e.g. PL/SQL) calls a piece of Java code 2. Java code needs to call out to an external service – for example to access an external Work Order system to obtain a new work order id 3. Java code calls an SCA client, using (say) the Web Services binding to access the remote service direct from within the database 4. Obtains a new id back and continues? Obviously the Database JVM must be able to support the appropriate version of Java etc. but what else might be required. I think it's an interesting scenario. We could run SCA compositions inside a database server, which would become just another node in an SCA domain. Nothing else is required, embedding an SCA runtime in your JVM should be easy, you'll just need to do what most of our J2SE samples do to bootstrap an SCA runtime and load it with your composite. Potentially hosting services is more of an issue – however, in some cases it might be useful to define a Java POJO that will invoke PL/SQL within the database for performance issues (obviously we could create a POJO external to the database that could call the PL/SQL / stored procedures externally). Yes exactly, the POJO could just perform local calls to the database PL/SQL or stored procedures. However, I suspect that this is a rather more problematic area. For example, depending upon the binding selected what functionality is required in the database - how would a web service, rmi or jms binding be supported (if indeed at all). I don't see any big problems here :) you just need to place the Tuscany binding extension on your classpath, RMI, WS, JMS should just work as-is, as in our J2SE samples, then you just add the desired binding to the service implemented by your POJO, in your composite file. That's all. In terms of real world scenarios I know of numerous situations in which the SCA client in the database scenario would be very useful. I have less “real world” scenarios for the service in the database example. But should the ability to at least run an SCA Client from within the database be a supported SCA scenario? I would be very interested to know what the SCA Dev community think about this. Regards, John I think it's a very interesting scenario and we should support it! Do you want to start working on it? Do you need pointers to the samples that bootstrap the runtime or have you already played with them? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
[EMAIL PROTECTED] wrote: Jean-sebastien, Qualified = target namespace?or wsdl name? Say my wsdl is named aaa.wsdl do I reference it by http://aaa ? Sorry for the slow response. I have been out sick for the last few days. The following definitely works. Other things might work as well, but I haven't tried them. The filename can be anything.wsdl as Sebastien says. (The anything part isn't used by Tuscany.) When you reference the WSDL in your .composite using interface.wsdl interface=mynamespace#wsdl.interface(myporttype) / you need to replace mynamespace and myporttype in the above line to correspond with the actual QName of the portType as defined in your .wsdl file. Simon Thx clemens -Original Message- From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: 2/11/08 6:33 PM Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. You don't even need an include, just place the WSDL file anywhere inside your SCA contribution (JAR or folder), reference its qualified name from your .composite and we should find it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
On Feb 15, 0008 4:09 PM, Continuum VMBuild Server [EMAIL PROTECTED] wrote: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=51091projectId=277 Build statistics: State: Error Previous State: Building Started at: Fri 15 Feb 2008 07:06:27 -0800 Finished at: Fri 15 Feb 2008 08:04:19 -0800 Total time: 57m 51s Build Trigger: Schedule Build Number: 45 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: slaws @ Fri 15 Feb 2008 05:07:00 -0800 Comment: TUSCANY-2046 Make itest use port 8085 rather than 8080 Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/auto- wsdl.composite ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/manual- wsdl.composite ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldCallback.wsdl ( 628050 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldService.wsdl ( 628050 ) Changed: slaws @ Fri 15 Feb 2008 05:14:14 -0800 Comment: TUSCANY-2047 Address a FIXME in the SCABindingProcessor to allow the binding processor to be loaded through the normal extension loading process rather than being created explicitly in the ReallySmallRuntime. In theory this would make it easier for people to provide their own binding.sca implementation. Files changed: /incubator/tuscany/java/sca/modules/binding-sca/src/main/java/org/apache/tuscany/sca/binding/sca/impl/SCABindingFactoryImpl.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/main/java/org/apache/tuscany/sca/binding/sca/xml/SCABindingProcessor.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java ( 628054 ) /incubator/tuscany/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java ( 628054 ) /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/ReallySmallRuntime.java ( 628054 ) /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/ReallySmallRuntimeBuilder.java ( 628054 ) Changed: slaws @ Fri 15 Feb 2008 05:15:58 -0800 Comment: Make the satic Domain instance protected so that I can get at it from a class that extends the domain. Files changed: /incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/SCADomain.java ( 628057 ) Changed: slaws @ Fri 15 Feb 2008 05:42:24 -0800 Comment: Add some traps around the domain cleanup to remove some null pointer exceptions from the continuum output to make the real error a little clearer Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/AutoWSDLTestCase.java ( 628063 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/ManualWSDLTestCase.java ( 628063 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1023 Failures: 0 Total time: 932533 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand (AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Raymond Feng wrote: My preference is to keep PassByValue as the prefix for the following reasons. 1) The invokers implement this interface only for the cases to enforece pass-by-value for remotable interfaces. Invocations over local interfaces (pass-by-reference) don't even care about this flag. 2) The allowsPassByReference() method basically tells if it's safe to pass data as-is without violating the pass-by-value semantics. Having a SomethingPassByValue interface provide an allowsPassByReference method is really confusing IMHO. I think we should use a consistent terminology with either passByValue or passByReference but not a mix of both. Initially, I was thinking about PassByValueInvoker but I found it a bit misleading as it doesn't extend from the Invoker interface. OK, let's scratch Invoker. I'm OK with xyzAware instead of xyzInvoker. Just my 2c. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2049) wsdl/xml promotion of interface fails with NPE
[ https://issues.apache.org/jira/browse/TUSCANY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clemens utschig updated TUSCANY-2049: - Attachment: WSDLModelResolver.java fix is attached (search for // cutschig - nodeMap ) wsdl/xml promotion of interface fails with NPE -- Key: TUSCANY-2049 URL: https://issues.apache.org/jira/browse/TUSCANY-2049 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: clemens utschig Priority: Blocker Fix For: Java-SCA-1.2 Attachments: WSDLModelResolver.java reference name=empFlexFieldService promote=FlexEmployeeServiceComponent/empFlexFieldService !-- interface.java interface=model.common.serviceinterface.EmpFlexFieldService/ -- interface.wsdl interface=/model/common/#wsdl.interface(EmpFlexFieldService) / binding.ws uri=http://localhost:/Application4710-Model-context-root/EmpFlexFieldService/ /reference Having the above wsdl interface reference, a nullpointer occurs in org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver - line 338 (nodeMap.getLength()) because nodeMap is null for an element with name #document Null check fixes this -- 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: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
I got the dynamic wsdl import to work, thx guys - however, the wrong namespace is still sent out to the webservice and hence causes the error reported. /clemens -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 12:58 PM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace [EMAIL PROTECTED] wrote: Jean-sebastien, Qualified = target namespace?or wsdl name? Say my wsdl is named aaa.wsdl do I reference it by http://aaa ? Sorry for the slow response. I have been out sick for the last few days. The following definitely works. Other things might work as well, but I haven't tried them. The filename can be anything.wsdl as Sebastien says. (The anything part isn't used by Tuscany.) When you reference the WSDL in your .composite using interface.wsdl interface=mynamespace#wsdl.interface(myporttype) / you need to replace mynamespace and myporttype in the above line to correspond with the actual QName of the portType as defined in your .wsdl file. Simon Thx clemens -Original Message- From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: 2/11/08 6:33 PM Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. You don't even need an include, just place the WSDL file anywhere inside your SCA contribution (JAR or folder), reference its qualified name from your .composite and we should find it. - 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: Distribution zips and what they contain, was: SCA runtimes
Sorry for the delay in responding. I have been out sick for a few days and I am just getting back to my Tuscany mail. Comments inline. Simon Jean-Sebastien Delfino wrote: Comments inline. Simon Nash wrote: Well, I think the smart installer approach will be a nightmare. We had a similar approach in M2 and people didn't like it. The M2 approach was very different from what I was proposing. M2 downloaded everything on demand at runtime. A smart installer would set things up ahead of time with the necessary features for the desired runtime configuration. This is much more manageable if there are any problems with the downloads. OK, you scared me :) If you're talking about analyzing the features required by a composite at deployment time, calculating the set of JARs providing these features, and making them available for installation, then you get my +1. The work I've started with the Maven Ant generator plugin is a step in that direction. If you hook it with a composite model analyzer and remove the Ant specifics you get what I just described, allowing you to tailor a minimal runtime for a particular SCA application. Yes, the tailored runtime could be based on the needs of a single composite or on a predefined user-selected list of features. You're right that the Eclipse feature install approach is a little like that. IMHO it has been a nightmare and probably one of the reasons why their download page [1] now shows targeted distros :) - for Java developers - for Java EE developers - for Plugin developers - for C++ developers - for Web developers (on a separate page). - and the classic IDE mix Very similar to the approach I was proposing... I'm just seeing Spring and Eclipse, two extensible and successful projects adopt similar approaches, and thought they'd be good examples to follow :) I think these are good examples to follow. Tuscany is rather similar in that it contains a base framework and many optional extensions, and there is probably no user who wants to use all the optional features. +1 But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. I agree with you, but there is no consensus on this. I see several options: a) a vote to pick a common direction now b) have people develop their different visions to get user feedback c) continue with the current distro scheme Like I said I could live with (c). However, I would prefer (a) or (b). I could live with c) only if we start doing baby steps towards better modularity within a single distro as I proposed here. So I'd like to try to understand others' views on this baby step towards better modularity before I take a firm position on a), b) or c). I'd like to suggest a first baby step towards partitioning the contents of the distro. In this first step, there's still a single binary distro with all the dependencies. The difference is that the modules and lib directories are broken down into subdirectories along the lines that Sebastien and others have suggested. Based on earlier discussions, the subdirectories could be: core - The base that everybody needs core assembly model and runtime Java APIs, Java components, SCA binding, Web Service binding web - For Web developers Web 2.0 bindings, Scripting components, Widget components JEE - For JEE app integration EJB, RMI and JMS bindings, Spring components process - For process development BPEL and XQuery components Each of these could be built and tested separately. Dependencies between them would only use documented SPIs. There would no longer be a single catch-all tuscany-manifest jar or a single tuscany-all jar. If this first step is successful, we could think about what further steps we could take to improve modularity. I don't see what that baby step buys us. If we think that partitioning is the right approach, why not just simply do it cleanly and partition the distro? Please take a look at my other email on this thread responding to Ant. I think the main piece of work needed is to create a runtime that's truly modular, and this baby step is a first move towards that. Once we have that, almost any configuration or reconfiguration will be possible. Doing a zip repackaging without solving the modularity isssues might just move us from one inflexible packaging to a different packaging that's equally inflexible. For me, having the internal flexibility enabled is the first step that provides the key to many different scenarios under headings a) and b) above. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany with Weblogic
ant elder wrote: On Mon, Feb 11, 2008 at 5:10 PM, Dave Sowerby [EMAIL PROTECTED] wrote: All, I've spotted there's no FAQs for using Tuscany with Weblogic, so I thought I'd throw something together to help :) Over on my blog: http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html It covers the updates necessary to webapps and then an example of how to deploy. If you think it'll be useful, please feel free to link from the FAQs Cheers, Dave. Dave, It's very useful. Thanks! Would you be OK if we copied the steps you've given to our Wiki? I'm asking because I think that blogspot is not accessible from China for example, so a whole part of the world will not be able to get these instructions from your blog, but could get them from the Tuscany Wiki. Wouldn't it be good if the Tuscany samples just worked out-of-the-box on Weblogic and didn't need this manual moving of the .composite file? Yes, +1 I know this is going to be yet another facet of the ongoing runtime and contributions discussions but in the meantime if we move the webapp samples .composite files into the meta-inf folder then the samples would just work everywhere. That's not a good idea IMO as meta-inf is not where people expect to place their normal development artifacts. I'd prefer if we fixed the Tuscany contribution processing to correctly handle WARs and support JARs under the lib/ folder. ...ant -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resolving Component type files
Luciano Resende wrote: I guess we have couple scenarios here : - Considering contribution A importing a java package from Contribution B, we can have the componentType in either Contribution A(supported today) or contribution B (not working: TUSCANY-1873). - We can also consider Contribution A importing a java package from Contribution B, but sharing a componentType from a Contribution C. We can also abstract the componentType file to some type of resource, that needs to be imported from a different contribution, so I was thinking on creating a resource import/export, that would work for componentType and also for other types of resources that can be addressed by a given URI. Thoughts ? We need a new type of import for file resources like HTML files and property value value files, for example: import.file uri=my/pages/store.html/ import.file uri=my/properties/value.xml ComponentType files are a different subject. I think that the following should be sufficient to find my.sample.store.Store.componentType: import.java package=my.sample.store/ or to find my/processes/Store.componentType describing my/processes/Store.bpel: import namespace=http://my/sample/bpel// In other words, the application developer should not have to write another import.xyz to import the .componentType file separately, importing the implementation artifact should be sufficient. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
How about something like DataPassingStyle or DataPassingStrategy? Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, February 15, 2008 3:01 PM Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/ modules/binding-ejb/src/main/java/org/apache/tuscany/s Raymond Feng wrote: My preference is to keep PassByValue as the prefix for the following reasons. 1) The invokers implement this interface only for the cases to enforece pass-by-value for remotable interfaces. Invocations over local interfaces (pass-by-reference) don't even care about this flag. 2) The allowsPassByReference() method basically tells if it's safe to pass data as-is without violating the pass-by-value semantics. Having a SomethingPassByValue interface provide an allowsPassByReference method is really confusing IMHO. I think we should use a consistent terminology with either passByValue or passByReference but not a mix of both. Initially, I was thinking about PassByValueInvoker but I found it a bit misleading as it doesn't extend from the Invoker interface. OK, let's scratch Invoker. I'm OK with xyzAware instead of xyzInvoker. Just my 2c. -- 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: Injecting the SCADomain from the TuscanyServletFilter into itest cases
Raymond Feng wrote:
Hi,
In the WAR-based Tuscany deployment, the TuscanyServletFilter is
responsible to start/stop the SCADomain. At this moment, most of our
itest cases create the SCADomain using SCADomain.newInstance() during
the setup. If we run itests as a webapp, it ends up with two different
domain instances.
To really test the webapp scheme, the itests should use the SCADomain
created by the TuscanyServletFilter. I propose that we convert the
itests using the following pattern so that they can be run under both
J2SE and Webapp.
For the test case:
1) Declare a static field typed by SCADomain
2) Test if it is null before creating a new instance (it will be
injected under Webapp)
For the runtime:
1) WebAppServletHost will subclass SCADomain so that SCADomain.close()
will only happen during the TuscanyServletFilter.destroy() and the
SCADomain.close() statement in itest doesn't really shutdown the domain.
2) The JUnitServletFilter will get the SCADomain attribute from the
ServletContext and try to inject it into the test case class.
Here is an example of the itest.
public class XYZServiceTestCase extends TestCase {
private static SCADomain scaDomain; // A static field which can be
injected
private MyService service;
protected void setUp() throws Exception {
if (scaDomain == null) {
// J2SE case
scaDomain = SCADomain.newInstance(XYZ.composite);
}
service = scaDomain.getService(MyService.class, MyComponent);
}
protected void tearDown() throws Exception {
scaDomain.close();
}
}
What do you guys think?
Thanks,
Raymond
+1 to all that except for the WebAppServletHost will subclass SCADomain
so that SCADomain.close() will only happen during the
TuscanyServletFilter.destroy() and the SCADomain.close() statement in
itest doesn't really shutdown the domain. part.
A close that doesn't really close is a recipe for confusion and
trouble IMO and feels like a runtime that doesn't really run...
I'd prefer close to throw an exception like It is illegal for you to
close that domain as it was created by and owned by somebody else and
have the test case consciously catch that exception.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Raymond Feng wrote: How about something like DataPassingStyle or DataPassingStrategy? This is not a big issue and I would not seriously -1 any name even if you just called it the XyzStyle but I'd like to understand why we'd use a different term from the term used in the spec, and if we did, how we would explain to our users: (a) why we used a different term for the same concept or (b) if it's actually a different concept, how different it is from what's described in the spec, why we needed that new concept, and how it maps to the concept from the spec. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
It's not a big deal and I'm not good at naming :-). I agree with you that we should be able to explain it to extension developers for the name we pick (maybe a good javadoc will help:-). My understanding is that the SCA spec uses allowsPassByReference to customize the data exchange sementics for remotable interfaces which is the default to Pass-By-Value. Line 707, 725, 737 of the Assembly Spec consitently uses the term data exchange semantics. So we could use a name like DataExchangeSemantics. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, February 15, 2008 4:25 PM Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/ modules/binding-ejb/src/main/java/org/apache/tuscany/s Raymond Feng wrote: How about something like DataPassingStyle or DataPassingStrategy? This is not a big issue and I would not seriously -1 any name even if you just called it the XyzStyle but I'd like to understand why we'd use a different term from the term used in the spec, and if we did, how we would explain to our users: (a) why we used a different term for the same concept or (b) if it's actually a different concept, how different it is from what's described in the spec, why we needed that new concept, and how it maps to the concept from the spec. -- 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]
Classloading code in core contribution processing
The last 2 weeks I've been working with the contribution processing code and am bumping into the following issues: - ContributionImpl is tied to a ClassLoader - ModelResolver as well, and it seems to be used to resolve classes in some cases. - We're now using a special ContributionClassLoader implementation. - The ContributionService depends on it and assumes that it should be used on all contributions. - ContributionClassLoader contains code to navigate the imports/exports, assumes that all contributions are using such a ContributionClassLoader, calls implementation methods on it to match imports and exports and resolve classes, going around the regular model resolver based scheme used for everything else. - contribution-impl depends on contribution-java, this is going backwards IMO and breaks modularity and pluggability, as a core module should not have dependencies on extensions. - I don't fully understand what JavaImportExportListener does but it looks like an attempt to implement a fancy domain update scheme, bringing another way to match Java imports/exports. Unfortunately it's only half implemented. All this complexity related to classloading makes my head spin, prevents me from using the contribution service outside of a running runtime (where I don't have a classloader at all) and should not be in the core contribution code in the first place, as processing of Java classes should be handled in a Java specific extension and not in the core. For now I have to make a copy of the contribution code without this stuff to make progress. Could the people who worked on this classloading code please help clean it up and move it out of the core contribution modules? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Resolving implementations using componentType model resolvers mistakenly
We have multiple tuscany extensions (implementation types) that has it's Implementation implemented by extending componentType in order to re-use some common code. During resolve phase, we have code in ExtensibleModelResolver to find the proper resolver based on the interfaces of the implementation we find ComponentType as one of the interfaces and try to use the componentType model resolver, failing in some cases where information such as URI is not available. Should we refactor part of these common code to a base class, and have the extensions and componentTypeImpl extend from that ? This would properly map these extensions to use the default model resolver, as it would not find other unrelated interfaces anymore. Thoughts ? -- 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 with Weblogic
Hey, Absolutely, feel free to copy/translate/whatever you need to do with it, though it'd be nice if you could still link back/acknowledge me in some small way ;) Just for my 2p on the weblogic situation I agree that the META-INF directory is the wrong place for the composite files to live long-term, there's every chance that users of Tuscany may have several contributions within a webapp, which are all organised into suitable jars. Dave. On Feb 15, 2008 11:16 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Mon, Feb 11, 2008 at 5:10 PM, Dave Sowerby [EMAIL PROTECTED] wrote: All, I've spotted there's no FAQs for using Tuscany with Weblogic, so I thought I'd throw something together to help :) Over on my blog: http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html It covers the updates necessary to webapps and then an example of how to deploy. If you think it'll be useful, please feel free to link from the FAQs Cheers, Dave. Dave, It's very useful. Thanks! Would you be OK if we copied the steps you've given to our Wiki? I'm asking because I think that blogspot is not accessible from China for example, so a whole part of the world will not be able to get these instructions from your blog, but could get them from the Tuscany Wiki. Wouldn't it be good if the Tuscany samples just worked out-of-the-box on Weblogic and didn't need this manual moving of the .composite file? Yes, +1 I know this is going to be yet another facet of the ongoing runtime and contributions discussions but in the meantime if we move the webapp samples .composite files into the meta-inf folder then the samples would just work everywhere. That's not a good idea IMO as meta-inf is not where people expect to place their normal development artifacts. I'd prefer if we fixed the Tuscany contribution processing to correctly handle WARs and support JARs under the lib/ folder. ...ant -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dave Sowerby MEng MBCS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
