Re: R1.3 update and call for help
On Fri, Jul 25, 2008 at 1:22 AM, Simon Nash [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Thu, Jul 24, 2008 at 4:31 PM, Simon Nash [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Simon Laws wrote: On Tue, Jul 22, 2008 at 2:51 PM, Simon Laws [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 12:20 PM, ant elder [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I said I'd do an RC2 today but there are still some open JIRAs, the main ones being TUSCANY-2480, TUSCANY-2484, and TUSCANY-2486. Whats the status and ETA for fixes for these? Can i help with any of those, i've done work on the ?wsdl endpoints in the past so could help with TUSCANY-2480 if its needed? ...ant (cut) Hi Ant I have a fix for TUSCANY-2484 which I'm testing at the moment but it has implications for TUSCANY-2324 so we will have to revisit that before we respin. I've just moved TUSACANY-2324 into 1.3 as I note some changes for that were checked into the branch for this problem but that it wasn't associated with 1.3 in JIRA. I think we need to delay until tomorrow. Simon Hi ant I'm done with these fixes now. We need to get the go ahead from others who have been making fixes in 1.3, e.g. Simon Nash, but from my pov we can go ahead with the respin. Are you happy to press the buttons for the respin I still haven't caught up after being out and could do with some time to do that. Simon All the work I have been doing on the issues that are named in this thread is now completed in the 1.3 branch. I'm now working on getting the same code into trunk. So from my perspective it's fine to go ahead with another 1.3 RC respin. Simon Wonderful. I shall go make an RC2, probably wont get it done today now but should have it out for voting by tomorrow. ...ant I just committed a one-line change to a sample. See TUSCANY-2417 for details of the reason for this. If you have already picked up the code for RC2, it's not necessary to do a respin just for this. Simon I checked in fixes for TUSCANY-2479 and TUSCANY-2481 into both the 1.3 branch and trunk. It would be good if you could include these fixes in the next 1.3 RC if it's not too late. Thanks. Simon Ok i'll redo it now to pick these up. ...ant
Re: Continuum build notifications
On Thu, Jul 24, 2008 at 9:47 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: Big +1 from me, i'd probably prefer the messages go to the commit list but either would be an improvement. We have clear evidence from the last few weeks that without these timely public reminders of the status of the build, the trunk is in a broken state far more often than it can be built cleanly. Looking back at the continuum history, there have been no successful SCA Java builds since the start of recorded history on May 7, 2008. So +++1 for restoring these notifications to the ML. I think these notifications are useful to people other than the committers, so I would prefer to have them on the dev list. Simon ...ant On Thu, Jul 24, 2008 at 8:16 PM, Luciano Resende [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: I have recently changed the Tuscany continuum build schedules to once a day instead of multiple times as it was originally set, and there was also some changes on the build error notification e-mails, that now contains only a summary of the errors and a link to the full log as on the notification example below. I was wondering that if we should get the build notifications back to the dev-list, as this would help us to get and continue with a stable trunk/build. Thoughts ? -- Forwarded message -- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Thu, Jul 3, 2008 at 3:18 AM Subject: [continuum] BUILD FAILURE: Tuscany - Apache Tuscany SCA Implementation Project - Build Def: To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=99875projectId=277 http://vmbuild.apache.org/continuum/buildResult.action?buildId=99875projectId=277 Build statistics: State: Failed Previous State: Failed Started at: Thu 3 Jul 2008 03:15:26 -0700 Finished at: Thu 3 Jul 2008 03:17:35 -0700 Total time: 2m 9s Build Trigger: Schedule Build Number: 195 Exit code: 1 Building machine hostname: vmbuild.apache.org http://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.8 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 Family: unix 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: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 108 Failures: 1 Total time: 8.749001 Test Failures: DefaultCorbaHostTestCase test_registerServant : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.fail(Assert.java:53) at org.apache.tuscany.sca.host.corba.testing.DefaultCorbaHostTestCase.test_registerServant(DefaultCorbaHostTestCase.java:94) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at
Re: Problem with links to confluence Wiki and Website spaces
On Thu, Jul 24, 2008 at 10:46 AM, Simon Nash [EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, I just forced the TUSCANYWIKI autoexport to be rebuilt. The exported content should be consistent with the WIKI now. Please let me know if you still see issues. I am seeing major problems with this. A number of recent changes to cwiki.apache.org/confluence/display/TUSCANY have not made it to either cwiki.apache.org/TUSCANY or tuscany.apache.org. For examples, take a look at the Home and Getting Involved pages. Also, there are differences between cwiki.apache.org/TUSCANY and tuscany.apache.org. On the Getting Involved page, the link to the Tuscany Wiki (autoexported version) is correct on cwiki.apache.org/TUSCANY but is broken on tuscany.apache.org. Does anyone understand how the process for moving changes from cwiki.apache.org/confluence/display/TUSCANY - cwiki.apache.org/TUSCANY - tuscany.apache.org is supposed to work? Some specific questions: 1. When are changes supposed to be moved between these 3 versions? 2. How does one force a manual resync when changes don't move automatically? 3. Who is allowed to force a manual resync? (e.g., can I do it?) 4. Why do some links that are OK in cwiki.apache.org/TUSCANY get broken in tuscany.apache.org? Simon I've just had a forced website resync done and some changes i had missing are there now, can you check if the public website reflects all the updates you saw were missing? I think the problem is the auto resync plugin so it only works correctly for updates to existing pages, new pages don't get automatically added and pages which include nested other pages don't get updated when only the nested wiki page is updated - we use a lot of nested includes in the Tuscany front pages so i guess thats why its often out of date. To force a refresh you need to be a confluence admin and the how to force a refresh is described at http://www.mail-archive.com/[EMAIL PROTECTED]/msg18717.html. I'll add this info to our wiki page on updating the website so its easier to find. Maybe we also need to add some more confluence admins as well, we don't need every committer to be an admin but how about any PMC member who has the desire could be. I'm not an admin so i'm going to try to change that, anyone else what to be one? ...ant
Re: Problem using wsdl generated by ?wsdl with interface.wsdl as well as wsimport
Vamsavardhana Reddy wrote: On Fri, Jul 25, 2008 at 3:45 AM, Simon Nash [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: On Tue, Jul 22, 2008 at 4:49 PM, Simon Nash [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Scott Kurz wrote: The root cause here seems to be the same or similar to the one in: https://issues.apache.org/jira/browse/TUSCANY-2479 (not that pointing that out brings us closer to a solution). I did also discover that externalizing every schema the way wsgen's WSDL output does leads to another problem: https://issues.apache.org/jira/browse/TUSCANY-2481 though I'd guess the latter shouldn't be too hard to fix. Scott On Fri, Jul 18, 2008 at 5:01 PM, Raymond Feng [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, The bottom of the problem is as follows: 1) The WSDL has more than one inline schemas with different target namespaces. 2) An inline schema references the other inline schema for XSD types or elements. We are supposed to have xsd:import statements in the inline schemas. I don't think it's the lack of xsd:import that's causing this problem. The schema definition for http://jaxb.databindings.itest.sca.tuscany.apache.org/ is referencing types using an ns0: prefix, which resolves to http://util.java/. However, there is no schema definition with this targetNamespace. The first thing that needs fixing is to add targetNamespace=http://util.java/; to the first schema definition (the one that defines arrayList etc.) and see if that resolves the problem. Vamsi, could you try editing the generated WSDL to add this targetNamespace attribute and see if the modified WSDL can be loaded by the Tuscany runtime? Thanks Simon. The WSDL got loaded and the testcase ran fine after adding targetNamespace=http://util.java/; as you suggested. Is that all you had to do to get this through wsimport without errors? I had to make quite a few other changes, including adding an import for http://util.java/; and moving the http://util.java/; schema definition to a separate file. That change was enough to get it running in Tuscany. Using the new wsdl with wsimport (this I did only after seeing your post to the dev-list), I ended up getting one more warning than I originally got. Output from the command is given below. What do you mean by get it running in Tuscany? I wrote a small test for Tuscany that fired up a service and did a ?wsdl. This worked on the Tuscany runtime even without adding the missing targetNamespace attribute. I tried defining my service with either interface.java or interface.wsdl, and both of these worked. I presume this is because running ?wsdl does not attempt to resolve the cross-schema references, but just reproduces them. Have you been able to use this WSDL in Tuscany (with or without adding the missing targetNamespace) and run business methods that marshal and unmarshal these schema types and wrappers? Simon D:\T\databindingd:\JAXWS\jaxws-ri\bin\wsimport.bat hello-service.wsdl parsing WSDL... [WARNING] src-resolve.4.2: Error resolving component 'ns0:arrayList'. It was det ected that 'ns0:arrayList' is in namespace 'http://util.java/', but components f rom this namespace are not referenceable from schema document 'file:/D:/T/databi nding/hello-service.wsdl#types?schema3'. If this is the incorrect namespace, per haps the prefix of 'ns0:arrayList' needs to be changed. If this is the correct n amespace, then an appropriate 'import' tag should be added to 'file:/D:/T/databi nding/hello-service.wsdl#types?schema3'. line 127 of file:/D:/T/databinding/hello-service.wsdl#types?schema3 [WARNING] src-resolve.4.1: Error resolving component 'abstractList'. It was dete cted that 'abstractList' has no namespace, but components with no target namespa ce are not referenceable from schema document 'file:/D:/T/databinding/hello-serv ice.wsdl#types?schema1'. If 'abstractList' is intended to have a namespace, perh aps a prefix needs to be provided. If it is intended that 'abstractList' has no namespace, then an 'import' without a namespace attribute should be added to '
[jira] Commented: (TUSCANY-2437) samples/helloworld-referenceservice-jms READMEs incorrect
[ https://issues.apache.org/jira/browse/TUSCANY-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616804#action_12616804 ] Simon Laws commented on TUSCANY-2437: - Commited to trunk at 679706 samples/helloworld-referenceservice-jms READMEs incorrect -- Key: TUSCANY-2437 URL: https://issues.apache.org/jira/browse/TUSCANY-2437 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.3 Environment: WinXP SP2 IBM JDK5 Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-1.3 samples/helloworld-referenceservice-jms has the READMEs from the helloworld-ws-referenceservice-jms samples from which I suspect they were copied. The diagrams probably need updating also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2420) samples/helloworld-service-jms
[ https://issues.apache.org/jira/browse/TUSCANY-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616811#action_12616811 ] Simon Laws commented on TUSCANY-2420: - Committed to trunk at revision: 679715 samples/helloworld-service-jms -- Key: TUSCANY-2420 URL: https://issues.apache.org/jira/browse/TUSCANY-2420 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.3 Environment: Windows XP SP2 IBM JDK5 Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-1.3 Buildfile: build.xml run: [java] Exception in thread main org.osoa.sca.ServiceRuntimeException: org .osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.binding.jms.impl.JMSBi ndingException: Error starting JMSServiceBinding [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:276) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC ADomain.java:70) [java] at helloworld.HelloWorldServer.main(HelloWorldServer.java:34) [java] Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany. sca.binding.jms.impl.JMSBindingException: Error starting JMSServiceBinding [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.in it(DefaultSCADomain.java:261) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.i nit(DefaultSCADomain.java:120) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta nce(SCADomain.java:242) [java] ... 2 more [java] Caused by: org.apache.tuscany.sca.binding.jms.impl.JMSBindingExcepti on: Error starting JMSServiceBinding [java] at org.apache.tuscany.sca.binding.jms.provider.JMSBindingService BindingProvider.start(JMSBindingServiceBindingProvider.java:108) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl$3 .run(CompositeActivatorImpl.java:618) [java] at java.security.AccessController.doPrivileged(AccessController. java:193) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.s tart(CompositeActivatorImpl.java:616) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.in it(DefaultSCADomain.java:258) [java] ... 4 more [java] Caused by: javax.jms.JMSException: Could not connect to broker URL: tcp://localhost:61619. Reason: java.net.ConnectException: Connection refused: co nnect [java] at org.apache.activemq.util.JMSExceptionSupport.create(JMSExcept ionSupport.java:33) [java] at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQC onnection(ActiveMQConnectionFactory.java:280) [java] at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQC onnection(ActiveMQConnectionFactory.java:214) [java] at org.apache.activemq.ActiveMQConnectionFactory.createConnectio n(ActiveMQConnectionFactory.java:161) [java] at org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactor y.createConnection(JMSResourceFactory.java:112) [java] at org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactor y.getConnection(JMSResourceFactory.java:70) [java] at org.apache.tuscany.sca.binding.jms.provider.JMSResourceFactor y.createSession(JMSResourceFactory.java:81) [java] at org.apache.tuscany.sca.binding.jms.provider.JMSBindingService BindingProvider.registerListerner(JMSBindingServiceBindingProvider.java:124) [java] at org.apache.tuscany.sca.binding.jms.provider.JMSBindingService BindingProvider.start(JMSBindingServiceBindingProvider.java:106) [java] ... 8 more [java] Caused by: java.net.ConnectException: Connection refused: connect [java] at java.net.PlainSocketImpl.socketConnect(Native Method) [java] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) [java] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.jav a:233) [java] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) [java] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) [java] at java.net.Socket.connect(Socket.java:541) [java] at org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTra nsport.java:335) [java] at org.apache.activemq.transport.tcp.TcpTransport.doStart(TcpTra nsport.java:303) [java] at org.apache.activemq.util.ServiceSupport.start(ServiceSupport. java:49) [java] at org.apache.activemq.transport.TransportFilter.start(Transport Filter.java:54) [java] at org.apache.activemq.transport.TransportFilter.start(Transport
[jira] Commented: (TUSCANY-2450) Fix RAT issues reported against release 1.3
[ https://issues.apache.org/jira/browse/TUSCANY-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616831#action_12616831 ] Simon Laws commented on TUSCANY-2450: - Committed to trunk at revision: 679740 Fix RAT issues reported against release 1.3 --- Key: TUSCANY-2450 URL: https://issues.apache.org/jira/browse/TUSCANY-2450 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.3 Environment: WinXP SP2 IBM JDK5 Reporter: Simon Laws Assignee: Simon Laws Priority: Blocker Fix For: Java-SCA-1.3 Fix any issues found in the RAT report for release 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2497) sample-feed-aggregator updates/issues
[ https://issues.apache.org/jira/browse/TUSCANY-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-2497. - Resolution: Fixed Fix Version/s: Java-SCA-Next Completed: At revision: 679747 Thanks for the patch Dhaval sample-feed-aggregator updates/issues - Key: TUSCANY-2497 URL: https://issues.apache.org/jira/browse/TUSCANY-2497 Project: Tuscany Issue Type: Improvement Components: Java SCA Samples Reporter: Dhaval Chauhan Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-Next Attachments: tuscany-TUSCANY-2497.Dhaval.diff This JIRA is created to post issues/updates related with the feed-aggregator sample -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem with links to confluence Wiki and Website spaces
ant elder wrote: On Thu, Jul 24, 2008 at 10:46 AM, Simon Nash [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, I just forced the TUSCANYWIKI autoexport to be rebuilt. The exported content should be consistent with the WIKI now. Please let me know if you still see issues. I am seeing major problems with this. A number of recent changes to cwiki.apache.org/confluence/display/TUSCANY http://cwiki.apache.org/confluence/display/TUSCANY have not made it to either cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY or tuscany.apache.org http://tuscany.apache.org. For examples, take a look at the Home and Getting Involved pages. Also, there are differences between cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY and tuscany.apache.org http://tuscany.apache.org. On the Getting Involved page, the link to the Tuscany Wiki (autoexported version) is correct on cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY but is broken on tuscany.apache.org http://tuscany.apache.org. Does anyone understand how the process for moving changes from cwiki.apache.org/confluence/display/TUSCANY http://cwiki.apache.org/confluence/display/TUSCANY - cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY - tuscany.apache.org http://tuscany.apache.org is supposed to work? Some specific questions: 1. When are changes supposed to be moved between these 3 versions? 2. How does one force a manual resync when changes don't move automatically? 3. Who is allowed to force a manual resync? (e.g., can I do it?) 4. Why do some links that are OK in cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY get broken in tuscany.apache.org http://tuscany.apache.org? Simon I've just had a forced website resync done and some changes i had missing are there now, can you check if the public website reflects all the updates you saw were missing? I think the problem is the auto resync plugin so it only works correctly for updates to existing pages, new pages don't get automatically added and pages which include nested other pages don't get updated when only the nested wiki page is updated - we use a lot of nested includes in the Tuscany front pages so i guess thats why its often out of date. To force a refresh you need to be a confluence admin and the how to force a refresh is described at http://www.mail-archive.com/[EMAIL PROTECTED]/msg18717.html. I'll add this info to our wiki page on updating the website so its easier to find. Maybe we also need to add some more confluence admins as well, we don't need every committer to be an admin but how about any PMC member who has the desire could be. I'm not an admin so i'm going to try to change that, anyone else what to be one? ...ant Thanks for getting this fixed. I would like to be an admin. Simon
[jira] Updated: (TUSCANY-2442) Remove any remaining references to incubator
[ https://issues.apache.org/jira/browse/TUSCANY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-2442: --- Fix Version/s: (was: Java-SCA-1.3) Java-SCA-Next Moving to next release, the remaining references in the pom.xml's shouldn't hurt anything and i dont want to be changing the pom.xml's at this stage in the 1.3 RC process so we can fix this in trunk for the next release. Remove any remaining references to incubator Key: TUSCANY-2442 URL: https://issues.apache.org/jira/browse/TUSCANY-2442 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.3 Environment: WinXP SP2 IBM JDK5 Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-Next See Raymond's thread - http://mail-archives.apache.org/mod_mbox/tuscany-dev/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2462) helloworld-ws-sdo-webapp cannot be built using ant
[ https://issues.apache.org/jira/browse/TUSCANY-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-2462. -- Resolution: Fixed This is working ok in the 1.3 RC2 for me both building and running the sample helloworld-ws-sdo-webapp cannot be built using ant -- Key: TUSCANY-2462 URL: https://issues.apache.org/jira/browse/TUSCANY-2462 Project: Tuscany Issue Type: Test Components: Java SCA Samples Affects Versions: Java-SCA-1.3 Reporter: Yang Sun Priority: Minor Fix For: Java-SCA-1.3 Attachments: build.xml Some classpath is missing in the script. The log is as below. (Sorry for the Chinese character. I don't know a easy way to set the locale on Windows platform). The error complains it cannot find some annotations. /--- Buildfile: build.xml init: generate-sdo: [java] Generating code [java] Generating packages [java] Generating package TypePackageImpl [java] Generating Java interface helloworld.type.TypeFactory [java] Generating /TargetProject/helloworld/type/TypeFactory.java [java] Examining old /TargetProject/helloworld/type/TypeFactory.java [java] Generating Java class helloworld.type.impl.TypeFactoryImpl [java] Generating /TargetProject/helloworld/type/impl/TypeFactoryImpl.java [java] Examining old /TargetProject/helloworld/type/impl/TypeFactoryImpl.java [java] Generating Person Base [java] Generating Java interface helloworld.type.Person_Base [java] Generating /TargetProject/helloworld/type/Person_Base.java [java] Examining old /TargetProject/helloworld/type/Person_Base.java [java] Generating Java class helloworld.type.impl.Person_BaseImpl [java] Generating /TargetProject/helloworld/type/impl/Person_BaseImpl.java [java] Examining old /TargetProject/helloworld/type/impl/Person_BaseImpl.java [java] Generating code [java] Generating packages [java] Generating package HelloworldPackageImpl [java] Generating Java interface helloworld.HelloworldFactory [java] Generating /TargetProject/helloworld/HelloworldFactory.java [java] Examining old /TargetProject/helloworld/HelloworldFactory.java [java] Generating Java class helloworld.impl.HelloworldFactoryImpl [java] Generating /TargetProject/helloworld/impl/HelloworldFactoryImpl.java [java] Examining old /TargetProject/helloworld/impl/HelloworldFactoryImpl.java [java] Generating get Greetings [java] Generating Java interface helloworld.getGreetings [java] Generating /TargetProject/helloworld/getGreetings.java [java] Examining old /TargetProject/helloworld/getGreetings.java [java] Generating Java class helloworld.impl.getGreetingsImpl [java] Generating /TargetProject/helloworld/impl/getGreetingsImpl.java [java] Examining old /TargetProject/helloworld/impl/getGreetingsImpl.java [java] Generating get Greetings Response [java] Generating Java interface helloworld.getGreetingsResponse [java] Generating /TargetProject/helloworld/getGreetingsResponse.java [java] Examining old /TargetProject/helloworld/getGreetingsResponse.java [java] Generating Java class helloworld.impl.getGreetingsResponseImpl [java] Generating /TargetProject/helloworld/impl/getGreetingsResponseImpl.java [java] Examining old /TargetProject/helloworld/impl/getGreetingsResponseImpl.java [java] Generating Party [java] Generating Java interface helloworld.Party [java] Generating /TargetProject/helloworld/Party.java [java] Examining old /TargetProject/helloworld/Party.java [java] Generating Java class helloworld.impl.PartyImpl [java] Generating /TargetProject/helloworld/impl/PartyImpl.java [java] Examining old /TargetProject/helloworld/impl/PartyImpl.java [java] Generating Person [java] Generating Java interface helloworld.Person [java] Generating /TargetProject/helloworld/Person.java [java] Examining old /TargetProject/helloworld/Person.java [java] Generating Java class helloworld.impl.PersonImpl [java] Generating /TargetProject/helloworld/impl/PersonImpl.java [java] Examining old /TargetProject/helloworld/impl/PersonImpl.java compile: [javac] Compiling 17 source files to D:\apache-tuscany-sca-1.3\tuscany-sca-1.3\samples\helloworld-ws-sdo-webapp\target\classes [javac] D:\apache-tuscany-sca-1.3\tuscany-sca-1.3\samples\helloworld-ws-sdo-webapp\src\main\java\helloworld\HelloWorld.java:28: 软件包 org.osoa.sca.annotations 不存在 [javac] import
[jira] Resolved: (TUSCANY-2479) Problems with bottom-up J2W code when cross-NS class-to-class reference exists; issue with systemID used by XMLSchema code for corresponding xsd import
[
https://issues.apache.org/jira/browse/TUSCANY-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz resolved TUSCANY-2479.
-
Resolution: Fixed
Thanks Simon, my original test is working now as well.
Problems with bottom-up J2W code when cross-NS class-to-class reference
exists; issue with systemID used by XMLSchema code for corresponding xsd
import
Key: TUSCANY-2479
URL: https://issues.apache.org/jira/browse/TUSCANY-2479
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Reporter: Scott Kurz
Assignee: Simon Nash
Attachments: 2479.test.diff
If I go bottom-up from Java, with class my.pkg1.MyClass dependent on
my.pkg2.OtherClass, the Interface2WSDLGenerator will produce XMLSchema
objects in such a way that the schemaLocation on the import doesn't work.
As an immediate cause, I can see the code in JAXBTypeHelper.DOMResolverImpl
doing:
public Result createOutput(String ns, String file) throws IOException
{
DOMResult result = new DOMResult();
result.setSystemId(ns + file);
This is what produces the XmlSchemaException with message The system cannot
find the file specified.
I'll attach a patch to allow for recreate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2481) NPE when WSDL types has schema minus @targetNamespace with an xsd:import
[ https://issues.apache.org/jira/browse/TUSCANY-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz resolved TUSCANY-2481. - Resolution: Fixed Thanks Simon, my original test is working now as well. NPE when WSDL types has schema minus @targetNamespace with an xsd:import -- Key: TUSCANY-2481 URL: https://issues.apache.org/jira/browse/TUSCANY-2481 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Environment: r673392 Reporter: Scott Kurz Assignee: Simon Nash Attachments: 2481.recreate.diff WIth a WSDL types with no @targetNamespace, like the following: schema xmlns=http://www.w3.org/2001/XMLSchema; import namespace=http://helloworld; schemaLocation=Hello.xsd/ /schema we get: java.lang.NullPointerException at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.updateSchemaRefs(Axis2ServiceProvider.java:519) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.addSchemas(Axis2ServiceProvider.java:511) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.createWSDLAxisService(Axis2ServiceProvider.java:478) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.createAxisService(Axis2ServiceProvider.java:369) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(Axis2ServiceProvider.java:256) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start(Axis2ServiceBindingProvider.java:65) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl$3.run(CompositeActivatorImpl.java:618) at java.security.AccessController.doPrivileged(AccessController.java:193) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:616) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:258) The problem seems to be the fact that our wsdlDefinition ends up with an XSDefinition corresponding to the null NS. This XSDefinition, then, has no XMLSchema object associated with it, producing the NPE above.I can see in the debugger that we have an XSDefinition with empty () NS, which has no problem; we have an XMLSchema for empty NS. But apparently this style of authoring types presents a problem. Note that BP1.1 R2105 says this is valid, and also that wsgen produces WSDL in this style. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2479) Problems with bottom-up J2W code when cross-NS class-to-class reference exists; issue with systemID used by XMLSchema code for corresponding xsd import
[
https://issues.apache.org/jira/browse/TUSCANY-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Nash updated TUSCANY-2479:
Affects Version/s: Java-SCA-1.3
Fix Version/s: Java-SCA-1.3
Problems with bottom-up J2W code when cross-NS class-to-class reference
exists; issue with systemID used by XMLSchema code for corresponding xsd
import
Key: TUSCANY-2479
URL: https://issues.apache.org/jira/browse/TUSCANY-2479
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.3
Reporter: Scott Kurz
Assignee: Simon Nash
Fix For: Java-SCA-1.3
Attachments: 2479.test.diff
If I go bottom-up from Java, with class my.pkg1.MyClass dependent on
my.pkg2.OtherClass, the Interface2WSDLGenerator will produce XMLSchema
objects in such a way that the schemaLocation on the import doesn't work.
As an immediate cause, I can see the code in JAXBTypeHelper.DOMResolverImpl
doing:
public Result createOutput(String ns, String file) throws IOException
{
DOMResult result = new DOMResult();
result.setSystemId(ns + file);
This is what produces the XmlSchemaException with message The system cannot
find the file specified.
I'll attach a patch to allow for recreate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2480) Generated wsdl has incorrect endpoint
[ https://issues.apache.org/jira/browse/TUSCANY-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2480. - Resolution: Fixed Fixed in trunk under r679776. Generated wsdl has incorrect endpoint - Key: TUSCANY-2480 URL: https://issues.apache.org/jira/browse/TUSCANY-2480 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.3 Reporter: ant elder Assignee: Simon Nash Priority: Minor Fix For: Java-SCA-1.3 In the 1.3 release the generated wsdl has an incorrect endpoint when the app is running on a port other than 8080. To recreate deploy the caclulator-ws-sample to Tomcat using a port other than 8080 and look at the generated wsdl - it still uses port 8080. See ML post: http://apache.markmail.org/message/fryloi6byuyjqvrl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How do I get my Continuum build server account unlocked?
As we're sorting out the cwiki admins its reminded me of this, what is the status of this and do we have any continuum admins in Tuscany able to add committers to the Tuscany group? As the notifications are going to start being sent to the mailing list again i think we should have all committers able to kick off new continuum builds so they're able to verify if the build is fixed. If not I'll try i'll raise a JIRA to get my id going again but might as well include anyone else on that one JIRA as well, I'll also try to get some Tuscany admin's so we can do this ourselves in future without JIRAs. ...ant On Fri, May 23, 2008 at 3:58 PM, Luciano Resende [EMAIL PROTECTED] wrote: Looks like the Continuum was upgraded and the security level too so we are going to see only the Tuscany project if you are loged in. 1.To unlock account : Create a Infra JIRA like this one https://issues.apache.org/jira/browse/INFRA-1616 2.To create account : on the upper left corner there is a register link, after you are registered, please let me know and I can try adding you to the group (I couldn't before)... otherwise you would have to create another JIRA for infra. Please let me know if you have more questions... On Fri, May 23, 2008 at 3:23 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 11:05 AM, Mark Combellack [EMAIL PROTECTED] wrote: -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 23 May 2008 11:01 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How do I get my Continuum build server account unlocked? On Fri, May 23, 2008 at 10:55 AM, Mark Combellack [EMAIL PROTECTED] wrote: Hi, I've just tried accessing the Continuum build server [1] and have discovered that my account is locked. How do I go about getting my account unlocked? Can anyone do this for me? My account id is mcombellack. Thanks, Mark [1] http://vmbuild.apache.org/continuum/ And an additional question. How did you get the account in the first place. I'd like to be able to kick off builds etc and I'm assuming I need an account to be able to do that. How does one go about getting one? Simon I did this many months ago so I am a bit vague on the exact detail. To get my account, I clicked the register link on the page and created an account. I then posted a request to the Tuscany dev list to be added to the Tuscany build group. Someone then did something and some time later I could then see and start Tuscany builds. Mark OK, thanks for that Mark. When I go to http://vmbuild.apache.org:8080/continuum I don't see any projects at all. Either that's now the wrong link or something more serious is up. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
[jira] Updated: (TUSCANY-2481) NPE when WSDL types has schema minus @targetNamespace with an xsd:import
[ https://issues.apache.org/jira/browse/TUSCANY-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-2481: Affects Version/s: Java-SCA-1.3 Fix Version/s: Java-SCA-1.3 NPE when WSDL types has schema minus @targetNamespace with an xsd:import -- Key: TUSCANY-2481 URL: https://issues.apache.org/jira/browse/TUSCANY-2481 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.3 Environment: r673392 Reporter: Scott Kurz Assignee: Simon Nash Fix For: Java-SCA-1.3 Attachments: 2481.recreate.diff WIth a WSDL types with no @targetNamespace, like the following: schema xmlns=http://www.w3.org/2001/XMLSchema; import namespace=http://helloworld; schemaLocation=Hello.xsd/ /schema we get: java.lang.NullPointerException at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.updateSchemaRefs(Axis2ServiceProvider.java:519) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.addSchemas(Axis2ServiceProvider.java:511) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.createWSDLAxisService(Axis2ServiceProvider.java:478) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.createAxisService(Axis2ServiceProvider.java:369) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(Axis2ServiceProvider.java:256) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start(Axis2ServiceBindingProvider.java:65) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl$3.run(CompositeActivatorImpl.java:618) at java.security.AccessController.doPrivileged(AccessController.java:193) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:616) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:258) The problem seems to be the fact that our wsdlDefinition ends up with an XSDefinition corresponding to the null NS. This XSDefinition, then, has no XMLSchema object associated with it, producing the NPE above.I can see in the debugger that we have an XSDefinition with empty () NS, which has no problem; we have an XMLSchema for empty NS. But apparently this style of authoring types presents a problem. Note that BP1.1 R2105 says this is valid, and also that wsgen produces WSDL in this style. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem with links to confluence Wiki and Website spaces
On Fri, Jul 25, 2008 at 11:26 AM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Thu, Jul 24, 2008 at 10:46 AM, Simon Nash [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, I just forced the TUSCANYWIKI autoexport to be rebuilt. The exported content should be consistent with the WIKI now. Please let me know if you still see issues. I am seeing major problems with this. A number of recent changes to cwiki.apache.org/confluence/display/TUSCANY http://cwiki.apache.org/confluence/display/TUSCANY have not made it to either cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY or tuscany.apache.org http://tuscany.apache.org. For examples, take a look at the Home and Getting Involved pages. Also, there are differences between cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY and tuscany.apache.org http://tuscany.apache.org. On the Getting Involved page, the link to the Tuscany Wiki (autoexported version) is correct on cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY but is broken on tuscany.apache.org http://tuscany.apache.org. Does anyone understand how the process for moving changes from cwiki.apache.org/confluence/display/TUSCANY http://cwiki.apache.org/confluence/display/TUSCANY - cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY - tuscany.apache.org http://tuscany.apache.org is supposed to work? Some specific questions: 1. When are changes supposed to be moved between these 3 versions? 2. How does one force a manual resync when changes don't move automatically? 3. Who is allowed to force a manual resync? (e.g., can I do it?) 4. Why do some links that are OK in cwiki.apache.org/TUSCANY http://cwiki.apache.org/TUSCANY get broken in tuscany.apache.org http://tuscany.apache.org? Simon I've just had a forced website resync done and some changes i had missing are there now, can you check if the public website reflects all the updates you saw were missing? I think the problem is the auto resync plugin so it only works correctly for updates to existing pages, new pages don't get automatically added and pages which include nested other pages don't get updated when only the nested wiki page is updated - we use a lot of nested includes in the Tuscany front pages so i guess thats why its often out of date. To force a refresh you need to be a confluence admin and the how to force a refresh is described at http://www.mail-archive.com/[EMAIL PROTECTED]/msg18717.html. I'll add this info to our wiki page on updating the website so its easier to find. Maybe we also need to add some more confluence admins as well, we don't need every committer to be an admin but how about any PMC member who has the desire could be. I'm not an admin so i'm going to try to change that, anyone else what to be one? ...ant Thanks for getting this fixed. I would like to be an admin. Simon Done. And i've now added this info to the doc about the Tuscany website. ...ant
[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616872#action_12616872 ] Simon Nash commented on TUSCANY-2324: - This change is now in trunk as part of r679774. InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding --- Key: TUSCANY-2324 URL: https://issues.apache.org/jira/browse/TUSCANY-2324 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Scott Kurz Assignee: Simon Laws Fix For: Java-SCA-1.3 If we take the following example where an inner component reference is overridden in two ways by the outer component using the inner Composite as impl: 1) a binding.ws is added 2) a WSDL intf (compatible with the inner Java intf) is declared composite ... name=OuterComposite component name=OuterComponent implementation.composite name=blah:InnerComposite/ reference name=outerRef target=MyTarget interface.wsdl interface=http://blah#wsdl.interface(HelloWorld) / binding.ws/ /reference /component /composite composite name=InnerComposite component name=InnerComponent implementation.java .../ reference name=helloWorldService interface.java interface=test.sca.w2j.ws.statc.exc.helloworld.HelloWorld/ /reference /component reference name=outerRef promote=InnerComponent/helloWorldService/ /composite we have a problem. The CompositeActivatorImpl is going to start an Axis2ReferenceBindingProvider for the inner Composite ref. The WS binding is propagated down or inwards, you could say.But this WS binding has a null IC, so we're going to look at the component ref IC, but this will be the inner component ref IC, which is a Java IC. This kicks off a Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC. So the generated WSDL may not match the actual WSDL, which is a problem. Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the outer component's binding.ws/ we would not have had a problem; it would have been propagated inwards along with the binding itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2486) Some promotion scenarios aren't handled correctly by the builders
[ https://issues.apache.org/jira/browse/TUSCANY-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2486. - Resolution: Fixed This change is now in trunk as part of r679774. Some promotion scenarios aren't handled correctly by the builders - Key: TUSCANY-2486 URL: https://issues.apache.org/jira/browse/TUSCANY-2486 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.3 Reporter: Simon Nash Fix For: Java-SCA-1.3 The builders don't handle some promotion scenarios correctly. See TUSCANY-2324 and TUSCANY-2352 for descriptions of some of the problems. In looking into this area and trying to fix TUSCANY-2324 and validate the fix for TUSCANY-2352, I found a few other things that did not appear to be correct. In trying to understand what the problems are, it has become clear that we need a test framework specifically for the builders, so that the results of various different scenarios can be validated by introspecting the model without needing to start a runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Embedding Tuscany/SCA in Google Android
Hi Simon,
Thanks for your explanation. I think it is indeed the case that there is no
wire to support the connection. I have the impression that the service does
exist but the runtime thinks it doesn't or something else is going wrong.
I looked in more detail to see whether the composite is really being read. I
found that ContributionServiceImpl.contribute() calls
ContributionServiceImpl.addContribution(). After debugging I found that
there is an exception after processReadPhase where the read problems are
arising. The code excerpt below shows this step:
try {
// Allow access to read system properties. Requires
PropertyPermission in security policy.
// Any security exceptions are caught and wrapped as
ContributionException.
processReadPhase(contribution, contributionArtifacts);
} catch ( Exception e ) {
throw new ContributionException(e);
}
contribution is null and contributionArtifacts has the following contents:
[dex://calculator/CalculatorServiceImpl.class,
dex://calculator/AddServiceImpl.class,
dex://calculator/SubtractServiceImpl.class,
dex://calculator/MultiplyServiceImpl.class,
dex://calculator/DivideServiceImpl.class,
dex://calculator.android/raw/calculator.composite]
In summary ContributionServiceImpl.contribute() is not returning anything
but instead resulting in an exception. I will ask Adriano if the dex
protocol can read .class files, as Android doesn't use .class but .dex
instead. Maybe, dex protocol should access .dex files.
Let me know if you have any pointers or ideas. I'll keep you posted if I
find something new.
Thanks for your help.
On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
[EMAIL PROTECTED] wrote:
Good summary Oscar : )
I would like to reproduce your workspace and get this exception with only
the modules set your are using. I tried it, but I'm getting some errors
related to missing classes from the modules I removed. Could you make a new
step by step tutorial of how to reproduce a workspace like yours?
Thanks,
Adriano Crestani
On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
[EMAIL PROTECTED] wrote:
Hi,
I've been mostly using another thread for issues and questions concerning
running Tuscany/SCA on Android. Some progress has been made and a new thread
was needed.
Recently, Adriano reported some errors while testing changes to the
android sandbox and revision 674723 [1]. There was also a suggestion from
Luciano to look into calculator2 for coming up with a minimal set of modules
necessary to run calculator-android. I took the list of modules from the
tuscany-runtime2 and tuscany-api JARs of the revision that included
calculator2, and augmented it based on dependencies from revision 643746,
which was a previous revision, until the point in which I received the same
errors [2] that Adriano had reported. These errors result in the
RuntimeException shown below:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
org.osoa.sca.ServiceUnavailableException: Service not found for component
CalculatorServiceComponent reference setAddService (bindingURI=null
operation=add). Ensure that the composite containing the service is loaded
and started somewhere in the SCA domain and that if running in a remote
node that the interface of the target service marked as @Remotable
Seeing this error the first question that came to mind was: how do I
verify whether the composite containing the service is being loaded? and,
does it actually exist? I was thinking that maybe the composite was not
being created and thus was resulting in the errors in [3]. To test this I
changed the first line of calculator_composite to read as follows:
composite name=Calculator autowire=true
Setting the autowire attribute to true would make the runtime
automatically connect services and references in the composite, granted
there actually was one. This resulted in the error shown in [4] and included
in more detail in [5]. The fact that the runtime wires are being created
makes me think that a composite does exist, as documented in [6]. However,
the error messages confuse me and make me think otherwise, especially the
one shown below:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
Composite not found: dex://calculator.android/raw/calculator.composite
Any suggestions or ideas from the Tuscany community to resolve this
problem will be greatly appreciated. As Adriano mentioned in the previous
thread, we have a feeling we're getting closer to successfully embedding
Tuscany/SCA in Android.
[1]
[Vote] Release Tuscany Java SCA 1.3 RC2
Please review and vote on the release artifacts for the Tuscany SCA for Java 1.3 release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.3-RC2/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.3 ...ant
Re: Continuum build notifications
+1 to resume the notifications. We should try to fix build breaks as the 1st priority. Ensuring a good build is the basic confidence for the project. Thanks, Raymond From: Simon Laws Sent: Friday, July 25, 2008 12:28 AM To: dev@tuscany.apache.org Subject: Re: Continuum build notifications On Thu, Jul 24, 2008 at 9:47 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: Big +1 from me, i'd probably prefer the messages go to the commit list but either would be an improvement. We have clear evidence from the last few weeks that without these timely public reminders of the status of the build, the trunk is in a broken state far more often than it can be built cleanly. Looking back at the continuum history, there have been no successful SCA Java builds since the start of recorded history on May 7, 2008. So +++1 for restoring these notifications to the ML. I think these notifications are useful to people other than the committers, so I would prefer to have them on the dev list. Simon ...ant On Thu, Jul 24, 2008 at 8:16 PM, Luciano Resende [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have recently changed the Tuscany continuum build schedules to once a day instead of multiple times as it was originally set, and there was also some changes on the build error notification e-mails, that now contains only a summary of the errors and a link to the full log as on the notification example below. I was wondering that if we should get the build notifications back to the dev-list, as this would help us to get and continue with a stable trunk/build. Thoughts ? -- Forwarded message -- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Thu, Jul 3, 2008 at 3:18 AM Subject: [continuum] BUILD FAILURE: Tuscany - Apache Tuscany SCA Implementation Project - Build Def: To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=99875projectId=277 http://vmbuild.apache.org/continuum/buildResult.action?buildId=99875projectId=277 Build statistics: State: Failed Previous State: Failed Started at: Thu 3 Jul 2008 03:15:26 -0700 Finished at: Thu 3 Jul 2008 03:17:35 -0700 Total time: 2m 9s Build Trigger: Schedule Build Number: 195 Exit code: 1 Building machine hostname: vmbuild.apache.org http://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.8 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 Family: unix 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: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 108 Failures: 1 Total time: 8.749001 Test Failures: DefaultCorbaHostTestCase test_registerServant : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.fail(Assert.java:53) at org.apache.tuscany.sca.host.corba.testing.DefaultCorbaHostTestCase.test_registerServant(DefaultCorbaHostTestCase.java:94) at
Re: Renaming Store Tutorial project
Jean-Sebastien Delfino wrote: Luciano Resende wrote: I'd like to rename our current tutorial project to tutorial-store and start a new tutorial-photo-gallery to work on some web 2.0 scenarios. Please let me know if anyone have any issues with this, otherwise I'll plan to do this sometime tomorrow. +1 from me Now that we have two tutorials, I'd like to move them under tutorials/store and tutorials/photo-gallery. If there's no objection I'll do that later this weekend. -- Jean-Sebastien
Re: Renaming Store Tutorial project
+1 btw, photo-gallery tutorial is coming, but not in svn yet, so you just need to move tutorial-store to tutorial/store. On Fri, Jul 25, 2008 at 10:30 AM, Raymond Feng [EMAIL PROTECTED] wrote: +1. This is consistent with other folders such as demo, itest and samples. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:08 AM To: dev@tuscany.apache.org Subject: Re: Renaming Store Tutorial project Jean-Sebastien Delfino wrote: Luciano Resende wrote: I'd like to rename our current tutorial project to tutorial-store and start a new tutorial-photo-gallery to work on some web 2.0 scenarios. Please let me know if anyone have any issues with this, otherwise I'll plan to do this sometime tomorrow. +1 from me Now that we have two tutorials, I'd like to move them under tutorials/store and tutorials/photo-gallery. If there's no objection I'll do that later this weekend. -- Jean-Sebastien -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Error building binding-ws-axis2
I'm seeing the following error when building binding-ws-axis2. Anybody
else seeing this?
testSOAP12Endpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase)
Time elapsed: 0.702 sec ERROR!
org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase.setUp(QuestionMarkWSDLTestCase.java:130)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.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:597)
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.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.analyseProblems(DefaultSCADomain.java:309)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:334)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:183)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:120)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 20 more
--
Jean-Sebastien
Re: Renaming Store Tutorial project
Luciano Resende wrote: +1 btw, photo-gallery tutorial is coming, but not in svn yet, so you just need to move tutorial-store to tutorial/store. OK, will do, the exact path will be: tutorials/store tutorials/photo-gallery (when it comes) -- Jean-Sebastien
Re: Embedding Tuscany/SCA in Google Android
I think the class should be ok, as we just ask the classLoaders to
load it inside ClassReferenceModelResolver. Another thing to check is
how the CompositeProcessor is viewing the contents of
dex://calculator.android/raw/calculator.composite, it should be
available as XML, and parsing should be happening as expected in order
for the assembly model to be properly populated.
On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws [EMAIL PROTECTED] wrote:
On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
[EMAIL PROTECTED] wrote:
Hi Simon,
Thanks for your explanation. I think it is indeed the case that there is
no wire to support the connection. I have the impression that the service
does exist but the runtime thinks it doesn't or something else is going
wrong.
I looked in more detail to see whether the composite is really being read.
I found that ContributionServiceImpl.contribute() calls
ContributionServiceImpl.addContribution(). After debugging I found that
there is an exception after processReadPhase where the read problems are
arising. The code excerpt below shows this step:
try {
// Allow access to read system properties. Requires
PropertyPermission in security policy.
// Any security exceptions are caught and wrapped as
ContributionException.
processReadPhase(contribution, contributionArtifacts);
} catch ( Exception e ) {
throw new ContributionException(e);
}
contribution is null and contributionArtifacts has the following contents:
[dex://calculator/CalculatorServiceImpl.class,
dex://calculator/AddServiceImpl.class,
dex://calculator/SubtractServiceImpl.class,
dex://calculator/MultiplyServiceImpl.class,
dex://calculator/DivideServiceImpl.class,
dex://calculator.android/raw/calculator.composite]
In summary ContributionServiceImpl.contribute() is not returning anything
but instead resulting in an exception. I will ask Adriano if the dex
protocol can read .class files, as Android doesn't use .class but .dex
instead. Maybe, dex protocol should access .dex files.
Let me know if you have any pointers or ideas. I'll keep you posted if I
find something new.
Thanks for your help.
On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
[EMAIL PROTECTED] wrote:
Good summary Oscar : )
I would like to reproduce your workspace and get this exception with
only the modules set your are using. I tried it, but I'm getting some
errors
related to missing classes from the modules I removed. Could you make a new
step by step tutorial of how to reproduce a workspace like yours?
Thanks,
Adriano Crestani
On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
[EMAIL PROTECTED] wrote:
Hi,
I've been mostly using another thread for issues and questions
concerning running Tuscany/SCA on Android. Some progress has been made
and a
new thread was needed.
Recently, Adriano reported some errors while testing changes to the
android sandbox and revision 674723 [1]. There was also a suggestion from
Luciano to look into calculator2 for coming up with a minimal set of
modules
necessary to run calculator-android. I took the list of modules from the
tuscany-runtime2 and tuscany-api JARs of the revision that included
calculator2, and augmented it based on dependencies from revision 643746,
which was a previous revision, until the point in which I received the
same
errors [2] that Adriano had reported. These errors result in the
RuntimeException shown below:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
org.osoa.sca.ServiceUnavailableException: Service not found for component
CalculatorServiceComponent reference setAddService (bindingURI=null
operation=add). Ensure that the composite containing the service is loaded
and started somewhere in the SCA domain and that if running in a remote
node
that the interface of the target service marked as @Remotable
Seeing this error the first question that came to mind was: how do I
verify whether the composite containing the service is being loaded? and,
does it actually exist? I was thinking that maybe the composite was not
being created and thus was resulting in the errors in [3]. To test this I
changed the first line of calculator_composite to read as follows:
composite name=Calculator autowire=true
Setting the autowire attribute to true would make the runtime
automatically connect services and references in the composite, granted
there actually was one. This resulted in the error shown in [4] and
included
in more detail in [5]. The fact that the runtime wires are being created
makes me think that a composite does exist, as documented in [6]. However,
the error messages confuse me and make me think otherwise, especially the
one shown below:
java.lang.RuntimeException: Unable to start activity
Re: Error building binding-ws-axis2
Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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:597) 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.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:308) at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1884) ... 33 more -- Jean-Sebastien
[jira] Created: (TUSCANY-2498) Test case failure in binding-ws-wsdlgen module from the 1.3 tag
Test case failure in binding-ws-wsdlgen module from the 1.3 tag --- Key: TUSCANY-2498 URL: https://issues.apache.org/jira/browse/TUSCANY-2498 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Environment: Linux Reporter: Raymond Feng Priority: Blocker Fix For: Java-SCA-1.3 --- T E S T S --- Running org.apache.tuscany.sca.binding.ws.wsdlgen.BindingWSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.574 sec FAILURE! testCreateWSDLInterfaceContract(org.apache.tuscany.sca.binding.ws.wsdlgen.BindingWSDLGeneratorTestCase) Time elapsed: 0.565 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.BindingWSDLGenerator.createWSDLInterfaceContract(BindingWSDLGenerator.java:307) at org.apache.tuscany.sca.binding.ws.wsdlgen.BindingWSDLGeneratorTestCase.testCreateWSDLInterfaceContract(BindingWSDLGeneratorTestCase.java:77) 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:597) 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.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:597) 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.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:308) at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1884) ... 33 more Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.029 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.024 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620)
Re: [Vote] Release Tuscany Java SCA 1.3 RC2
Hi, I tried to build the 1.3 tag from scratch and ran into a blocker as reported by https://issues.apache.org/jira/browse/TUSCANY-2498. Thanks, Raymond From: ant elder Sent: Friday, July 25, 2008 7:05 AM To: dev@tuscany.apache.org Subject: [Vote] Release Tuscany Java SCA 1.3 RC2 Please review and vote on the release artifacts for the Tuscany SCA for Java 1.3 release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.3-RC2/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.3 ...ant
Re: Continuum build notifications
I was wondering that if we should get the build notifications back to the dev-list, as this would help us to get and continue with a stable trunk/build. +1 from me -- Thanks, Dan Becker
Re: Renaming Store Tutorial project
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Now that we have two tutorials, I'd like to move them under tutorials/store and tutorials/photo-gallery. If there's no objection I'll do that later this weekend. +1. It makes sense to me. -- Thanks, Dan Becker
Re: [Vote] Release Tuscany Java SCA 1.3 RC2
Please review and vote on the release artifacts for the Tuscany SCA for Java 1.3 release. +1. The artifacts unpacked for me and some of the sample ran fine. -- Thanks, Dan Becker
Re: [Vote] Release Tuscany Java SCA 1.3 RC2
This runs fine for me both before when the distribution was built and trying again now, both times with a clean repo with both Sun and IBM JDKs so i guess it must be some environment thing. I'm on WinXP what are you using? Did this work for you with RC1? ...ant On Fri, Jul 25, 2008 at 6:57 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I tried to build the 1.3 tag from scratch and ran into a blocker as reported by https://issues.apache.org/jira/browse/TUSCANY-2498. Thanks, Raymond *From:* ant elder [EMAIL PROTECTED] *Sent:* Friday, July 25, 2008 7:05 AM *To:* dev@tuscany.apache.org *Subject:* [Vote] Release Tuscany Java SCA 1.3 RC2 Please review and vote on the release artifacts for the Tuscany SCA for Java 1.3 release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.3-RC2/http://people.apache.org/%7Eantelder/tuscany/1.3-RC2/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/tuscany/tags/java/sca/1.3 ...ant
Re: Error building binding-ws-axis2
Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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:597) 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.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:308) at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1884) ... 33 more -- Jean-Sebastien
Re: Error building binding-ws-axis2
Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. I updated trunk to r679881 and did a mvn clean and rebuild of the modules directory. I didn't see any problems with binding-ws-wsdlgen or with binding-ws-axis2. Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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:597) 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.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:308) at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1884) ... 33 more -- Jean-Sebastien
Re: Error building binding-ws-axis2
Hi, It's broken on both trunk and 1.3 tag. The problem is that the generated xsd:import statement has invalid schemaLocation from the system id of the DOMResult which contains the schema from JAXB. I'm setting system id to so that the schemaLocation will be not generated. If the build is successful, I can commit the fix. Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:13 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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:597) at
Re: Error building binding-ws-axis2
Hi, I just checked in a fix for TUSCANY-2498 into trunk after a clean build. Please let me know if we agree to merge it into the 1.3 branch. Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:13 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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:597) 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.ws.commons.schema.XmlSchemaException:
Re: Error building binding-ws-axis2
Raymond Feng wrote: Hi, It's broken on both trunk and 1.3 tag. The problem is that the generated xsd:import statement has invalid schemaLocation from the system id of the DOMResult which contains the schema from JAXB. I'm setting system id to so that the schemaLocation will be not generated. If the build is successful, I can commit the fix. I think this change will regress the fix for TUSCANY-2479. I'm not sure why Ant and I don't see this problem and you and Sebastien do. What values do you see in the system ID with the current code? Simon Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:13 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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
Re: Error building binding-ws-axis2
Raymond Feng wrote: Hi, I just checked in a fix for TUSCANY-2498 into trunk after a clean build. Please let me know if we agree to merge it into the 1.3 branch. I don't agree until we understand more about what is the problem with the code currently in 1.3 RC2. What value do you see in the system ID without the change that you just checked in? Simon Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:13 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.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:597)
Re: Error building binding-ws-axis2
Here is the difference in the generated schema: Before my change: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:ns1=http://other.ws.binding.sca.tuscany.apache.org/; version=1.0 xs:import namespace=http://other.ws.binding.sca.tuscany.apache.org/; schemaLocation=http://other.ws.binding.sca.tuscany.apache.org/schema3.xsd/ ... /xs:schema With my change: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:ns1=http://other.ws.binding.sca.tuscany.apache.org/; version=1.0 xs:import namespace=http://other.ws.binding.sca.tuscany.apache.org// ... /xs:schema Please note the schemaLocation is not present any more as the WSDL inline schemas don't have a well-supported syntax for the schemaLocation URI. Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Friday, July 25, 2008 2:08 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 The system id was set to namespace + a file name generated by JAXB, such as schema3.xsd. In the failing test case, it was http://other.ws.binding.sca.tuscany.apache.org/schema3.xsd; and other.ws.binding.sca.tuscany.apache.org was taken as the host name. BTW, don't we have a testcase for TUSCANY-2479? My change doesn't break anything in the build. Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 1:50 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just checked in a fix for TUSCANY-2498 into trunk after a clean build. Please let me know if we agree to merge it into the 1.3 branch. I don't agree until we understand more about what is the problem with the code currently in 1.3 RC2. What value do you see in the system ID without the change that you just checked in? Simon Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:13 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) 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:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at
Re: Continuum build notifications
Ok, I'll resume build notifications early next week, this should give EVERYBODY enough time to get things working smoothly. As a reminder, build status and full logs can be seen in [1]. [1] http://vmbuild.apache.org/continuum/buildResults.action;jsessionid=2827ic4k5ujba?projectGroupId=19projectId=277 On Fri, Jul 25, 2008 at 11:14 AM, Dan Becker [EMAIL PROTECTED] wrote: I was wondering that if we should get the build notifications back to the dev-list, as this would help us to get and continue with a stable trunk/build. +1 from me -- Thanks, Dan Becker -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Error building binding-ws-axis2
Raymond Feng wrote: Hi, I just checked in a fix for TUSCANY-2498 into trunk after a clean build. Please let me know if we agree to merge it into the 1.3 branch. Thanks, Raymond SVN r679890 fixes the build break in trunk. Thanks! -- Jean-Sebastien
Re: Error building binding-ws-axis2
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'm seeing the following error when building binding-ws-axis2. Anybody
else seeing this?
...
Well that was with a revision from yesterday, with SVN r679776 I'm
getting another error in modules/binding-ws-wsdlgen.
So, the binding-ws-wsdlgen error is fixed, back to the error with
binding-ws-axis2, now on SVN r679890, as you can see below, 26 out of 30
tests are failing:
testSOAP12Endpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase)
Time elapsed: 1.229 sec ERROR!
org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase.setUp(QuestionMarkWSDLTestCase.java:130)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.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:597)
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.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.analyseProblems(DefaultSCADomain.java:309)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:334)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:183)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:120)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 20 more
Results :
Tests in error:
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testEchoFoo(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldTestCase)
testUriPrecedence(org.apache.tuscany.sca.binding.ws.axis2.itests.UriPrecedenceTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.epr.HelloWorldTestCase)
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP11(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP12(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testWSDLImportPortEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLImportTestCase)
testWSDLPortEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLTestCase)
testCustomEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.endpoints.WSDLRelativeURITestCase)
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.policy.mixed.WSSecurityMixedTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.endpoints.WSDLExplicitURITestCase)
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldWSDLMergedTestCase)
Re: Error building binding-ws-axis2
On Fri, Jul 25, 2008 at 11:45 PM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'm seeing the following error when building binding-ws-axis2. Anybody
else seeing this?
...
Well that was with a revision from yesterday, with SVN r679776 I'm getting
another error in modules/binding-ws-wsdlgen.
So, the binding-ws-wsdlgen error is fixed, back to the error with
binding-ws-axis2, now on SVN r679890, as you can see below, 26 out of 30
tests are failing:
testSOAP12Endpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase)
Time elapsed: 1.229 sec ERROR!
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
Provided Intent - {
http://tuscany.apache.org/xmlns/sca/1.0}wsAuthenticationhttp://tuscany.apache.org/xmlns/sca/1.0%7DwsAuthenticationnot
found for PolicySet {
http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicyhttp://tuscany.apache.org/xmlns/sca/1.0%7DwsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase.setUp(QuestionMarkWSDLTestCase.java:130)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.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:597)
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.osoa.sca.ServiceRuntimeException: Provided Intent - {
http://tuscany.apache.org/xmlns/sca/1.0}wsAuthenticationhttp://tuscany.apache.org/xmlns/sca/1.0%7DwsAuthenticationnot
found for PolicySet {
http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicyhttp://tuscany.apache.org/xmlns/sca/1.0%7DwsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.analyseProblems(DefaultSCADomain.java:309)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:334)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:183)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:120)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 20 more
Results :
Tests in error:
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testEchoFoo(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldTestCase)
testUriPrecedence(org.apache.tuscany.sca.binding.ws.axis2.itests.UriPrecedenceTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.epr.HelloWorldTestCase)
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP11(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP12(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testWSDLImportPortEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLImportTestCase)
testWSDLPortEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLTestCase)
testCustomEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLTestCase)
Re: Error building binding-ws-axis2
Hi,
Can you try this patch?
Index:
src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/mixed/definitions.xml
===
---
src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/mixed/definitions.xml (revision
679873)
+++
src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/mixed/definitions.xml (working
copy)
@@ -23,6 +23,15 @@
xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0;
!-- WS Security POLICY SETS --
+ !-- A policyset that uses WS Policy --
+ sca:intent name=wsAuthentication
+constrains=sca:binding.ws
+description
+Communitcation thro this binding required
Authentication.
+/description
+ /sca:intent+
+ !-- WS Security POLICY SETS --
sca:policySet name=wsAuthenticationPolicy
provides=sca:authentication
appliesTo=//sca:binding.ws
Thanks,
Raymond
--
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
Sent: Friday, July 25, 2008 3:45 PM
To: dev@tuscany.apache.org
Subject: Re: Error building binding-ws-axis2
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'm seeing the following error when building binding-ws-axis2. Anybody
else seeing this?
...
Well that was with a revision from yesterday, with SVN r679776 I'm
getting another error in modules/binding-ws-wsdlgen.
So, the binding-ws-wsdlgen error is fixed, back to the error with
binding-ws-axis2, now on SVN r679890, as you can see below, 26 out of 30
tests are failing:
testSOAP12Endpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase)
Time elapsed: 1.229 sec ERROR!
org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase.setUp(QuestionMarkWSDLTestCase.java:130)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.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:597)
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.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.analyseProblems(DefaultSCADomain.java:309)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:334)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:183)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:120)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 20 more
Results :
Tests in error:
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testEchoFoo(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldTestCase)
Re: How to avoid build breaks
On Fri, Jul 25, 2008 at 9:44 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, As being discussed on the other thread, we all agree that it's very important to keep the trunk build successfully all the time. Builds will break its a fact of life, and this is especially true in an open source development environment with a diverse range of committers and with Tuscany as it has got so big. Don't get take this wrong sure its better when the trunk builds cleanly but I'd like to understand who is this very important to and is there something else we could be doing to make things better for them. From my perspective as an active developer on Tuscany although the trunk has been getting broken a bit recently that hasn't been causing me so much inconvenience as its usually easy enough to work around things by using mvn -fn or -Dmaven.test.skip=true or commenting something out locally. It takes a little more work but i think its worth it as we've seen in that past people get put off when they're made to feel scared to commit in case they do something wrong. Tuscany builds take ages so I often don't do a full build before checking things in. If i've just made changes in say the jms binding why build the demos, tutorials, and vtests when none of those use JMS? If I just change an itest why build anything else at all? I often work like this and (fingers crossed) hardly ever break the build, and this is also the way our maven incremental builder works. I don't think trunk breaks will be bothering our users much as they mostly use the releases or published snapshots. If there are some people who really need clean builds then maybe we should look at something like a more stable branch which we do try hard to keep building cleanly all the time. Or if we did releases more often like we did back with the monthly 0.9x releases then we'd have those more stable branches anyway and reasonably closely tracking the trunk changes. Newer developers to Tuscany may have more trouble with trunk breaks but they first probably have more trouble battling with maven to get the vast array of dependencies downloaded successfully from the repositories. Maybe Tuscany is just getting too big for the current structure and one option could be to look at splitting things up somehow into more smaller discrete functional parts which may make it easier to work on? ...ant
Re: Error building binding-ws-axis2
Raymond Feng wrote: The system id was set to namespace + a file name generated by JAXB, such as schema3.xsd. In the failing test case, it was http://other.ws.binding.sca.tuscany.apache.org/schema3.xsd; and other.ws.binding.sca.tuscany.apache.org was taken as the host name. The system ID has always been set to this value. The recent change I made for TUSCANY-2479 did not change the system ID, but made sure that its value is propagated to the XmlSchema object that is created by Interface2WSDLGenerator.loadXSD(). This allows XmlSchema imports to resolve correctly. I built 1.3 RC2 with an empty maven repo. The modules databinding-jaxb, binding-ws-wsdlgen and binding-ws-axis2 all built OK. We are doing the same thing, but our results are different. One possibility is such cases is a difference between the Sun and IBM JDKs. I'm on Sun JDK 1.5.0_13-b03, so I tried changing to the IBM JDK and this produced the build failure you and Sebastien are seeing when the system ID is set to a non-null string. I applied your change to set the system ID to and it seems this works OK for me. I'd like to know whether this also works for Scott in his environment. If it does, it seems we should go with this approach for 1.3 as this appears to be the only combination that works on both the Sun and IBM JDKs. BTW, don't we have a testcase for TUSCANY-2479? My change doesn't break anything in the build. Yes, the test case for this is in binding-ws-wsdlgen. This is the test case that was breaking for you with the IBM JDK before you made your change. However, it was working for me with the Sun JDK. Simon Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 1:50 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just checked in a fix for TUSCANY-2498 into trunk after a clean build. Please let me know if we agree to merge it into the 1.3 branch. I don't agree until we understand more about what is the problem with the code currently in 1.3 RC2. What value do you see in the system ID without the change that you just checked in? Simon Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Friday, July 25, 2008 12:13 PM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Raymond Feng wrote: Hi, I just ran a build against the trunk and 1.3 tag and I don't see the issue related to the binding-ws-axis2. I already opened a JIRA for wsdlgen test failures: https://issues.apache.org/jira/browse/TUSCANY-2498. Does this problem only apply to the 1.3 tag? The description in TUSCANY-2498 suggests this. Does trunk build cleanly for you? Simon Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, July 25, 2008 10:55 AM To: dev@tuscany.apache.org Subject: Re: Error building binding-ws-axis2 Jean-Sebastien Delfino wrote: I'm seeing the following error when building binding-ws-axis2. Anybody else seeing this? ... Well that was with a revision from yesterday, with SVN r679776 I'm getting another error in modules/binding-ws-wsdlgen. Running org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.156 sec FAILURE! testGenerate(org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase) Time elapsed: 0.139 sec ERROR! java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException: other.ws.binding.sca.tuscany.apache.org at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1886) at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1620) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:175) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:82) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:359) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:353) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:402) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:384) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:256) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGeneratorTestCase.testGenerate(Interface2WSDLGeneratorTestCase.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
Re: Error building binding-ws-axis2
On Sat, Jul 26, 2008 at 12:08 AM, Simon Nash [EMAIL PROTECTED] wrote: Raymond Feng wrote: The system id was set to namespace + a file name generated by JAXB, such as schema3.xsd. In the failing test case, it was http://other.ws.binding.sca.tuscany.apache.org/schema3.xsd; and other.ws.binding.sca.tuscany.apache.org was taken as the host name. The system ID has always been set to this value. The recent change I made for TUSCANY-2479 did not change the system ID, but made sure that its value is propagated to the XmlSchema object that is created by Interface2WSDLGenerator.loadXSD(). This allows XmlSchema imports to resolve correctly. I built 1.3 RC2 with an empty maven repo. The modules databinding-jaxb, binding-ws-wsdlgen and binding-ws-axis2 all built OK. We are doing the same thing, but our results are different. One possibility is such cases is a difference between the Sun and IBM JDKs. I'm on Sun JDK 1.5.0_13-b03, so I tried changing to the IBM JDK and this produced the build failure you and Sebastien are seeing when the system ID is set to a non-null string. I applied your change to set the system ID to and it seems this works OK for me. I'd like to know whether this also works for Scott in his environment. If it does, it seems we should go with this approach for 1.3 as this appears to be the only combination that works on both the Sun and IBM JDKs. Seems fine to me too if it fixes it but it does work fine for me with both Sun JDK and IBMs 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20080315 (SR7)) ...ant
Re: Error building binding-ws-axis2
Simon Nash wrote: Raymond Feng wrote: One possibility is such cases is a difference between the Sun and IBM JDKs. I'm on Sun JDK 1.5.0_13-b03, so I tried changing to the IBM JDK and this produced the build failure you and Sebastien are seeing when the system ID is set to a non-null string. I'm usually building in parallel on Windows IBM JDK 1.5 SR8, Linux RHEL 5 IBM JDK 1.5 SR8 and Linux RHEL 5 SUN JDK 6 Update 7. All three failed with the same error before Raymond's change. All work with his change. -- Jean-Sebastien
Re: How do I get my Continuum build server account unlocked?
Do you mean you're a Confluence or Continuum admin? Its a Continuum admin we need, my id is antelder. ...ant On Fri, Jul 25, 2008 at 5:33 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I have the cwiki admin right and I can add committers to the tuscany-committers group. Please let me your confluence id if you are not on the list. Thanks, Raymond *From:* ant elder [EMAIL PROTECTED] *Sent:* Friday, July 25, 2008 5:18 AM *To:* dev@tuscany.apache.org *Subject:* Re: How do I get my Continuum build server account unlocked? As we're sorting out the cwiki admins its reminded me of this, what is the status of this and do we have any continuum admins in Tuscany able to add committers to the Tuscany group? As the notifications are going to start being sent to the mailing list again i think we should have all committers able to kick off new continuum builds so they're able to verify if the build is fixed. If not I'll try i'll raise a JIRA to get my id going again but might as well include anyone else on that one JIRA as well, I'll also try to get some Tuscany admin's so we can do this ourselves in future without JIRAs. ...ant On Fri, May 23, 2008 at 3:58 PM, Luciano Resende [EMAIL PROTECTED] wrote: Looks like the Continuum was upgraded and the security level too so we are going to see only the Tuscany project if you are loged in. 1.To unlock account : Create a Infra JIRA like this one https://issues.apache.org/jira/browse/INFRA-1616 2.To create account : on the upper left corner there is a register link, after you are registered, please let me know and I can try adding you to the group (I couldn't before)... otherwise you would have to create another JIRA for infra. Please let me know if you have more questions... On Fri, May 23, 2008 at 3:23 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 11:05 AM, Mark Combellack [EMAIL PROTECTED] wrote: -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 23 May 2008 11:01 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How do I get my Continuum build server account unlocked? On Fri, May 23, 2008 at 10:55 AM, Mark Combellack [EMAIL PROTECTED] wrote: Hi, I've just tried accessing the Continuum build server [1] and have discovered that my account is locked. How do I go about getting my account unlocked? Can anyone do this for me? My account id is mcombellack. Thanks, Mark [1] http://vmbuild.apache.org/continuum/ And an additional question. How did you get the account in the first place. I'd like to be able to kick off builds etc and I'm assuming I need an account to be able to do that. How does one go about getting one? Simon I did this many months ago so I am a bit vague on the exact detail. To get my account, I clicked the register link on the page and created an account. I then posted a request to the Tuscany dev list to be added to the Tuscany build group. Someone then did something and some time later I could then see and start Tuscany builds. Mark OK, thanks for that Mark. When I go to http://vmbuild.apache.org:8080/continuum I don't see any projects at all. Either that's now the wrong link or something more serious is up. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: How to avoid build breaks
On Fri, Jul 25, 2008 at 4:07 PM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jul 25, 2008 at 9:44 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, As being discussed on the other thread, we all agree that it's very important to keep the trunk build successfully all the time. I don't think it's a must to have it successfully building at all times. Builds will break its a fact of life, and this is especially true in an open source development environment with a diverse range of committers and with Tuscany as it has got so big. Don't get take this wrong sure its better when the trunk builds cleanly but I'd like to understand who is this very important to and is there something else we could be doing to make things better for them. I agree that builds will break, and I have done that multiple times. But I also expect that, if the build breaks, the person that caused the build issue would take a look and try to fix it. What I don't think it's desirable is to get a broken build for several weeks, I think this can affect the overall community. From my perspective as an active developer on Tuscany although the trunk has been getting broken a bit recently that hasn't been causing me so much inconvenience as its usually easy enough to work around things by using mvn -fn or -Dmaven.test.skip=true or commenting something out locally. It takes a little more work but i think its worth it as we've seen in that past people get put off when they're made to feel scared to commit in case they do something wrong. Agree that we can easily workaround it, and we should document this for others as well. The issue is when there are dependencies on the broken modules. Tuscany builds take ages so I often don't do a full build before checking things in. If i've just made changes in say the jms binding why build the demos, tutorials, and vtests when none of those use JMS? If I just change an itest why build anything else at all? I often work like this and (fingers crossed) hardly ever break the build, and this is also the way our maven incremental builder works. I don't think trunk breaks will be bothering our users much as they mostly use the releases or published snapshots. If there are some people who really need clean builds then maybe we should look at something like a more stable branch which we do try hard to keep building cleanly all the time. Or if we did releases more often like we did back with the monthly 0.9x releases then we'd have those more stable branches anyway and reasonably closely tracking the trunk changes. Newer developers to Tuscany may have more trouble with trunk breaks but they first probably have more trouble battling with maven to get the vast array of dependencies downloaded successfully from the repositories. Maybe Tuscany is just getting too big for the current structure and one option could be to look at splitting things up somehow into more smaller discrete functional parts which may make it easier to work on? ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
My guess is that the message complains:
With the following policySet:
sca:policySet name=wsClientAuthenticationPolicy
provides=tuscany:wsAuthentication
appliesTo=//sca:binding.ws
tuscany:wsAuthentication is a provided intent by the policy set and it
cannot find the definition of intent tuscany:wsAuthentication.
Thanks,
Raymond
--
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
Sent: Friday, July 25, 2008 4:39 PM
To: dev@tuscany.apache.org
Subject: Policy error building binding-ws-axis2, was: Error building
binding-ws-axis2
Raymond Feng wrote:
Can you try this patch?
...
Sorry, it didn't fix it. I'm not too surprised as the error below says the
problem is a provided intent cannot be found (while your patch was
trying to apply an intent).
However I'm just guessing as I'm a little confused by the error message
and the policy definitions in the failing test case.
org.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
--
Jean-Sebastien
Re: Error building binding-ws-axis2
ant elder wrote: On Sat, Jul 26, 2008 at 12:08 AM, Simon Nash [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Raymond Feng wrote: The system id was set to namespace + a file name generated by JAXB, such as schema3.xsd. In the failing test case, it was http://other.ws.binding.sca.tuscany.apache.org/schema3.xsd; and other.ws.binding.sca.tuscany.apache.org http://other.ws.binding.sca.tuscany.apache.org was taken as the host name. The system ID has always been set to this value. The recent change I made for TUSCANY-2479 did not change the system ID, but made sure that its value is propagated to the XmlSchema object that is created by Interface2WSDLGenerator.loadXSD(). This allows XmlSchema imports to resolve correctly. I built 1.3 RC2 with an empty maven repo. The modules databinding-jaxb, binding-ws-wsdlgen and binding-ws-axis2 all built OK. We are doing the same thing, but our results are different. One possibility is such cases is a difference between the Sun and IBM JDKs. I'm on Sun JDK 1.5.0_13-b03, so I tried changing to the IBM JDK and this produced the build failure you and Sebastien are seeing when the system ID is set to a non-null string. I applied your change to set the system ID to and it seems this works OK for me. I'd like to know whether this also works for Scott in his environment. If it does, it seems we should go with this approach for 1.3 as this appears to be the only combination that works on both the Sun and IBM JDKs. Seems fine to me too if it fixes it but it does work fine for me with both Sun JDK and IBMs 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20080315 (SR7)) Do you mean RC2 works fine with both of these, without the recent change from Raymond? The IBM JDK that I used for testing was J2RE 1.5.0 IBM Windows 32 build pwi32dev-20070201 (SR4). Maybe there is an IBM JDK bug that was fixed in the newer level. Simon ...ant
Re: How do I get my Continuum build server account unlocked?
ant elder wrote: As we're sorting out the cwiki admins its reminded me of this, what is the status of this and do we have any continuum admins in Tuscany able to add committers to the Tuscany group? As the notifications are going to start being sent to the mailing list again i think we should have all committers able to kick off new continuum builds so they're able to verify if the build is fixed. If not I'll try i'll raise a JIRA to get my id going again but might as well include anyone else on that one JIRA as well, I'll also try to get some Tuscany admin's so we can do this ourselves in future without JIRAs. I would like to have Continuum admin powers to be able to do this. Simon ...ant On Fri, May 23, 2008 at 3:58 PM, Luciano Resende [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Looks like the Continuum was upgraded and the security level too so we are going to see only the Tuscany project if you are loged in. 1.To unlock account : Create a Infra JIRA like this one https://issues.apache.org/jira/browse/INFRA-1616 2.To create account : on the upper left corner there is a register link, after you are registered, please let me know and I can try adding you to the group (I couldn't before)... otherwise you would have to create another JIRA for infra. Please let me know if you have more questions... On Fri, May 23, 2008 at 3:23 AM, Simon Laws [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 11:05 AM, Mark Combellack [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: 23 May 2008 11:01 To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]; [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Re: How do I get my Continuum build server account unlocked? On Fri, May 23, 2008 at 10:55 AM, Mark Combellack [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I've just tried accessing the Continuum build server [1] and have discovered that my account is locked. How do I go about getting my account unlocked? Can anyone do this for me? My account id is mcombellack. Thanks, Mark [1] http://vmbuild.apache.org/continuum/ And an additional question. How did you get the account in the first place. I'd like to be able to kick off builds etc and I'm assuming I need an account to be able to do that. How does one go about getting one? Simon I did this many months ago so I am a bit vague on the exact detail. To get my account, I clicked the register link on the page and created an account. I then posted a request to the Tuscany dev list to be added to the Tuscany build group. Someone then did something and some time later I could then see and start Tuscany builds. Mark OK, thanks for that Mark. When I go to http://vmbuild.apache.org:8080/continuum I don't see any projects at all. Either that's now the wrong link or something more serious is up. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: How do I get my Continuum build server account unlocked?
I only have the confluence admin. Thanks, Raymond From: ant elder Sent: Friday, July 25, 2008 4:36 PM To: dev@tuscany.apache.org Subject: Re: How do I get my Continuum build server account unlocked? Do you mean you're a Confluence or Continuum admin? Its a Continuum admin we need, my id is antelder. ...ant On Fri, Jul 25, 2008 at 5:33 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I have the cwiki admin right and I can add committers to the tuscany-committers group. Please let me your confluence id if you are not on the list. Thanks, Raymond From: ant elder Sent: Friday, July 25, 2008 5:18 AM To: dev@tuscany.apache.org Subject: Re: How do I get my Continuum build server account unlocked? As we're sorting out the cwiki admins its reminded me of this, what is the status of this and do we have any continuum admins in Tuscany able to add committers to the Tuscany group? As the notifications are going to start being sent to the mailing list again i think we should have all committers able to kick off new continuum builds so they're able to verify if the build is fixed. If not I'll try i'll raise a JIRA to get my id going again but might as well include anyone else on that one JIRA as well, I'll also try to get some Tuscany admin's so we can do this ourselves in future without JIRAs. ...ant On Fri, May 23, 2008 at 3:58 PM, Luciano Resende [EMAIL PROTECTED] wrote: Looks like the Continuum was upgraded and the security level too so we are going to see only the Tuscany project if you are loged in. 1.To unlock account : Create a Infra JIRA like this one https://issues.apache.org/jira/browse/INFRA-1616 2.To create account : on the upper left corner there is a register link, after you are registered, please let me know and I can try adding you to the group (I couldn't before)... otherwise you would have to create another JIRA for infra. Please let me know if you have more questions... On Fri, May 23, 2008 at 3:23 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 11:05 AM, Mark Combellack [EMAIL PROTECTED] wrote: -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 23 May 2008 11:01 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How do I get my Continuum build server account unlocked? On Fri, May 23, 2008 at 10:55 AM, Mark Combellack [EMAIL PROTECTED] wrote: Hi, I've just tried accessing the Continuum build server [1] and have discovered that my account is locked. How do I go about getting my account unlocked? Can anyone do this for me? My account id is mcombellack. Thanks, Mark [1] http://vmbuild.apache.org/continuum/ And an additional question. How did you get the account in the first place. I'd like to be able to kick off builds etc and I'm assuming I need an account to be able to do that. How does one go about getting one? Simon I did this many months ago so I am a bit vague on the exact detail. To get my account, I clicked the register link on the page and created an account. I then posted a request to the Tuscany dev list to be added to the Tuscany build group. Someone then did something and some time later I could then see and start Tuscany builds. Mark OK, thanks for that Mark. When I go to http://vmbuild.apache.org:8080/continuum I don't see any projects at all. Either that's now the wrong link or something more serious is up. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
[jira] Commented: (TUSCANY-2499) Build error trying to resolve policy intent in binding-ws-axis2
[
https://issues.apache.org/jira/browse/TUSCANY-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617113#action_12617113
]
Jean-Sebastien Delfino commented on TUSCANY-2499:
-
I have committed a work around in SVN r679944. The underlying issue (problems
resolving provided policy intents) still needs to be fixed.
Build error trying to resolve policy intent in binding-ws-axis2
---
Key: TUSCANY-2499
URL: https://issues.apache.org/jira/browse/TUSCANY-2499
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Environment: Linux RHEL5
Reporter: Jean-Sebastien Delfino
Priority: Critical
Fix For: Java-SCA-Next
Building SVN r679890 gives the following error:
testSOAP12Endpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase)
Time elapsed: 1.229 sec ERROR!
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
Provided Intent - {http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication
not found for PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.QuestionMarkWSDLTestCase.setUp(QuestionMarkWSDLTestCase.java:130)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.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:597)
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.osoa.sca.ServiceRuntimeException: Provided Intent -
{http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
PolicySet
{http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.analyseProblems(DefaultSCADomain.java:309)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:334)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:183)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:120)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 20 more
Results :
Tests in error:
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testEchoFoo(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldNoWSDLTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldTestCase)
testUriPrecedence(org.apache.tuscany.sca.binding.ws.axis2.itests.UriPrecedenceTestCase)
testCalculator(org.apache.tuscany.sca.binding.ws.axis2.itests.epr.HelloWorldTestCase)
testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP11(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testHelloWorldSOAP12(org.apache.tuscany.sca.binding.ws.axis2.itests.soap12.HelloWorldSOAP12TestCase)
testWSDLImportPortEndpoint(org.apache.tuscany.sca.binding.ws.axis2.itests.QuestionMarkWSDLImportTestCase)
