[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=50954&projectId=277 Build statistics: State: Error Previous State: Error Started at: Thu 14 Feb 2008 21:53:16 -0800 Finished at: Thu 14 Feb 2008 22:52:55 -0800 Total time: 59m 39s Build Trigger: Forced 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: No files changed 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: 1019 Failures: 0 Total time: 971893 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 org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59) at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:204) ... 11 more Caused by: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128) ... 15 more - 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=50954&projectId=277 Build statistics: State: Error Previous State: Error Started at: Thu 14 Feb 2008 21:53:16 -0800 Finished at: Thu 14 Feb 2008 22:52:55 -0800 Total time: 59m 39s Build Trigger: Forced 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: No files changed 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: 1019 Failures: 0 Total time: 971893 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 org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59) at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:204) ... 11 more Caused by: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128) ... 15 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processing multiple WSDLs in the same namespace
Please go ahead. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: Sent: Thursday, February 14, 2008 10:28 AM Subject: Re: Processing multiple WSDLs in the same namespace Raymond, A couple of comments below.. My preference would be to check in the changes I've made that make the itest (wsdl-multiple) that I've just checked in at least work. I can then close JIRA-2043 that relates to a very specific problem and raise a new one that discusses the general situation. We then have some extra testing in the build to keep us honest when it comes to fixing the more general case. Sound OK? Regards Simon On Thu, Feb 14, 2008 at 5:46 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: Maybe the best approach is keep the physical artifacts in the list as-is without aggregation. +1 And we change the artifact resolving so that it only happens at lower levels such as WSDL portType, binding, service or XSD element, type. This way we can find the accurate artifact. So you mean that the aggregation is no longer required. Sounds good to me. I.e. Currently we aggregate the WSDL/XSD at resolution time and then have extra logic at run time to unpick this aggregation It would seem better to Pick the precise artifact that is required at resolution time and do away with the runtime requirement to analyze aggregations The current Tuscany code tries to resolve WSDLDefinition/XSDefinition first. It seems to be causing ambiguity when there are multiple WSDLs/XSDs under the same namespace. Here are some examples of references to WSDL/XSD elements from SCA. [EMAIL PROTECTED] --> WSDL portType [EMAIL PROTECTED] --> WSDL portType, service, binding, etc. property --> XSD element or type In the above, we do have the information about what type of artifacts we're trying to resolve. Do any of you see a case that we can only resolve at WSDL Definition or XML Schema level? Thanks, Raymond - 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=50867&projectId=277 Build statistics: State: Error Previous State: Ok Started at: Thu 14 Feb 2008 16:02:47 -0800 Finished at: Thu 14 Feb 2008 17:02:21 -0800 Total time: 59m 34s 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: kwilliams @ Thu 14 Feb 2008 15:31:51 -0800 Comment: Adding HelloWorld test case Files changed: /incubator/tuscany/java/sca/itest/spring/pom.xml ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/META-INF ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/META-INF/sca ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/META-INF/sca/SpringHelloWorld-context.xml ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca/itest ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca/itest/spring ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca/itest/spring/SpringHelloWorld.composite ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/AbstractHelloWorldTestCase.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/AbstractSCATestCase.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/HelloWorld.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/HelloWorldProxy.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/SpringHelloWorldTestCase.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/TestHelloWorldBean.java ( 627910 ) 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: 1020 Failures: 0 Total time: 1057380 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.
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=50867&projectId=277 Build statistics: State: Error Previous State: Ok Started at: Thu 14 Feb 2008 16:02:47 -0800 Finished at: Thu 14 Feb 2008 17:02:21 -0800 Total time: 59m 34s 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: kwilliams @ Thu 14 Feb 2008 15:31:51 -0800 Comment: Adding HelloWorld test case Files changed: /incubator/tuscany/java/sca/itest/spring/pom.xml ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/META-INF ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/META-INF/sca ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/META-INF/sca/SpringHelloWorld-context.xml ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca/itest ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca/itest/spring ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/main/resources/org/apache/tuscany/sca/itest/spring/SpringHelloWorld.composite ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/AbstractHelloWorldTestCase.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/AbstractSCATestCase.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/HelloWorld.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/HelloWorldProxy.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/SpringHelloWorldTestCase.java ( 627910 ) /incubator/tuscany/java/sca/itest/spring/src/test/java/org/apache/tuscany/sca/itest/spring/TestHelloWorldBean.java ( 627910 ) 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: 1020 Failures: 0 Total time: 1057380 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.
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12569150#action_12569150
]
Lou Amodeo commented on TUSCANY-2043:
-
Thank You for the responses.
I upgraded from Axis 1.2 to Axis 1.3 and now I see additional issues. It
appears that Axis 1.3 cannot handle the wsd4l facade.
1) 2 wsdl with same target namspace as sent earlier.. The WSDL aggregation
process occurs creating a wsdl4j facade. Notice
the 2 imports 1st for callback wsdl and 2nd for service wsdl. They both
have same namespace.
Definition: name={http://helloworld}$aggregated$
targetNamespace=http://helloworld
[Import:
namespaceURI=http://helloworld
locationURI=file:/C:/WASV7Alpha/AppServer/profiles/SOAAppSrv01/installedAssets/helloworld-ws-asynchclient.jar/1.0/helloworld-ws-asynchclient.jar/WEB-INF/wsdl/helloworld.HelloWorldCallback.wsdl
definition=file:/C:/WASV7Alpha/AppServer/profiles/SOAAppSrv01/installedAssets/helloworld-ws-asynchclient.jar/1.0/helloworld-ws-asynchclient.jar/WEB-INF/wsdl/helloworld.HelloWorldCallback.wsdl
definition namespaceURI=http://helloworld, Import:
namespaceURI=http://helloworld
locationURI=file:/C:/WASV7Alpha/AppServer/profiles/SOAAppSrv01/installedAssets/helloworld-ws-asynchclient.jar/1.0/helloworld-ws-asynchclient.jar/WEB-INF/wsdl/helloworld.HelloWorldService.wsdl
definition=file:/C:/WASV7Alpha/AppServer/profiles/SOAAppSrv01/installedAssets/helloworld-ws-asynchclient.jar/1.0/helloworld-ws-asynchclient.jar/WEB-INF/wsdl/helloworld.HelloWorldService.wsdl
definition namespaceURI=http://helloworld]
2) Service definition is built from the wsdl
Axis2ServiceClient.java
AxisService axisService = serviceBuilder.populateService();
3) execption is thrown as Axis2 says it cant find the service in the wsdl.
org.apache.axis2.description.WSDL11ToAxisServiceBuilder populateService Service
{http://helloworld}HelloWorldService was not found in the WSDL
org.apache.axis2.AxisFault: Service {http://helloworld}HelloWorldService
was not found in the WSDL
4) Remove the callback wsdl entirely and populateService completes
successfully. This is because the aggregator proceess doesnt occcur and a full
wslddefinition is used for the service.
> 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 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]
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=50796&projectId=277 Build statistics: State: Error Previous State: Error Started at: Thu 14 Feb 2008 11:12:27 -0800 Finished at: Thu 14 Feb 2008 12:07:41 -0800 Total time: 55m 14s Build Trigger: Schedule Build Number: 44 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 @ Thu 14 Feb 2008 09:29:30 -0800 Comment: TUSCANY-2043 An itest related to this JIRA where two WSDL share the same namespace and subsequent WSDL and XSD processing doesn't work properly. This is not part of the build yet. More fixes to follow once ML discussion is completed Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/pom.xml ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldCallback.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldClientImpl.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldService.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldServiceImpl.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/auto-wsdl.composite ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/manual-wsdl.composite ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldCallback.wsdl ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldService.wsdl ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/AutoWSDLTestCase.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/ManualWSDLTestCase.java ( 627812 ) Changed: rfeng @ Thu 14 Feb 2008 11:09:39 -0800 Comment: Fix the problem that WebSCADomain is always not used for SCADomain injection Files changed: /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java ( 627842 ) /incubator/tuscany/java/sca/modules/host-webapp-junit/src/main/java/org/apache/tuscany/sca/host/webapp/junit/JUnitServletFilter.java ( 627842 ) 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: 1019 Failures: 0 Total time: 874696 Build Error: *
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=50796&projectId=277 Build statistics: State: Error Previous State: Error Started at: Thu 14 Feb 2008 11:12:27 -0800 Finished at: Thu 14 Feb 2008 12:07:41 -0800 Total time: 55m 14s Build Trigger: Schedule Build Number: 44 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 @ Thu 14 Feb 2008 09:29:30 -0800 Comment: TUSCANY-2043 An itest related to this JIRA where two WSDL share the same namespace and subsequent WSDL and XSD processing doesn't work properly. This is not part of the build yet. More fixes to follow once ML discussion is completed Files changed: /incubator/tuscany/java/sca/itest/wsdl-multiple ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/pom.xml ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldCallback.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldClientImpl.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldService.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/java/helloworld/HelloWorldServiceImpl.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/auto-wsdl.composite ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/manual-wsdl.composite ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldCallback.wsdl ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/main/resources/wsdl/helloworld.HelloWorldService.wsdl ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/AutoWSDLTestCase.java ( 627812 ) /incubator/tuscany/java/sca/itest/wsdl-multiple/src/test/java/org/apache/tuscany/sca/itest/ManualWSDLTestCase.java ( 627812 ) Changed: rfeng @ Thu 14 Feb 2008 11:09:39 -0800 Comment: Fix the problem that WebSCADomain is always not used for SCADomain injection Files changed: /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java ( 627842 ) /incubator/tuscany/java/sca/modules/host-webapp-junit/src/main/java/org/apache/tuscany/sca/host/webapp/junit/JUnitServletFilter.java ( 627842 ) 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: 1019 Failures: 0 Total time: 874696 Build Error: *
Re: Processing multiple WSDLs in the same namespace
Raymond, A couple of comments below.. My preference would be to check in the changes I've made that make the itest (wsdl-multiple) that I've just checked in at least work. I can then close JIRA-2043 that relates to a very specific problem and raise a new one that discusses the general situation. We then have some extra testing in the build to keep us honest when it comes to fixing the more general case. Sound OK? Regards Simon On Thu, Feb 14, 2008 at 5:46 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Maybe the best approach is keep the physical artifacts in the list as-is > without aggregation. +1 > And we change the artifact resolving so that it only > happens at lower levels such as WSDL portType, binding, service or XSD > element, type. This way we can find the accurate artifact. > So you mean that the aggregation is no longer required. Sounds good to me. I.e. Currently we aggregate the WSDL/XSD at resolution time and then have extra logic at run time to unpick this aggregation It would seem better to Pick the precise artifact that is required at resolution time and do away with the runtime requirement to analyze aggregations > > The current Tuscany code tries to resolve WSDLDefinition/XSDefinition > first. > It seems to be causing ambiguity when there are multiple WSDLs/XSDs under > the same namespace. > > Here are some examples of references to WSDL/XSD elements from SCA. > > [EMAIL PROTECTED] --> WSDL portType > [EMAIL PROTECTED] --> WSDL portType, service, binding, etc. > property --> XSD element or type > > In the above, we do have the information about what type of artifacts > we're > trying to resolve. Do any of you see a case that we can only resolve at > WSDL > Definition or XML Schema level? > > Thanks, > Raymond >
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12569031#action_12569031 ] Raymond Feng commented on TUSCANY-2044: --- I made some fixes under 627796 and 627650. Hopefully the problem will be gone in the next build. 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.j
Re: svn commit: r627631 - in /incubator/tuscany/java/sca: itest/jms/ itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/pr
I've been cleaning up the JMS code around here so it works better with either the embedded broker or the appserver message broker and was going to change the way Tuscany uses an embedded broker and to use the ActiveMQ VM transport. Is there a real need to support multiple embedded ActiveMQ brokers? O If so that may still be possible with the VM transport but its not the way i've coded it right now. ...ant On Thu, Feb 14, 2008 at 4:41 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to bring up the itest/jms with Tomcat and Geronimo. There are a > few things in this commit: > > 1) Add some logic to detect if the ActiveMQ broker is active, if not, then > start a new one. (Try to reuse the ActiveMQ broker from Geronimo) > 2) Move the startBroker() from JMSServiceBindingProvider's constructor to > the start() method. Add stopBroker() to JMSResourceFactory and call it > from > JMSServiceBindingProvider.stop() if the broker is created by this > provider. > 3) Use broker name and store directory for different instances of ActiveMQ > brokers to avoid conflicts. (This way, I can have different JMS bindings > use > different ActiveMQ brokers in the same VM). > > I'm done with the changes. Please let me know if I break something. > > Thanks, > Raymond > > - Original Message - > From: "ant elder" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, February 13, 2008 11:26 PM > Subject: Re: svn commit: r627631 - in /incubator/tuscany/java/sca: > itest/jms/ itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ > > modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/ > modules/binding-jms/src/test/java/org/apac > > > > Could you say some more about this change, I'm not sure I understand it > > and > > its conflicting with some local changes i have and i don't want to break > > what you're trying to do when i fix that. > > > > ...ant > > > > On Feb 14, 2008 1:32 AM, <[EMAIL PROTECTED]> wrote: > > > >> Author: rfeng > >> Date: Wed Feb 13 17:32:08 2008 > >> New Revision: 627631 > >> > >> URL: http://svn.apache.org/viewvc?rev=627631&view=rev > >> Log: > >> Add the on-demand ActiveMQ broker start/stop with detection/sharing of > >> running brokers (toward the geronimo deployment) > >> > >> Modified: > >>incubator/tuscany/java/sca/itest/jms/pom.xml > >> > >> > >> > incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java > >> > >> > >> > incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/JMSBindingServiceBindingProvider.java > >> > >> > >> > incubator/tuscany/java/sca/modules/binding-jms/src/test/java/org/apache/tuscany/sca/binding/jms/mock/MockJMSResourceFactoryQueueExist.java > >> > >> > >> > incubator/tuscany/java/sca/modules/binding-jms/src/test/java/org/apache/tuscany/sca/binding/jms/mock/MockJMSResourceFactoryQueueNotExist.java > >> > >> > >> > incubator/tuscany/java/sca/modules/host-jms-activemq/src/main/java/org/apache/tuscany/sca/host/jms/activemq/ActiveMQBroker.java > >> > >> > >> > incubator/tuscany/java/sca/modules/host-jms-activemq/src/main/java/org/apache/tuscany/sca/host/jms/activemq/ActiveMQModuleActivator.java > >> > >> > >> > incubator/tuscany/java/sca/modules/host-jms-activemq/src/main/java/org/apache/tuscany/sca/host/jms/activemq/JMSResourceFactoryImpl.java > >> > >> > >> > incubator/tuscany/java/sca/modules/host-jms/src/main/java/org/apache/tuscany/sca/host/jms/JMSResourceFactory.java > >> > >> > >> > incubator/tuscany/java/sca/samples/helloworld-reference-jms/src/test/java/helloworld/HelloWorldJmsClientTestCase.java > >> > >> > >> > incubator/tuscany/java/sca/samples/helloworld-service-jms/src/main/java/helloworld/HelloWorldServer.java > >> > >> > >> > incubator/tuscany/java/sca/samples/helloworld-service-jms/src/test/java/helloworld/HelloWorldJmsServerTestCaseOff.java > >> > >> Modified: incubator/tuscany/java/sca/itest/jms/pom.xml > >> URL: > >> > http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/jms/pom.xml?rev=627631&r1=627630&r2=627631&view=diff > >> > >> > == > >> --- incubator/tuscany/java/sca/itest/jms/pom.xml (original) > >> +++ incubator/tuscany/java/sca/itest/jms/pom.xml Wed Feb 13 17:32:08 > 2008 > >> @@ -47,7 +47,7 @@ > >> org.apache.tuscany.sca > >> tuscany-host-embedded > >> 1.2-incubating-SNAPSHOT > >> -test > >> +runtime > >> > >> > >> > >> > >> Modified: > >> > incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java > >> URL: > >> > http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java?rev=627631&r1=627630&r2=627631&view=diff > >> > >> > ===
[jira] Resolved: (TUSCANY-2041) Repeated nill elements of extended type cause "Parser found unknown element" exception
[ https://issues.apache.org/jira/browse/TUSCANY-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-2041. - Resolution: Fixed Thanks Pete. Change looks good to me. Checked out OK with the PHP tests I'm running. > Repeated nill elements of extended type cause "Parser found unknown element" > exception > -- > > Key: TUSCANY-2041 > URL: https://issues.apache.org/jira/browse/TUSCANY-2041 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-Next > Environment: XP SP2, VC7 >Reporter: Simon Laws >Assignee: Pete Robbins > Fix For: Cpp-Next > > > With the schema > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.org/AnnonTypes"; > xmlns:tns="http://www.example.org/AnnonTypes"; > elementFormDefault="qualified"> > > > > > maxOccurs="unbounded"> > > > > > > > > > > > > > And XML > http://www.example.org/AnnonTypes"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://www.example.org/AnnonTypes > AnnonTypes2.xsd "> > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> >
Re: Processing multiple WSDLs in the same namespace
Maybe the best approach is keep the physical artifacts in the list as-is without aggregation. And we change the artifact resolving so that it only happens at lower levels such as WSDL portType, binding, service or XSD element, type. This way we can find the accurate artifact. The current Tuscany code tries to resolve WSDLDefinition/XSDefinition first. It seems to be causing ambiguity when there are multiple WSDLs/XSDs under the same namespace. Here are some examples of references to WSDL/XSD elements from SCA. [EMAIL PROTECTED] --> WSDL portType [EMAIL PROTECTED] --> WSDL portType, service, binding, etc. property --> XSD element or type In the above, we do have the information about what type of artifacts we're trying to resolve. Do any of you see a case that we can only resolve at WSDL Definition or XML Schema level? Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: Sent: Thursday, February 14, 2008 9:25 AM Subject: Re: Processing multiple WSDLs in the same namespace hi Ramyond Comments in line... Simon On Thu, Feb 14, 2008 at 4:57 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Let me explain what I thought in this example: a contribution with two xsds under the same tns (http://ns1): a.xsd and b.xsd. When the XSDs are initially processed, we only create a XSDefinition object to hold the tns and URL of the xsd. The XSD is not fully loaded at this point. The XSDefinition object is added to the definitions list. So we end up with two XSDefinition objects in the list, one for a.xsd and one for b.xsd. When the first request comes to resolve the XSDefinition for "http"//ns1", we create an aggregated XSDefinition which use "xsd:include" to reference a.xsd and b.xsd. Both a.xsd and b.xsd are fully loaded. (I'm not sure if the XSD can include WSDLs for the inline schemas and we might have problems here) I observe that in the following case: WSDL-A - namespace X Inline XSD-A - namespace Y WSDL-B - namespace X Inline XSD-B - namespace Y That XSD-A and XSD-B are both registered with the XSDModelResolver in their unresolved state. When WSDL-A is resolved is causes a request for XSD-A to be resolved. This in turn causes the code to try and aggregate XSD-A and XSD-B together. However the resolution process for XSD-B has not started yet and hence it is ommitted from the aggregation and, with the code as it currently is, is lost when the definitions list is replaced with the aggregated XSD. The reason I replaced the list with the facade is to avoid reaggregation. This way, we'll return the aggregated XSDefinition next time directly from the list. Ah I see. Is there any function harm in re-doing the aggregation or if this a performance thing? I'm not sure why you see the hierarchy. Can you tell me what you found out? I'm not sure either looking back. I don't see it now. It's possible I was just confusing this with the effect of the disappearing XSD, i.e. I saw the result nest facade only having 1 object inside it and assumed, incorrectly, that is was another facade. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Thursday, February 14, 2008 6:15 AM Subject: Processing multiple WSDLs in the same namespace > re. https://issues.apache.org/jira/browse/TUSCANY-2043 > > Part of the the fix for this involves removing a FIXME in > org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver. > Specifically > at the bottom of the aggregate method I need to comment out two > lines... > > >// FIXME: [rfeng] This is hacky >//definitions.clear(); >//definitions.add(aggregated); >return aggregated; > > Raymond, do you recall why these were put in? > > Because the non-aggregated definition is replaces with the aggregated > definition the effect of including them is to build a hierarchy of XSD > that > could end up looking like: > > facade >facade > facade >xsd > > depending on how may WSDL/Schema there are in the same namespace. > > The other, possibly more dangerous, effect is that some schema are omitted > because the "aggregated" schema may not include all of the schema that are > in the original definitions list, for example, if many schema are in > the > same namespace then only the inline schema for WSDL that have been > resolved > so far will be present as opposed to all of the XSD that could be > available. > So the original list is cleared and replaced with a shortened list. The > XSD > that have now been remove will not be resolved. > > I get a clean build with these two lines removed, and with the other > required changes in place, so will check my fix in unless someone shouts. > > Simon > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processing multiple WSDLs in the same namespace
hi Ramyond Comments in line... Simon On Thu, Feb 14, 2008 at 4:57 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > Let me explain what I thought in this example: a contribution with two > xsds > under the same tns (http://ns1): a.xsd and b.xsd. > > When the XSDs are initially processed, we only create a XSDefinition > object > to hold the tns and URL of the xsd. The XSD is not fully loaded at this > point. The XSDefinition object is added to the definitions list. So we end > up with two XSDefinition objects in the list, one for a.xsd and one for > b.xsd. > > > When the first request comes to resolve the XSDefinition for "http"//ns1", > we create an aggregated XSDefinition which use "xsd:include" to reference > a.xsd and b.xsd. Both a.xsd and b.xsd are fully loaded. (I'm not sure if > the > XSD can include WSDLs for the inline schemas and we might have problems > here) I observe that in the following case: WSDL-A - namespace X Inline XSD-A - namespace Y WSDL-B - namespace X Inline XSD-B - namespace Y That XSD-A and XSD-B are both registered with the XSDModelResolver in their unresolved state. When WSDL-A is resolved is causes a request for XSD-A to be resolved. This in turn causes the code to try and aggregate XSD-A and XSD-B together. However the resolution process for XSD-B has not started yet and hence it is ommitted from the aggregation and, with the code as it currently is, is lost when the definitions list is replaced with the aggregated XSD. > > The reason I replaced the list with the facade is to avoid reaggregation. > This way, we'll return the aggregated XSDefinition next time directly from > the list. Ah I see. Is there any function harm in re-doing the aggregation or if this a performance thing? > > > I'm not sure why you see the hierarchy. Can you tell me what you found > out? I'm not sure either looking back. I don't see it now. It's possible I was just confusing this with the effect of the disappearing XSD, i.e. I saw the result nest facade only having 1 object inside it and assumed, incorrectly, that is was another facade. > > > Thanks, > Raymond > > - Original Message - > From: "Simon Laws" <[EMAIL PROTECTED]> > To: "tuscany-dev" > Sent: Thursday, February 14, 2008 6:15 AM > Subject: Processing multiple WSDLs in the same namespace > > > > re. https://issues.apache.org/jira/browse/TUSCANY-2043 > > > > Part of the the fix for this involves removing a FIXME in > > org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver. > > Specifically > > at the bottom of the aggregate method I need to comment out two lines... > > > > > >// FIXME: [rfeng] This is hacky > >//definitions.clear(); > >//definitions.add(aggregated); > >return aggregated; > > > > Raymond, do you recall why these were put in? > > > > Because the non-aggregated definition is replaces with the aggregated > > definition the effect of including them is to build a hierarchy of XSD > > that > > could end up looking like: > > > > facade > >facade > > facade > >xsd > > > > depending on how may WSDL/Schema there are in the same namespace. > > > > The other, possibly more dangerous, effect is that some schema are > omitted > > because the "aggregated" schema may not include all of the schema that > are > > in the original definitions list, for example, if many schema are in the > > same namespace then only the inline schema for WSDL that have been > > resolved > > so far will be present as opposed to all of the XSD that could be > > available. > > So the original list is cleared and replaced with a shortened list. The > > XSD > > that have now been remove will not be resolved. > > > > I get a clean build with these two lines removed, and with the other > > required changes in place, so will check my fix in unless someone > shouts. > > > > Simon > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12569001#action_12569001 ] Raymond Feng commented on TUSCANY-2043: --- In Tuscany, if there are multiple WSDLs under the same namespace, we return a facade WSDL4J Definition that use "wsdl:import" to import the physical WSDL definitions. 1) You can navigate the imports of the facade WSDL definition to get the document URI of the physical WSDLs. 2) Maybe there is a way to find the physical WSDL defintion that actually contains the WSDL artifact. The current code resolve WSDLDefinition at the Definition level. The unresolved object type is not helpful unless it goes down to Service/Port/PortType/Binding level. We need to change the code to resolve interface.wsdl and wsdlElement at finer level. Thanks, Raymond > 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 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]
Re: Processing multiple WSDLs in the same namespace
Hi, Let me explain what I thought in this example: a contribution with two xsds under the same tns (http://ns1): a.xsd and b.xsd. When the XSDs are initially processed, we only create a XSDefinition object to hold the tns and URL of the xsd. The XSD is not fully loaded at this point. The XSDefinition object is added to the definitions list. So we end up with two XSDefinition objects in the list, one for a.xsd and one for b.xsd. When the first request comes to resolve the XSDefinition for "http"//ns1", we create an aggregated XSDefinition which use "xsd:include" to reference a.xsd and b.xsd. Both a.xsd and b.xsd are fully loaded. (I'm not sure if the XSD can include WSDLs for the inline schemas and we might have problems here) The reason I replaced the list with the facade is to avoid reaggregation. This way, we'll return the aggregated XSDefinition next time directly from the list. I'm not sure why you see the hierarchy. Can you tell me what you found out? Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Thursday, February 14, 2008 6:15 AM Subject: Processing multiple WSDLs in the same namespace re. https://issues.apache.org/jira/browse/TUSCANY-2043 Part of the the fix for this involves removing a FIXME in org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver. Specifically at the bottom of the aggregate method I need to comment out two lines... // FIXME: [rfeng] This is hacky //definitions.clear(); //definitions.add(aggregated); return aggregated; Raymond, do you recall why these were put in? Because the non-aggregated definition is replaces with the aggregated definition the effect of including them is to build a hierarchy of XSD that could end up looking like: facade facade facade xsd depending on how may WSDL/Schema there are in the same namespace. The other, possibly more dangerous, effect is that some schema are omitted because the "aggregated" schema may not include all of the schema that are in the original definitions list, for example, if many schema are in the same namespace then only the inline schema for WSDL that have been resolved so far will be present as opposed to all of the XSD that could be available. So the original list is cleared and replaced with a shortened list. The XSD that have now been remove will not be resolved. I get a clean build with these two lines removed, and with the other required changes in place, so will check my fix in unless someone shouts. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What should be in Tuscany SCA Java release 1.2?
Hi It's probably about time we started talking about what's going to be in Tuscany SCA Java release 1.2. From the past timeline I would expect us to be trying for a release mid to late March which is not very far away. Some of the things I'd like to see are; More progress on our domain level composite and generally the processing that has to go there There have been a lot of policy changes going on and it would be good to get them in. Also linked to the item above we should look at how policy affects domain level processing. Don't know if it's achievable but some elements of the runtime story we have been talking about on the mail list for a while now Feel free to add topics on this thread. I've also opened up the Java-SCA-1.2category in JIRA so start associating JIRA with it, for example, if 1 - you've already marked a JIRA as fixed and its sitting at Java-SCA-Next 2 - you are working or are going to work on the JIRA for 1.2 3 - you would like to see the JIRA fixed for 1.2 Of course everyone is invited to contribute and submit patches for JIRA whether they be for bugs or new features. Inevitably not all "wish list" features will get done so you improve your chances of getting you favorite feature in by submitting a patch for it. Regards Simon
Re: svn commit: r627631 - in /incubator/tuscany/java/sca: itest/jms/ itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/pr
Hi,
I'm trying to bring up the itest/jms with Tomcat and Geronimo. There are a
few things in this commit:
1) Add some logic to detect if the ActiveMQ broker is active, if not, then
start a new one. (Try to reuse the ActiveMQ broker from Geronimo)
2) Move the startBroker() from JMSServiceBindingProvider's constructor to
the start() method. Add stopBroker() to JMSResourceFactory and call it from
JMSServiceBindingProvider.stop() if the broker is created by this provider.
3) Use broker name and store directory for different instances of ActiveMQ
brokers to avoid conflicts. (This way, I can have different JMS bindings use
different ActiveMQ brokers in the same VM).
I'm done with the changes. Please let me know if I break something.
Thanks,
Raymond
- Original Message -
From: "ant elder" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 13, 2008 11:26 PM
Subject: Re: svn commit: r627631 - in /incubator/tuscany/java/sca:
itest/jms/ itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/
modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/
modules/binding-jms/src/test/java/org/apac
Could you say some more about this change, I'm not sure I understand it
and
its conflicting with some local changes i have and i don't want to break
what you're trying to do when i fix that.
...ant
On Feb 14, 2008 1:32 AM, <[EMAIL PROTECTED]> wrote:
Author: rfeng
Date: Wed Feb 13 17:32:08 2008
New Revision: 627631
URL: http://svn.apache.org/viewvc?rev=627631&view=rev
Log:
Add the on-demand ActiveMQ broker start/stop with detection/sharing of
running brokers (toward the geronimo deployment)
Modified:
incubator/tuscany/java/sca/itest/jms/pom.xml
incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/JMSBindingServiceBindingProvider.java
incubator/tuscany/java/sca/modules/binding-jms/src/test/java/org/apache/tuscany/sca/binding/jms/mock/MockJMSResourceFactoryQueueExist.java
incubator/tuscany/java/sca/modules/binding-jms/src/test/java/org/apache/tuscany/sca/binding/jms/mock/MockJMSResourceFactoryQueueNotExist.java
incubator/tuscany/java/sca/modules/host-jms-activemq/src/main/java/org/apache/tuscany/sca/host/jms/activemq/ActiveMQBroker.java
incubator/tuscany/java/sca/modules/host-jms-activemq/src/main/java/org/apache/tuscany/sca/host/jms/activemq/ActiveMQModuleActivator.java
incubator/tuscany/java/sca/modules/host-jms-activemq/src/main/java/org/apache/tuscany/sca/host/jms/activemq/JMSResourceFactoryImpl.java
incubator/tuscany/java/sca/modules/host-jms/src/main/java/org/apache/tuscany/sca/host/jms/JMSResourceFactory.java
incubator/tuscany/java/sca/samples/helloworld-reference-jms/src/test/java/helloworld/HelloWorldJmsClientTestCase.java
incubator/tuscany/java/sca/samples/helloworld-service-jms/src/main/java/helloworld/HelloWorldServer.java
incubator/tuscany/java/sca/samples/helloworld-service-jms/src/test/java/helloworld/HelloWorldJmsServerTestCaseOff.java
Modified: incubator/tuscany/java/sca/itest/jms/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/jms/pom.xml?rev=627631&r1=627630&r2=627631&view=diff
==
--- incubator/tuscany/java/sca/itest/jms/pom.xml (original)
+++ incubator/tuscany/java/sca/itest/jms/pom.xml Wed Feb 13 17:32:08 2008
@@ -47,7 +47,7 @@
org.apache.tuscany.sca
tuscany-host-embedded
1.2-incubating-SNAPSHOT
-test
+runtime
Modified:
incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java?rev=627631&r1=627630&r2=627631&view=diff
==
---
incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java
(original)
+++
incubator/tuscany/java/sca/itest/jms/src/test/java/org/apache/tuscany/sca/binding/jms/ExternalBrokerTestCase.java
Wed Feb 13 17:32:08 2008
@@ -36,7 +36,7 @@
@Before
public void init() throws Exception {
-startBroker();
+// startBroker();
scaDomain = SCADomain.newInstance("http://localhost";, "/",
"external/client.composite", "external/service.composite");
}
Modified:
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/JMSBindingServiceBindingProvider.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/provider/JMSBindingServiceBindingProvider.java?rev=627631&r1=627630&r2=627631&view=diff
[jira] Updated: (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 updated TUSCANY-2043: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.2 > 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 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] Updated: (TUSCANY-1999) ConversationAttributes and expiry doesn't work with Stateless Conversational components
[
https://issues.apache.org/jira/browse/TUSCANY-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws updated TUSCANY-1999:
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.2
> ConversationAttributes and expiry doesn't work with Stateless Conversational
> components
> ---
>
> Key: TUSCANY-1999
> URL: https://issues.apache.org/jira/browse/TUSCANY-1999
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
>Reporter: Ben Smith
>Assignee: Simon Laws
> Fix For: Java-SCA-1.2
>
> Attachments: ConversationExpiry.patch
>
>
> In services that are marked as @Conversational yet have scope of STATELESS
> the following problems occur
> Caused by:
> org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidConversationalImplementation:
> Service is marked with @ConversationAttributes but the scope is not
> @Scope("CONVERSATION")
> at
> org.apache.tuscany.sca.implementation.java.introspect.impl.ConversationProcessor.visitClass(ConversationProcessor.java:57)
> Also looking at the code it looks as if that expiring of conversations only
> occurs with services that are of scope CONVERSATION. I believe that the above
> should work with all services marked as @Conversational.
> To fix this I'm thinking that the job of expiring conversations should be
> moved from the ConversationalScopeContainer into the ConversationManager and
> the check in the ConversationProcessor changed to check for the
> @Conversational tag not @Scope("CONVERSATION")
> Ben
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2044) BUILD FAILURE : Building Apache Tuscany SCA RMI Host Extension Point
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 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.invoke
[jira] Resolved: (TUSCANY-1063) Improve diagnostics running XSD2JavaGenerator against bad schema
[ https://issues.apache.org/jira/browse/TUSCANY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1063. - Resolution: Fixed Added print stack trace for any Exception (note one mod for this JIRA was inadvertently committed under TUSCANY-1293) Also added error report for case where input file results in no metadata (not easy to catch case where some metadata is in error). > Improve diagnostics running XSD2JavaGenerator against bad schema > > > Key: TUSCANY-1063 > URL: https://issues.apache.org/jira/browse/TUSCANY-1063 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SCA-M2 >Reporter: Scott Kurz >Priority: Minor > Fix For: Java-SDO-Next > > > I gave an invalid XSD file to the XSD2JavaGenerator and had to use the > debugger to figure out the problem. > It might be nice to do a printStackTrace() on any exception before throwing > out of main(). > Also it might be good to print out simple error messages in the cases that: > a) the usage was correct but the specified file can't be read > b) the file can be read but there is no valid schema found > As a sample of the latter here is my invalid schema > http://helloworld"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" > targetNamespace="http://helloworld";> > > > > > > > -- 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]
Processing multiple WSDLs in the same namespace
re. https://issues.apache.org/jira/browse/TUSCANY-2043 Part of the the fix for this involves removing a FIXME in org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver. Specifically at the bottom of the aggregate method I need to comment out two lines... // FIXME: [rfeng] This is hacky //definitions.clear(); //definitions.add(aggregated); return aggregated; Raymond, do you recall why these were put in? Because the non-aggregated definition is replaces with the aggregated definition the effect of including them is to build a hierarchy of XSD that could end up looking like: facade facade facade xsd depending on how may WSDL/Schema there are in the same namespace. The other, possibly more dangerous, effect is that some schema are omitted because the "aggregated" schema may not include all of the schema that are in the original definitions list, for example, if many schema are in the same namespace then only the inline schema for WSDL that have been resolved so far will be present as opposed to all of the XSD that could be available. So the original list is cleared and replaced with a shortened list. The XSD that have now been remove will not be resolved. I get a clean build with these two lines removed, and with the other required changes in place, so will check my fix in unless someone shouts. Simon
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
snip... > in definitions.xml(A). But, is this sort of re-processing / rebuild is a > requirment only in this context ? If there are other contexts as well, > such > as re-wiring and we there is going to be a separate phase for this, then > I'd > like to do this as well in that phase. > > Absolutely. There are a number of things that need to be calculated across the domain. We have started discussing [1] some phases of processing at a higher level than are currently contained in the depths of the ContributionService, assembly builders and composite activators. I've started a technical note [2] on this subject to net out the conversation from that thread (hasn't been much recently but it is on my mind and Sebastien has been doing things on the Contribution Worksapce judging by the SVN log). So from the point of view of this thread we should ensure that the blocks of processing you have extended the existing processing steps with, i.e. the bits you added to [3], are suitably accessible so that the can easily be called from higher level steps [2] I guess we need to get a bit more concrete on the higher level steps. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27609.html [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+Processing [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi, Yes, this is something that ran thro my mind. I guess A.composite might have to run thro both definitions.xmll(A) and definitions.xml(B) if definitions.xml(B) has brought in some re-definitions of policysets defined in definitions.xml(A). But, is this sort of re-processing / rebuild is a requirment only in this context ? If there are other contexts as well, such as re-wiring and we there is going to be a separate phase for this, then I'd like to do this as well in that phase. Thanks - Venkat On Thu, Feb 14, 2008 at 6:25 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > snip... > > against the aggregated union of all definitions. Do you see something > > missing ? > > > The point I'm interested in is what happens to the composites that belong > to contributions that have previously been added when you add a new > contribution, for example, > > ContributionA > definitions.xml(A) > A.composite > ContributionB > defnitions.xml(B) > B.composite > > When ContributionA is processed A.composite will be processed in the > context > of any "appliesTo" statements that appear in deinfitions.xml(A). When > ContributionB is added should B.composite be processed in the context of > "appliesTo" statements that appear in both deinfitions.xml(A) and > definitions.xml(B)? Should A.composite be re-processed in the context of > "appliesTo" statements that appear in both deinfitions.xml(A) and > definitions.xml(B)? > > Simon >
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
snip... against the aggregated union of all definitions. Do you see something > missing ? The point I'm interested in is what happens to the composites that belong to contributions that have previously been added when you add a new contribution, for example, ContributionA definitions.xml(A) A.composite ContributionB defnitions.xml(B) B.composite When ContributionA is processed A.composite will be processed in the context of any "appliesTo" statements that appear in deinfitions.xml(A). When ContributionB is added should B.composite be processed in the context of "appliesTo" statements that appear in both deinfitions.xml(A) and definitions.xml(B)? Should A.composite be re-processed in the context of "appliesTo" statements that appear in both deinfitions.xml(A) and definitions.xml(B)? Simon
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi, I reviewed these changes a bit in the context of multiple contributions. I guess things should work even then because these steps happen in the course of 'addContribution'. So if a new contribution comes in, the definitions in that would further get aggregated and then the composites coming in would be parsed and processed against the aggregated union of all definitions. Do you see something missing ? Thanks - Venkat On Wed, Feb 13, 2008 at 6:45 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > On Feb 12, 2008 5:18 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > No there isn't a separate phase. Just that in the current read phase I > > look > > for *.composite files and set those aside in a list without processing > > them > > further. After all artifacts in the contribution have been read I then > > read > > the list of composite URIs, read them and modify them with the > additional > > attribute 'applicablePolicySets' and then push it further for the usual > > processing. > > > > I see that this is what you have also summarized on the wiki. I have > > assumed that in the section titled "New Policy Processing Phase" should > go > > the description of what we do now with the composite reading and > > augmenting. I have added that information. Let me know if your > thoughts > > for it were otherwise. > > > > I think I might have to change this a bit in the context of multiple > > contributions. Isn't it ? > > > > - Venkat > > > > On Feb 12, 2008 2:41 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > snip.. > > > > > > On Feb 12, 2008 8:40 AM, Venkata Krishnan <[EMAIL PROTECTED]> > wrote: > > > > > > > Yes. Because we are now computing the 'applicablePolicySets' for > > > various > > > > SCA artifacts and that needs the list of 'all' PolicySets that might > > be > > > > applicable ever. > > > > > > > > > > > So, in the code today, how do you know you have reached the point that > > all > > > contributions have been added and you can start associating policy > sets > > > with > > > composites? Is the composite processing now in a separate phase > > > independent > > > of the the contribution processing. > > > > > > To try and get this clearer in my mind I've written out a part of the > > > various phases on the wiki [1]. Is there a new phase? Looking at the > > code > > > I > > > don't see it. > > > > > > Simon > > > > > > [1] > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases > > > > > > > Hi Venkat > > Thanks for the updates. The multiple contribution case was the case that I > was thinking about :-) So you have these new steps that have to sit > between > the point where all the definitions.xml files are read from ALL the > contributions and the point at which a composite is parsed and turned into > an assembly model. SO it sounds like the process would be something like > > 1. Add contribution > 2. Process contribution to extract definitions.xml > > repeat 1 & 2 until all contributions are added > > 3. Find composites in contributions > 4. Process "appliesTo" with reference to each of the composites > 5. process the the composites into an assembly model for further domain > processing (the domain composite) > > I'm not necessarily advocating enforcing the approach that all > contributions > must be added before any further processing commences. You could imagine > an > approach where the process is just repeated as new contributions are added > for example. But you get my point. > > Simon >
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568889#action_12568889
]
Amita Vadhavkar commented on TUSCANY-1293:
--
yes, it's fixed now.
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
> at commonj.sdo.impl.HelperPro
Re: NoSuchMethodError: javax/wsdl/Operation
just fyi i've got past this by reinstalling a new version of websphere. didn't get to the bottom of what was wrong but afaict doing exactly the same thing works now. ...ant On Mon, Feb 11, 2008 at 8:52 AM, ant elder <[EMAIL PROTECTED]> wrote: > Trying to run Tuscany WebApp samples in WebSphere i get a > NoSuchMethodError: > javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know > how to fix that? This is with the class loader set to "Classes loaded with > application class loader first". > >...ant >
Re: Tuscany with Weblogic
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. > 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? 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. ...ant
RE: Anyone seeing a test failure in itest/databindings/sdogen and how can I force the Continuum server to do a build of Tuscany?
Hi Jean-Sebastien, I've finally got around to creating an account on the continuum server. My account ID is mcombellack. Could I be added to the Tuscany group please. Thanks, Mark -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: 08 February 2008 05:43 To: tuscany-dev@ws.apache.org Subject: Re: Anyone seeing a test failure in itest/databindings/sdogen and how can I force the Continuum server to do a build of Tuscany? Mark Combellack wrote: [snip] > * Are other people seeing this problem with the > itest/databindings/sdogen iTest? SVN revision r619725 just built OK for me. > * How can I force the Continuum server to do a build? You need to create a continuum account [1]. Then once we add your account to the Tuscany group you'll be able to trigger builds. [1] http://vmbuild.apache.org/continuum/security/register.action -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12568837#action_12568837
]
Simon Laws commented on TUSCANY-2043:
-
Hi
I took your WSDL files and made a sample. I see an effect just by running it
that you don't mention
Caused by: org.apache.tuscany.sca.interfacedef.wsdl.impl.InvalidWSDLException:
Element cannot be resolved: {http://helloworld/xsd}getGreetings
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl$WSDLPart.(WSDLOperationIntrospectorImpl.java:272)
This is during the resolution of the WSDL. I'm curious that the affect for you
is just a null documentBaseURI rather than the error I see. It maybe that I set
the test up slightly differently (Can you post the java source files also for
comparison? I only see the class files in the attached jar)
Anyhow something is definitely going wrong with the way that the runtime tries
to aggregate types found in the same namespace. Am debugging now so I'll post
again when I know more.
Simon
> 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-Next
>
> 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 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] Assigned: (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 reassigned TUSCANY-2043: --- Assignee: Simon Laws > 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-Next > > 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 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]
