Build coordinator volunteer, was: Continuum build has completed successfully!
Simon Nash wrote: The Continuum build just completed successfully, for the first time since November 12th! Let's all try hard to keep it working from now on. Simon Thanks so much! Now that the build is going again, how about having a build coordinator person monitoring build issues, raising JIRAs and the community's attention on tuscany-dev and helping coordinate resolutions? We could rotate that role as we've done for release managers. I don't think that person even needs to be a committer, it could be a great way to get involved for anybody who wants to help. Any volunteer? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1965) sample-callback-ws-service fails to callback to the 2nd instance of sample-callback-ws-client
sample-callback-ws-service fails to callback to the 2nd instance of sample-callback-ws-client - Key: TUSCANY-1965 URL: https://issues.apache.org/jira/browse/TUSCANY-1965 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Priority: Critical Start the sample-callback-ws-service, and then run sample-callback-ws-client. It will be successful for the first time. Then run sample-callback-ws-client again, the sample-callback-ws-service will fail to callback with a ConnectException. Here is the problem behind, say the client starts the "callback service": at port X, then service side set X into the wire for the callback. When the client runs for the 2nd time, the "callback service" listens on a new port Y, but the service side still use the staled port X to make the callback. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1964) store sample doesn't work with IE7
[ https://issues.apache.org/jira/browse/TUSCANY-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558107#action_12558107 ] Raymond Feng commented on TUSCANY-1964: --- I have the same IE version as yours. Not sure why it fails for me. > store sample doesn't work with IE7 > -- > > Key: TUSCANY-1964 > URL: https://issues.apache.org/jira/browse/TUSCANY-1964 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-SCA-1.1, Java-SCA-Next >Reporter: Raymond Feng > > The store sample is not working well with IE7. Clicking on "Add to Cart" > buttondoesn't add new items. The browser complains that > "document.getElementById()" returns null on Line 50. It works with FireFox. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1)
Hi, I ran through the samples packaged in the RC1 and here are a list of issues I found so far: 1) TUSCANY-1963: callback-ws-client sample fails with IndexOutOfBoundsException 2) TUSCANY-1964: store sample doesn't work with IE7 3) TUSCANY-1956: SecurityException thrown in helloworld-bpel calculator-implementation-policies: fails with SecurityException: Unable to locate a login configuartion (Not sure if we already a JIRA opened for this) The rest of the samples work fine. The license/notice side looks good to me. I will vote +0 at this point. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Thursday, January 10, 2008 7:25 AM Subject: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1) Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC1/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC1/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch or raise jira's targeting the 1.1 release. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1964) store sample doesn't work with IE7
[ https://issues.apache.org/jira/browse/TUSCANY-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558091#action_12558091 ] Luciano Resende commented on TUSCANY-1964: -- Can't reproduce with SCA 1.1 RC1 using IE 7.0.5730.11 I can add multiple items to the shopping cart, checkout, and then continue to add more items... > store sample doesn't work with IE7 > -- > > Key: TUSCANY-1964 > URL: https://issues.apache.org/jira/browse/TUSCANY-1964 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-SCA-1.1, Java-SCA-Next >Reporter: Raymond Feng > > The store sample is not working well with IE7. Clicking on "Add to Cart" > buttondoesn't add new items. The browser complains that > "document.getElementById()" returns null on Line 50. It works with FireFox. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: impl-bpel shutdown issue
You are right, I'll commit this other part of the workaround into the 1.1 branch in case we do another RC. On Jan 11, 2008 11:18 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I'm still seeing the SecurityException with 1.1 RC1 as the "java" task in > ANT script still has the "fork=true" attribute commented out. > > Thanks, > Raymond > > - Original Message - > From: "Luciano Resende" <[EMAIL PROTECTED]> > To: > > Sent: Wednesday, January 09, 2008 11:11 AM > Subject: Re: impl-bpel shutdown issue > > > > After some investigation, it looks like the threads that are hanging > > are from ODE, when we deploy the BPEL process, and it's only happening > > on a non-maven environment. For now, i'll add an ugly workaround for > > our 1.1 release on the sample application, to do a System.exit(0) and > > work with the ODE guys to provide a solution for the thread issue. > > > > Thoughts > > > > > > On Jan 8, 2008 4:17 PM, Luciano Resende <[EMAIL PROTECTED]> wrote: > >> Looks like we have the thread pool and derby with some hanging > >> threads, based on this thread dump > >> > >> Full thread dump Java HotSpot(TM) Client VM (1.5.0_11-b03 mixed mode): > >> > >> "DestroyJavaVM" prio=6 tid=0x0003ca68 nid=0x1554 waiting on condition > >> [0x..0x0007fae8] > >> > >> "pool-3-thread-1" prio=6 tid=0x0b4249d0 nid=0x1958 waiting on > >> condition [0x0cccf000..0x0cccfce8] > >> at sun.misc.Unsafe.park(Native Method) > >> at > >> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146) > >> at > >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:772) > >> at > >> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1087) > >> at > >> java.util.concurrent.SynchronousQueue$Node.waitForPut(SynchronousQueue.java:291) > >> at > >> java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:443) > >> at > >> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:475) > >> at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674) > >> at java.lang.Thread.run(Thread.java:595) > >> > >> "pool-2-thread-1" prio=6 tid=0x0b4a1e18 nid=0x1b00 waiting on > >> condition [0x0bc8f000..0x0bc8fd68] > >> at sun.misc.Unsafe.park(Native Method) > >> at > >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:118) > >> at > >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1767) > >> at > >> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359) > >> at > >> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470) > >> at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674) > >> at java.lang.Thread.run(Thread.java:595) > >> > >> "Thread-2" daemon prio=6 tid=0x0b062d90 nid=0x1430 waiting on > >> condition [0x0bc0f000..0x0bc0fa68] > >> at java.lang.Thread.sleep(Native Method) > >> at > >> org.apache.geronimo.transaction.manager.TransactionTimer$CurrentTime.run(TransactionTimer.java:38) > >> > >> "derby.rawStoreDaemon" daemon prio=6 tid=0x0b7c4a18 nid=0x15c0 in > >> Object.wait() [0x0bbcf000..0x0bbcfae8] > >> at java.lang.Object.wait(Native Method) > >> - waiting on <0x03194110> (a > >> org.apache.derby.impl.services.daemon.BasicDaemon) > >> at org.apache.derby.impl.services.daemon.BasicDaemon.rest(Unknown > >> Source) > >> - locked <0x03194110> (a > >> org.apache.derby.impl.services.daemon.BasicDaemon) > >> at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown > >> Source) > >> at java.lang.Thread.run(Thread.java:595) > >> > >> "derby.antiGC" daemon prio=2 tid=0x0b7ad008 nid=0x194c in > >> Object.wait() [0x0bb0f000..0x0bb0fb68] > >> at java.lang.Object.wait(Native Method) > >> - waiting on <0x031163e0> (a > >> org.apache.derby.impl.services.monitor.AntiGC) > >> at java.lang.Object.wait(Object.java:474) > >> at org.apache.derby.impl.services.monitor.AntiGC.run(Unknown > >> Source) > >> - locked <0x031163e0> (a > >> org.apache.derby.impl.services.monitor.AntiGC) > >> at java.lang.Thread.run(Thread.java:595) > >> > >> "Timer-0" daemon prio=6 tid=0x0ad25168 nid=0x1fc4 in Object.wait() > >> [0x0bacf000..0x0bacfbe8] > >> at java.lang.Object.wait(Native Method) > >> - waiting on <0x031127b0> (a java.util.TaskQueue) > >> at java.util.TimerThread.mainLoop(Timer.java:509) > >> - locked <0x031127b0> (a java.util.TaskQueue) > >> at java.util.TimerThread.run(Timer.java:462) > >> > >> "Low Memory Detector" daemon prio=6 tid=0x00aa6730 nid=0x1f40 runnable > >> [0x..0x] > >> > >> "CompilerThread0" daemon prio=10 tid=0x00aa5460 nid=0x14dc waiting
[jira] Created: (TUSCANY-1964) store sample doesn't work with IE7
store sample doesn't work with IE7 -- Key: TUSCANY-1964 URL: https://issues.apache.org/jira/browse/TUSCANY-1964 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1, Java-SCA-Next Reporter: Raymond Feng The store sample is not working well with IE7. Clicking on "Add to Cart" buttondoesn't add new items. The browser complains that "document.getElementById()" returns null on Line 50. It works with FireFox. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1963) callback-ws-client sample fails with IndexOutOfBoundsException
callback-ws-client sample fails with IndexOutOfBoundsException -- Key: TUSCANY-1963 URL: https://issues.apache.org/jira/browse/TUSCANY-1963 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.1, Java-SCA-Next Reporter: Raymond Feng Buildfile: build.xml run: [java] Jan 11, 2008 11:35:41 AM org.apache.tuscany.sca.node.impl.SCADomainProxyImpl init [java] INFO: Domain will be started stand-alone as domain URL is not provided [java] Jan 11, 2008 11:35:41 AM org.apache.tuscany.sca.domain.impl.SCADomainImpl registerNode [java] INFO: Registered node: http://rfengt60p:4407 at endpoint http://rfengt60p:4407 [java] Jan 11, 2008 11:35:41 AM org.apache.tuscany.sca.node.impl.SCADomainProxyImpl createRuntime [java] INFO: Domain management configured from file:/C:/Apache/tuscany-sca-1.1-incubating/modules/tuscany-node-impl-1.1-incubating.jar [java] Exception in thread "main" org.apache.tuscany.sca.node.NodeException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:157) [java] at myapp.MyClientImpl.main(MyClientImpl.java:50) [java] Caused by: org.apache.tuscany.sca.node.NodeException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:230) [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.(SCANodeImpl.java:136) [java] at org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54) [java] at org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:149) [java] ... 1 more [java] Caused by: org.apache.tuscany.sca.domain.DomainException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.createRuntime(SCADomainProxyImpl.java:299) [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.addNode(SCADomainProxyImpl.java:350) [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:225) [java] ... 4 more [java] Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:756) [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.createRuntime(SCADomainProxyImpl.java:256) [java] ... 6 more [java] Caused by: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.getFactory(DefaultProviderFactoryExtensionPoint.java:182) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:195) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider.(RuntimeSCAServiceBindingProvider.java:88) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createServiceBindingProvider(RuntimeSCABindingProviderFactory.java:60) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createServiceBindingProvider(RuntimeSCABindingProviderFactory.java:39) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:195) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addServiceBindingProvider(CompositeActivatorImpl.java:408) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:690) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:748) [java] ... 7 more [java] Caused by: java.lang.reflect.InvocationTargetException [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67) [java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [java] at java.lang.reflect.Constructor.newInstance(Constructor.java:522) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoi
Re: impl-bpel shutdown issue
Hi, I'm still seeing the SecurityException with 1.1 RC1 as the "java" task in ANT script still has the "fork=true" attribute commented out. Thanks, Raymond - Original Message - From: "Luciano Resende" <[EMAIL PROTECTED]> To: Sent: Wednesday, January 09, 2008 11:11 AM Subject: Re: impl-bpel shutdown issue After some investigation, it looks like the threads that are hanging are from ODE, when we deploy the BPEL process, and it's only happening on a non-maven environment. For now, i'll add an ugly workaround for our 1.1 release on the sample application, to do a System.exit(0) and work with the ODE guys to provide a solution for the thread issue. Thoughts On Jan 8, 2008 4:17 PM, Luciano Resende <[EMAIL PROTECTED]> wrote: Looks like we have the thread pool and derby with some hanging threads, based on this thread dump Full thread dump Java HotSpot(TM) Client VM (1.5.0_11-b03 mixed mode): "DestroyJavaVM" prio=6 tid=0x0003ca68 nid=0x1554 waiting on condition [0x..0x0007fae8] "pool-3-thread-1" prio=6 tid=0x0b4249d0 nid=0x1958 waiting on condition [0x0cccf000..0x0cccfce8] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:772) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1087) at java.util.concurrent.SynchronousQueue$Node.waitForPut(SynchronousQueue.java:291) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:443) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:475) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674) at java.lang.Thread.run(Thread.java:595) "pool-2-thread-1" prio=6 tid=0x0b4a1e18 nid=0x1b00 waiting on condition [0x0bc8f000..0x0bc8fd68] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1767) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674) at java.lang.Thread.run(Thread.java:595) "Thread-2" daemon prio=6 tid=0x0b062d90 nid=0x1430 waiting on condition [0x0bc0f000..0x0bc0fa68] at java.lang.Thread.sleep(Native Method) at org.apache.geronimo.transaction.manager.TransactionTimer$CurrentTime.run(TransactionTimer.java:38) "derby.rawStoreDaemon" daemon prio=6 tid=0x0b7c4a18 nid=0x15c0 in Object.wait() [0x0bbcf000..0x0bbcfae8] at java.lang.Object.wait(Native Method) - waiting on <0x03194110> (a org.apache.derby.impl.services.daemon.BasicDaemon) at org.apache.derby.impl.services.daemon.BasicDaemon.rest(Unknown Source) - locked <0x03194110> (a org.apache.derby.impl.services.daemon.BasicDaemon) at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) "derby.antiGC" daemon prio=2 tid=0x0b7ad008 nid=0x194c in Object.wait() [0x0bb0f000..0x0bb0fb68] at java.lang.Object.wait(Native Method) - waiting on <0x031163e0> (a org.apache.derby.impl.services.monitor.AntiGC) at java.lang.Object.wait(Object.java:474) at org.apache.derby.impl.services.monitor.AntiGC.run(Unknown Source) - locked <0x031163e0> (a org.apache.derby.impl.services.monitor.AntiGC) at java.lang.Thread.run(Thread.java:595) "Timer-0" daemon prio=6 tid=0x0ad25168 nid=0x1fc4 in Object.wait() [0x0bacf000..0x0bacfbe8] at java.lang.Object.wait(Native Method) - waiting on <0x031127b0> (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:509) - locked <0x031127b0> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) "Low Memory Detector" daemon prio=6 tid=0x00aa6730 nid=0x1f40 runnable [0x..0x] "CompilerThread0" daemon prio=10 tid=0x00aa5460 nid=0x14dc waiting on condition [0x..0x0ac0fa48] "Signal Dispatcher" daemon prio=10 tid=0x00aa4860 nid=0x1b8c waiting on condition [0x..0x] "Finalizer" daemon prio=8 tid=0x00a90080 nid=0x1c5c in Object.wait() [0x0ab8f000..0x0ab8fa68] at java.lang.Object.wait(Native Method) - waiting on <0x02fc36e0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x02fc36e0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread
Re: store sample issues, was: Re: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1)
On Jan 11, 2008 10:55 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I just tried the store sample from the 1.1 RC1 binary distro. There are two > issues: > > 1) When I clicked on the "Add to Cart" buttion, I was prompted to type in > user id and password. It's not documented anywhere in the README. I had to > go back the tuscany-binding-feed source code to figure it out. There is a getting started pdf with the store sample, and an updated version is also available at : http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started+with+Tuscany It says : Note: When adding items for the first time you will be asked for userid and password by the browser. Enter "admin" for both. > > 2) The store sample is not working well with IE7. > "document.getElementById()" returns null on Line 50. It works with FireFox. > Support for IE was just added couple weeks ago, but from what you are reporting, I guess it works only in IE6. I didn't test in IE7 (didn't have it). Let me know if this is something we want to get fixed in R1.1 and I can investigate the issue. > Thanks, > Raymond > > - Original Message - > From: "Simon Laws" <[EMAIL PROTECTED]> > To: "tuscany-dev" > Sent: Thursday, January 10, 2008 7:25 AM > Subject: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1) > > > > Please review and vote on the 1.1 release artifacts of Tuscany SCA for > > Java. > > > > The SVN tag for the release is: > > https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC1/ > > > > The artifacts are available for review at: > > http://people.apache.org/~slaws/tuscany/1.1-RC1/ > > > > This includes the signed binary and source distributions, the RAT report, > > and the Maven staging repository. > > > > If you do find issues with the release candidate that you think need > > to be fixed and lead to a -1 please review and fix them in the 1.1 branch > > or raise jira's targeting the 1.1 release. > > > > Thanks, > > > > Simon > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
store sample issues, was: Re: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1)
Hi, I just tried the store sample from the 1.1 RC1 binary distro. There are two issues: 1) When I clicked on the "Add to Cart" buttion, I was prompted to type in user id and password. It's not documented anywhere in the README. I had to go back the tuscany-binding-feed source code to figure it out. 2) The store sample is not working well with IE7. "document.getElementById()" returns null on Line 50. It works with FireFox. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Thursday, January 10, 2008 7:25 AM Subject: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1) Please review and vote on the 1.1 release artifacts of Tuscany SCA for Java. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC1/ The artifacts are available for review at: http://people.apache.org/~slaws/tuscany/1.1-RC1/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. If you do find issues with the release candidate that you think need to be fixed and lead to a -1 please review and fix them in the 1.1 branch or raise jira's targeting the 1.1 release. Thanks, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Archiving Releases
On Fri, 2008-01-11 at 09:28 -0800, Luciano Resende wrote: > Hey Robert > >With the current distribution setup, we use the apache http logs to > count the number of downloads of each tuscany releases. With this new > setup, will we still be able to get the download counts from the http > logs ? for the old releases, possibly but the details may change new releases will use the mirrors so counting releases this way will no longer be possible. i've heard that some projects use something like google analytics to count mirrored downloads. - robert signature.asc Description: This is a digitally signed message part
[jira] Reopened: (TUSCANY-1962) WSDL2JAVA Test not valid - generating code that is not checked
[ https://issues.apache.org/jira/browse/TUSCANY-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reopened TUSCANY-1962: -- Reopening based on discussions on the following thread : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg26939.html Suggestion from Sebastien is to have : - Unit tests of the wsdl2java logic that check the expected output (without compiling it or trying to use the generated code). - Integration tests that compile the generated code. - Integration tests that compile and use the generated code at runtime (start with wsdls on both ends of a wire, gen the java, compile, execute an end to end interaction). > WSDL2JAVA Test not valid - generating code that is not checked > -- > > Key: TUSCANY-1962 > URL: https://issues.apache.org/jira/browse/TUSCANY-1962 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-SCA-1.1 > Environment: All >Reporter: Mike Edwards >Priority: Minor > Fix For: Java-SCA-Next > > > The WSDL2Java tools has a testcase WSDL2JavaGeneratorTestcase that is an > invalid testcase. > This testcase runs the WSDL2Java tool and generates some output Java classes > based on an input WSDL document. The files get placed into the > target/wsdl2java-source directory. The current testcase only generates these > files - it does not check that their contents are meaningful or correct. In > reality, the generated code has problems: > a) The code refers to SDO classes that are not generated by the testcase and > which are not available in any obvious location. As a result the code does > not compile. > b) The generated code does not have import statements for the SDO classes > that are used. Instead, the classes are used with full paths on each > declaration. At the very least this is unacceptable style and it should be > changed. > There is no attempt in the test to check that the generated code conforms to > some expected output. The test MUST be extended to do this if it is to be of > any real value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-1957) Domain controller incorrectly loading contributions added to nodes.
On Jan 9, 2008 10:44 PM, Jean-Sebastien Delfino (JIRA) < tuscany-dev@ws.apache.org> wrote: > Domain controller incorrectly loading contributions added to nodes. > --- > > Key: TUSCANY-1957 > URL: https://issues.apache.org/jira/browse/TUSCANY-1957 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-SCA-1.1 >Reporter: Jean-Sebastien Delfino > Fix For: Java-SCA-Next > > > Very weird behavior of the domain controller, which seems to want to load > contributions in its memory as they are added to nodes running on different > JVMs. I must admit I'm puzzled... > > To reproduce the problem use SVN revision r610601 of the trunk, use the > tutorial modules: > - from the cloud module start LaunchCloud > - from the store-db module start LaunchStoreDB > > Here's the output from LaunchCloud showing that it's incorrectly trying to > load the store-db contribution (as it's added to the node in LaunchStoreDB) > and BTW failing to do load it properly (see all the composite builder > problems showing in the output). > > Starting ... > Jan 9, 2008 1:43:14 PM org.apache.tuscany.sca.domain.impl.SCADomainImplinit > INFO: Domain management configured from > file:/home/delfinoj/Tuscany/apache-repos/java/sca/modules/domain-impl/target/classes/ > Jan 9, 2008 1:43:19 PM > org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:9998/domain/* > Jan 9, 2008 1:43:19 PM > org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:9998/SCADomainManagerComponent/SCADomainManagerService/* > Jan 9, 2008 1:43:19 PM > org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:9998/SCADomainManagerComponent/SCADomainManagerService > Jan 9, 2008 1:43:19 PM > org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:9998/SCADomain/scaDomain.js > Jan 9, 2008 1:43:19 PM > org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:9998/SCADomainManagerComponent/SCADomainEventService > Domain controller ready for big business !!! > Jan 9, 2008 1:43:19 PM > org.apache.tuscany.sca.http.jetty.JettyServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:9998/SCADomainManagerComponent/SCADomainAPIService > Jan 9, 2008 1:43:20 PM > org.apache.tuscany.sca.domain.impl.SCADomainImplregisterNode > INFO: Registered node: http://localhost:8200/cloud at endpoint > http://localhost:8200/cloud > Jan 9, 2008 1:43:20 PM > org.apache.tuscany.sca.node.impl.SCADomainProxyImplcreateRuntime > INFO: Domain management configured from > file:/home/delfinoj/Tuscany/apache-repos/java/sca/modules/node-impl/target/classes/ > Jan 9, 2008 1:43:22 PM org.apache.catalina.core.StandardEngine start > INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 > Jan 9, 2008 1:43:22 PM > org.apache.catalina.startup.ContextConfigdefaultWebConfig > INFO: No default web.xml > Jan 9, 2008 1:43:22 PM org.apache.catalina.startup.DigesterFactoryregister > WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd > Jan 9, 2008 1:43:22 PM org.apache.catalina.startup.DigesterFactoryregister > WARNING: Could not get url for > /javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd > Jan 9, 2008 1:43:23 PM org.apache.coyote.http11.Http11Protocol init > INFO: Initializing Coyote HTTP/1.1 on http-8200 > Jan 9, 2008 1:43:23 PM org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-8200 > Jan 9, 2008 1:43:23 PM > org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:8200/cloud/SCADomainEventServiceProxyComponent > Jan 9, 2008 1:43:23 PM > org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:8200/cloud/SCADomainAPIServiceProxyComponent > Jan 9, 2008 1:43:23 PM > org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:8200/cloud/SCANodeManagerComponent/SCANodeManagerService > Jan 9, 2008 1:43:23 PM > org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:8200/cloud/SCANodeManagerComponent/ComponentManagerService/* > Jan 9, 2008 1:43:23 PM > org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletMapping > INFO: Added Servlet mapping: > http://delfinoj60.burlingame.ibm.com:8200/cloud/SCANodeManagerComponent/ComponentManagerService > Jan 9, 2008 1:43:23 PM > org.apache.tuscany.sca.ht
Re: [NOTICE] Archiving Releases
Hey Robert With the current distribution setup, we use the apache http logs to count the number of downloads of each tuscany releases. With this new setup, will we still be able to get the download counts from the http logs ? On Jan 9, 2008 3:04 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > incubator releases now need to be distributed using the standard apache > system. new releases will need to be mirrored and uploaded to > www.apache.org/dist. see > http://incubator.apache.org/guides/releasemanagement.html#release-distribution > for more details. please post questions about the new process on general. > > as part of this process, i'm archiving all existings releases from > people.apache.org to archive.apache.org. redirects will ensure that > existing URLs do not need to be changed. > > i see that tuscany has releases in > people.apache.org/dist/incubator/tuscany. unless anyone jumps in, i plan > to archive these in the near future. i'll stay subscribed for to this > list till sunday 13th so if anyone has any questions about the archiving > process please reply to this email. > > - robert > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA runtimes
On Jan 10, 2008 11:13 PM, Simon Nash <[EMAIL PROTECTED]> wrote: My earlier idea which seems to have got a little lost in the debate > was for the wwebapp to contain a minimal Tuscany bootstrapper that > pulls in the needed jars from wherever the full runtime is installed. > So webapps wouldn't contain the whole Tuscany runtime, but would use > jars from a runtime installed somewhere that the webapp bootstrapper > could find. > Is that very similar to what we had back in M2 with the way extensions and dependencies got pulled in at runtime by Maven, or am misunderstanding what you're suggesting? ...ant
Re: svn commit: r611046 - /incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
Mike Edwards wrote: Folks, The real problem here is that the testcase for wsdl2java is cr*p. I'll raise a JIRA to track this. Basically, the testcase runs the wsdl2java tool a number of times and produces some output. Nothing wrong with that, except that all that is being tested is that the tool code can be invoked without getting an exception. There is *no* checking that what is produced by the tool makes any sense at all. And in fact, the code produced DOESN'T make any sense - try compiling it by hand. So, this test needs changing and extending. There must be a test done on the output code itself - ideally there should be an "expected output" which is checked against the actual output. I agree, I'd suggest the following: - Unit tests of the wsdl2java logic that check the expected output (without compiling it or trying to use the generated code). - Integration tests that compile the generated code. - Integration tests that compile and use the generated code at runtime (start with wsdls on both ends of a wire, gen the java, compile, execute an end to end interaction). One other point is that the generated code looks VERY poor - it's Java, but not as you'd write it. For an SDO used by a method, for example, instead of an import statement for the SDO class, followed by a variable declaration using the class, the full path to the class is used on every occasion it's referenced (YUK ). Agreed but needs to be done carefully, speaking after years of tooling development, I'd suggest to be very very careful when generating imports and ensure that they won't cause compile errors in conjunction with the user code available around the generated code. I'll be there to help test it after you turn the qualified references into imports. :) This may require changes in: - our WSDL2Java tool - the Axis2 WSDL2Java that we use - the SDO generator Worse, the test doesn't actually generate these SDO classes - hence the code won't compile since they can't be found That would be part of the integration test. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r611046 - /incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
Comments inline. Simon Mike Edwards wrote: Folks, The real problem here is that the testcase for wsdl2java is cr*p. I'll raise a JIRA to track this. Basically, the testcase runs the wsdl2java tool a number of times and produces some output. Nothing wrong with that, except that all that is being tested is that the tool code can be invoked without getting an exception. There is *no* checking that what is produced by the tool makes any sense at all. And in fact, the code produced DOESN'T make any sense - try compiling it by hand. So, this test needs changing and extending. There must be a test done on the output code itself - ideally there should be an "expected output" which is checked against the actual output. One other point is that the generated code looks VERY poor - it's Java, but not as you'd write it. For an SDO used by a method, for example, instead of an import statement for the SDO class, followed by a variable declaration using the class, the full path to the class is used on every occasion it's referenced (YUK ). Worse, the test doesn't actually generate these SDO classes - hence the code won't compile since they can't be found These are very good points. I'd like to add one more observation. I have never been very keen on test cases that generate and compare their output against a "reference" version of what is expected, rather than actually running the generated output as part of some functional test. The problem is that when small details of the output change, the comparison fails, even when the output is still good. In my past experience, this happens more often than the output changing from good to bad. So the comparison gives more "false positives" than "true positives", which is not very efficient. Also, the fix to a "false positive" failure is usually to regenerate the reference output using the new generator, and unless there's some way to actually test the new reference output, there's a chance that the new reference output could have bugs. Testing the generated output in some functional way is a bit more work initially, but this work is more than repaid in the longer term by eliminating the "false positives" problem. Simon Yours, Mike. Simon Laws wrote: On Jan 11, 2008 4:50 AM, <[EMAIL PROTECTED]> wrote: Author: lresende Date: Thu Jan 10 20:50:35 2008 New Revision: 611046 URL: http://svn.apache.org/viewvc?rev=611046&view=rev Log: TUSCANY-1936 Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tools/wsdl2java/pom.xml?rev=611046&r1=611045&r2=611046&view=diff == --- incubator/tuscany/java/sca/tools/wsdl2java/pom.xml (original) +++ incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Thu Jan 10 20:50:35 2008 @@ -191,26 +191,6 @@ -org.codehaus.mojo -build-helper-maven-plugin -1.0 - - -add-test-source -generate-sources - -add-test-source - - - -target/sdo-source - target/wsdl2java-source - - - - - - org.apache.tuscany.sdo tuscany-sdo-plugin 1.0-incubating-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano It looks like this means that we are no longer trying to compile the source code that is generated as part of the generator test. I'm a little concerned that this means that we are not checking that the generator generates valid output. Looking at the tests though it doesn't seem that it does explicit checks anyhow. So how about we build on your change here and do a textual comparison of what was generated against what was expected to be generated? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r611046 - /incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
I didn't see this discussion before I added comments to the JIRA 1962. Let me try to add some comments in-line. [1] https://issues.apache.org/jira/browse/TUSCANY-1962 On Jan 11, 2008 6:09 AM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > The real problem here is that the testcase for wsdl2java is cr*p. I'll > raise a JIRA to track this. > > Basically, the testcase runs the wsdl2java tool a number of times and > produces some output. Nothing wrong with that, except that all that is > being tested is that the tool code can be invoked without getting an > exception. > Yes, I guess this was exactly the purpose of the testcase, the full blow test, where all the java artifacts get generated and compiled it's done on wsdl2java iTest. > There is *no* checking that what is produced by the tool makes any sense > at all. And in fact, the code produced DOESN'T make any sense - try > compiling it by hand. > > So, this test needs changing and extending. There must be a test done > on the output code itself - ideally there should be an "expected output" > which is checked against the actual output. > I guess the tests we have don't check for "expected output", but try to compile it (under iTest). > One other point is that the generated code looks VERY poor - it's Java, > but not as you'd write it. For an SDO used by a method, for example, > instead of an import statement for the SDO class, followed by a variable > declaration using the class, the full path to the class is used on every > occasion it's referenced (YUK ). Worse, the test doesn't actually > generate these SDO classes - hence the code won't compile since they > can't be found > I guess this is something we could improve on the tools. My guess is that it has been like this for a while. > > Yours, Mike. > > > Simon Laws wrote: > > On Jan 11, 2008 4:50 AM, <[EMAIL PROTECTED]> wrote: > > > >> Author: lresende > >> Date: Thu Jan 10 20:50:35 2008 > >> New Revision: 611046 > >> > >> URL: http://svn.apache.org/viewvc?rev=611046&view=rev > >> Log: > >> TUSCANY-1936 > >> > >> Modified: > >>incubator/tuscany/java/sca/tools/wsdl2java/pom.xml > >> > >> Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml > >> URL: > >> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tools/wsdl2java/pom.xml?rev=611046&r1=611045&r2=611046&view=diff > >> > >> == > >> --- incubator/tuscany/java/sca/tools/wsdl2java/pom.xml (original) > >> +++ incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Thu Jan 10 20:50:35 > >> 2008 > >> @@ -191,26 +191,6 @@ > >> > >> > >> > >> -org.codehaus.mojo > >> -build-helper-maven-plugin > >> -1.0 > >> - > >> - > >> -add-test-source > >> -generate-sources > >> - > >> -add-test-source > >> - > >> - > >> - > >> -target/sdo-source > >> -target/wsdl2java-source > >> - > >> - > >> - > >> - > >> - > >> - > >> org.apache.tuscany.sdo > >> tuscany-sdo-plugin > >> 1.0-incubating-SNAPSHOT > >> > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> Hi Luciano > > > > It looks like this means that we are no longer trying to compile the source > > code that is generated as part of the generator test. I'm a little concerned > > that this means that we are not checking that the generator generates valid > > output. Looking at the tests though it doesn't seem that it does explicit > > checks anyhow. So how about we build on your change here and do a textual > > comparison of what was generated against what was expected to be generated? > > > > Simon > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Account Request - Rajini Sivaram - Tuscany (incubating)
Dear root, Please create an id for Rajini Sivaram on the Tuscany project under Incubation. Preferred userid: rsivaram Full name: Rajini Sivaram Forwarding email address:[EMAIL PROTECTED] Requested Karma for: ws-tuscany ICLA is on file. Votes: tuscany-private, Nov 8, Message-ID: < [EMAIL PROTECTED]> incubator-private, Nov 19, Message-ID: < [EMAIL PROTECTED]> Many thanks, ...ant
[jira] Resolved: (TUSCANY-1962) WSDL2JAVA Test not valid - generating code that is not checked
[ https://issues.apache.org/jira/browse/TUSCANY-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1962. -- Resolution: Invalid The wsdl2java test case only test that the wsdl tool works ok and can process and generate the java artifacts from wsdl. The full integration test, that generates and compile the generated artifacts is available in iTest\wsdl2java. Please reopen the JIRA if you disagree with the way it's structured today. > WSDL2JAVA Test not valid - generating code that is not checked > -- > > Key: TUSCANY-1962 > URL: https://issues.apache.org/jira/browse/TUSCANY-1962 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-SCA-1.1 > Environment: All >Reporter: Mike Edwards >Priority: Minor > Fix For: Java-SCA-Next > > > The WSDL2Java tools has a testcase WSDL2JavaGeneratorTestcase that is an > invalid testcase. > This testcase runs the WSDL2Java tool and generates some output Java classes > based on an input WSDL document. The files get placed into the > target/wsdl2java-source directory. The current testcase only generates these > files - it does not check that their contents are meaningful or correct. In > reality, the generated code has problems: > a) The code refers to SDO classes that are not generated by the testcase and > which are not available in any obvious location. As a result the code does > not compile. > b) The generated code does not have import statements for the SDO classes > that are used. Instead, the classes are used with full paths on each > declaration. At the very least this is unacceptable style and it should be > changed. > There is no attempt in the test to check that the generated code conforms to > some expected output. The test MUST be extended to do this if it is to be of > any real value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1952) Domain broken after stopping+starting a node
[ https://issues.apache.org/jira/browse/TUSCANY-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-1952: --- Assignee: Simon Laws > Domain broken after stopping+starting a node > - > > Key: TUSCANY-1952 > URL: https://issues.apache.org/jira/browse/TUSCANY-1952 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-1.1 >Reporter: Jean-Sebastien Delfino >Assignee: Simon Laws > Fix For: Java-SCA-Next > > > The SCA domain seems to be unusable after a node is stopped then started > again. > Steps to reproduce the problem: > 1. From the tutorial/cloud module start LaunchCloud.java, it'll start some > services and a domain controller. > 2. From the tutorial/store module start LaunchStore.java, it'll start the > store composite. > 3. Point your Web browser to http://localhost:8100/ui/store.html your should > see the store UI showing a catalog of fruits > 4. Stop LaunchStore by pressing Ctrl+C > 5. Do steps 2 and 3 again, you won't see the catalog anymore. None of the > services seem to properly register/resolve in the domain anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1962) WSDL2JAVA Test not valid - generating code that is not checked
WSDL2JAVA Test not valid - generating code that is not checked -- Key: TUSCANY-1962 URL: https://issues.apache.org/jira/browse/TUSCANY-1962 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.1 Environment: All Reporter: Mike Edwards Priority: Minor Fix For: Java-SCA-Next The WSDL2Java tools has a testcase WSDL2JavaGeneratorTestcase that is an invalid testcase. This testcase runs the WSDL2Java tool and generates some output Java classes based on an input WSDL document. The files get placed into the target/wsdl2java-source directory. The current testcase only generates these files - it does not check that their contents are meaningful or correct. In reality, the generated code has problems: a) The code refers to SDO classes that are not generated by the testcase and which are not available in any obvious location. As a result the code does not compile. b) The generated code does not have import statements for the SDO classes that are used. Instead, the classes are used with full paths on each declaration. At the very least this is unacceptable style and it should be changed. There is no attempt in the test to check that the generated code conforms to some expected output. The test MUST be extended to do this if it is to be of any real value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r611046 - /incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
Folks, The real problem here is that the testcase for wsdl2java is cr*p. I'll raise a JIRA to track this. Basically, the testcase runs the wsdl2java tool a number of times and produces some output. Nothing wrong with that, except that all that is being tested is that the tool code can be invoked without getting an exception. There is *no* checking that what is produced by the tool makes any sense at all. And in fact, the code produced DOESN'T make any sense - try compiling it by hand. So, this test needs changing and extending. There must be a test done on the output code itself - ideally there should be an "expected output" which is checked against the actual output. One other point is that the generated code looks VERY poor - it's Java, but not as you'd write it. For an SDO used by a method, for example, instead of an import statement for the SDO class, followed by a variable declaration using the class, the full path to the class is used on every occasion it's referenced (YUK ). Worse, the test doesn't actually generate these SDO classes - hence the code won't compile since they can't be found Yours, Mike. Simon Laws wrote: On Jan 11, 2008 4:50 AM, <[EMAIL PROTECTED]> wrote: Author: lresende Date: Thu Jan 10 20:50:35 2008 New Revision: 611046 URL: http://svn.apache.org/viewvc?rev=611046&view=rev Log: TUSCANY-1936 Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tools/wsdl2java/pom.xml?rev=611046&r1=611045&r2=611046&view=diff == --- incubator/tuscany/java/sca/tools/wsdl2java/pom.xml (original) +++ incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Thu Jan 10 20:50:35 2008 @@ -191,26 +191,6 @@ -org.codehaus.mojo -build-helper-maven-plugin -1.0 - - -add-test-source -generate-sources - -add-test-source - - - -target/sdo-source -target/wsdl2java-source - - - - - - org.apache.tuscany.sdo tuscany-sdo-plugin 1.0-incubating-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano It looks like this means that we are no longer trying to compile the source code that is generated as part of the generator test. I'm a little concerned that this means that we are not checking that the generator generates valid output. Looking at the tests though it doesn't seem that it does explicit checks anyhow. So how about we build on your change here and do a textual comparison of what was generated against what was expected to be generated? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO] SDO generator
Amita, that sounds great thanks. It would be good to have more people understanding this stuff. I'm happy with javajet setup to help if you need it. There's an FAQ in the SDO Java part of the website for getting started that you may have already found. Kelvin. On 11/01/2008, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > Hi, > I was just scanning through SDO for the things I was trying in 2007 and > came > across JIRA-1483. David has already > provided the patch and test xsd. I would like to give it a try using > javajet > and apply it. > > Old discussion - > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26269.html > Suggestions? > Regards, > Amita >
Re: [Java SDO] What should we be attacking?
Hi Rajini, thanks for this. Our problem is that because the SDO spec says we must support Java 1.4, and versions of EMF from 2.3 and beyond require Java 5, we are blocked from advancing beyond EMF 2.2.3. Your Bugzilla doesn't mention the version of EMF, but sadly I'm pretty sure there's no scope for us getting a fix on top of 2.2.3, so I think we will have to go on with the solution you have provided indefinitely. Kelvin. On 11/01/2008, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > Kelvin, > > Following on from the notes from John Conlon ( > > http://www.eclipse.org/newsportal/article.php?id=29577&group=eclipse.tools.emf#29577 > ) > and Jeff McAffer ( > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00673.html), I have > opened an EMF Bugzilla ( > https://bugs.eclipse.org/bugs/show_bug.cgi?id=215010) > to remove the dependency of EMF on the Eclipse runtime. > > You could apply the patch as is, and remove the code that modifies the > manifest entries in the EMF jars when the issue is resolved. > > > Thank you... > > Regards, > > Rajini > > > On 1/9/08, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > Rajini, I think you are right. I'll apply the patch as is, and we > can > > tackle the issue of Felix as a community if and when specific the need > > arises. > > Regards, Kelvin. > > > > On 08/01/2008, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > > > > > Kelvin, > > > > > > http://issues.apache.org/jira/browse/TUSCANY-1293 contains the patch > > that > > > enables SDO to run under OSGi. At the moment, the OSGi manifest > entries > > in > > > EMF jars and the OSGi bundle activator have a dependency on Eclipse > > > runtime > > > (and hence on Equinox). Since Tuscany SCA is tested under Apache Felix > > > OSGi > > > runtime (and Felix is easily available from a public maven > repository), > > > the > > > tests in the patch for TUSCANY-1293 are also run under Apache Felix. > > These > > > tests modify the manifest entries of the EMF jars before installing > them > > > under Felix. The patch should work for Equinox without any changes to > > EMF. > > > > > > It would be good if a cleaner solution could be implemented for SDO to > > run > > > under Felix without modifying EMF. This is the response I got from Ed > > > Merks > > > on the EMF newsgroup: > > > > > > > > > *This question probably really should be directed to the Apache > > folks. At > > > Eclipse I can just provide a version intended to run with the Equinox > > > runtime so the Tuscany folks probably ought to make a version that > works > > > well with Felix. Have you asked them about this? I'd be curious what > > > they > > > say... > > > * > > > > > > For now, it may be best to apply the patch which enables SDO to run > > under > > > Equinox without modifying EMF, and with Felix with modified EMF jars. > If > > > there is a wider interest in running SDO under Felix, an alternative > may > > > be > > > needed. Redistributing EMF with SDO with different manifest entries > > > doesn't > > > seem a good option. > > > > > > Suggestions? > > > > > > > > > > > > Thank you... > > > > > > Regards, > > > > > > Rajini > > > > > > > > > On 1/4/08, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > > Hi Rajini, > > > > Now that the New Year has arrived, do you think you'll be able to > > take > > > a > > > > look at this? > > > > Thanks, Kelvin. > > > > > > > > > > > > On 11/12/2007, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Kelvin, > > > > > > > > > > I am busy until Christmas with the SCA-OSGi work, but I will try > and > > > > look > > > > > at > > > > > the OSGi-enablement of SDO early in the new year. At the moment I > > > can't > > > > > promise anything, but from the notes that you produced about > > > > classloading, > > > > > and the code and comments from Bert, I think there is enough > > > information > > > > > to > > > > > prototype an implementation. I will update the list in the new > year > > > > after > > > > > I > > > > > take a more detailed look. > > > > > > > > > > > > > > > Thank you... > > > > > > > > > > Regards, > > > > > > > > > > Rajini > > > > > > > > > > On 12/10/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I'd kind of hoped to be in a position to have a release before > the > > > end > > > > > of > > > > > > the year. The JIRA query [1] shows that we have 34 JIRAs in > > resolved > > > > > state > > > > > > with a fix version of SDO-Next, but I think it would be good to > > get > > > > the > > > > > > OSGi > > > > > > issues dealt with before a release. Thoughts? > > > > > > > > > > > > Kelvin. > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=5&status=6&component=12311542&component=12310660&component=12310973&component=12310802&fixfor=12312262&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/
Re: [Java SDO] What should we be attacking?
Kelvin, Following on from the notes from John Conlon ( http://www.eclipse.org/newsportal/article.php?id=29577&group=eclipse.tools.emf#29577) and Jeff McAffer ( http://www.mail-archive.com/[EMAIL PROTECTED]/msg00673.html), I have opened an EMF Bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=215010) to remove the dependency of EMF on the Eclipse runtime. You could apply the patch as is, and remove the code that modifies the manifest entries in the EMF jars when the issue is resolved. Thank you... Regards, Rajini On 1/9/08, kelvin goodson <[EMAIL PROTECTED]> wrote: > > Rajini, I think you are right. I'll apply the patch as is, and we can > tackle the issue of Felix as a community if and when specific the need > arises. > Regards, Kelvin. > > On 08/01/2008, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > > > Kelvin, > > > > http://issues.apache.org/jira/browse/TUSCANY-1293 contains the patch > that > > enables SDO to run under OSGi. At the moment, the OSGi manifest entries > in > > EMF jars and the OSGi bundle activator have a dependency on Eclipse > > runtime > > (and hence on Equinox). Since Tuscany SCA is tested under Apache Felix > > OSGi > > runtime (and Felix is easily available from a public maven repository), > > the > > tests in the patch for TUSCANY-1293 are also run under Apache Felix. > These > > tests modify the manifest entries of the EMF jars before installing them > > under Felix. The patch should work for Equinox without any changes to > EMF. > > > > It would be good if a cleaner solution could be implemented for SDO to > run > > under Felix without modifying EMF. This is the response I got from Ed > > Merks > > on the EMF newsgroup: > > > > > > *This question probably really should be directed to the Apache > folks. At > > Eclipse I can just provide a version intended to run with the Equinox > > runtime so the Tuscany folks probably ought to make a version that works > > well with Felix. Have you asked them about this? I'd be curious what > > they > > say... > > * > > > > For now, it may be best to apply the patch which enables SDO to run > under > > Equinox without modifying EMF, and with Felix with modified EMF jars. If > > there is a wider interest in running SDO under Felix, an alternative may > > be > > needed. Redistributing EMF with SDO with different manifest entries > > doesn't > > seem a good option. > > > > Suggestions? > > > > > > > > Thank you... > > > > Regards, > > > > Rajini > > > > > > On 1/4/08, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > Hi Rajini, > > > Now that the New Year has arrived, do you think you'll be able to > take > > a > > > look at this? > > > Thanks, Kelvin. > > > > > > > > > On 11/12/2007, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > > > > > > > Kelvin, > > > > > > > > I am busy until Christmas with the SCA-OSGi work, but I will try and > > > look > > > > at > > > > the OSGi-enablement of SDO early in the new year. At the moment I > > can't > > > > promise anything, but from the notes that you produced about > > > classloading, > > > > and the code and comments from Bert, I think there is enough > > information > > > > to > > > > prototype an implementation. I will update the list in the new year > > > after > > > > I > > > > take a more detailed look. > > > > > > > > > > > > Thank you... > > > > > > > > Regards, > > > > > > > > Rajini > > > > > > > > On 12/10/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I'd kind of hoped to be in a position to have a release before the > > end > > > > of > > > > > the year. The JIRA query [1] shows that we have 34 JIRAs in > resolved > > > > state > > > > > with a fix version of SDO-Next, but I think it would be good to > get > > > the > > > > > OSGi > > > > > issues dealt with before a release. Thoughts? > > > > > > > > > > Kelvin. > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=5&status=6&component=12311542&component=12310660&component=12310973&component=12310802&fixfor=12312262&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC > > > > > > > > > > > > > > > On 29/11/2007, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > David, > > > > > >thanks for the fixes. I'll apply them as soon as I can get > to > > > > > > them. I've been away unwell for most of the last weeks so I > have > > > some > > > > > > catching up to do. Anything you can do to reduce the JIRA > backlog > > > > > > further would be great, thanks. > > > > > > > > > > > > Kelvin. > > > > > > > > > > > > On 29/11/2007, David Adcox <[EMAIL PROTECTED]> wrote: > > > > > > > Kelvin, > > > > > > > > > > > > > > I have some free cycles, so I'd like to help knock some things > > off > > > > > > > this list for you. I've gone ahead and contributed a patch > for > > > > 1483. > > > > > > > I'll address 1545
[SDO] SDO generator
Hi, I was just scanning through SDO for the things I was trying in 2007 and came across JIRA-1483. David has already provided the patch and test xsd. I would like to give it a try using javajet and apply it. Old discussion - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26269.html Suggestions? Regards, Amita
[jira] Closed: (TUSCANY-1793) calculator-script displays message about package cache dir
[ https://issues.apache.org/jira/browse/TUSCANY-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-1793. --- Resolution: Duplicate What that should have said was This issue has been re-raised at TUSCANY-1950 and ant has added some explanation so I'm closing this version of it > calculator-script displays message about package cache dir > -- > > Key: TUSCANY-1793 > URL: https://issues.apache.org/jira/browse/TUSCANY-1793 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-SCA-1.0 > Environment: Windows XP >Reporter: Simon Nash >Priority: Minor > Fix For: Java-SCA-1.1 > > > When I run the calculator-script sample, I get the following output: > run: > [java] 3 + 2=5.0 > [java] 3 - 2=1.0 > [java] *sys-package-mgr*: can't create package cache dir, > 'H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\lib\jython-2.2.jar\cachedir\packages' > [java] 3 * 2=6.0 > [java] 3 / 2=1.5 > The warning message about "package cache dir" is not shown in the README > sample output. Do I have a setup problem that is causing me to get this > message, or is it always displayed? If the former, then the README should > contain instructions on how to avoid this. If the latter, then the README > sample output should be updated to include this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1793) calculator-script displays message about package cache dir
[ https://issues.apache.org/jira/browse/TUSCANY-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reopened TUSCANY-1793: - > calculator-script displays message about package cache dir > -- > > Key: TUSCANY-1793 > URL: https://issues.apache.org/jira/browse/TUSCANY-1793 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-SCA-1.0 > Environment: Windows XP >Reporter: Simon Nash >Priority: Minor > Fix For: Java-SCA-1.1 > > > When I run the calculator-script sample, I get the following output: > run: > [java] 3 + 2=5.0 > [java] 3 - 2=1.0 > [java] *sys-package-mgr*: can't create package cache dir, > 'H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\lib\jython-2.2.jar\cachedir\packages' > [java] 3 * 2=6.0 > [java] 3 / 2=1.5 > The warning message about "package cache dir" is not shown in the README > sample output. Do I have a setup problem that is causing me to get this > message, or is it always displayed? If the former, then the README should > contain instructions on how to avoid this. If the latter, then the README > sample output should be updated to include this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1793) calculator-script displays message about package cache dir
[ https://issues.apache.org/jira/browse/TUSCANY-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-1793. --- Resolution: Fixed This issue has been re-raised at TUSCANY-1793 and ant has added some explanation so I'm closing this version of it > calculator-script displays message about package cache dir > -- > > Key: TUSCANY-1793 > URL: https://issues.apache.org/jira/browse/TUSCANY-1793 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-SCA-1.0 > Environment: Windows XP >Reporter: Simon Nash >Priority: Minor > Fix For: Java-SCA-1.1 > > > When I run the calculator-script sample, I get the following output: > run: > [java] 3 + 2=5.0 > [java] 3 - 2=1.0 > [java] *sys-package-mgr*: can't create package cache dir, > 'H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\lib\jython-2.2.jar\cachedir\packages' > [java] 3 * 2=6.0 > [java] 3 / 2=1.5 > The warning message about "package cache dir" is not shown in the README > sample output. Do I have a setup problem that is causing me to get this > message, or is it always displayed? If the former, then the README should > contain instructions on how to avoid this. If the latter, then the README > sample output should be updated to include this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r611046 - /incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
On Jan 11, 2008 4:50 AM, <[EMAIL PROTECTED]> wrote: > Author: lresende > Date: Thu Jan 10 20:50:35 2008 > New Revision: 611046 > > URL: http://svn.apache.org/viewvc?rev=611046&view=rev > Log: > TUSCANY-1936 > > Modified: >incubator/tuscany/java/sca/tools/wsdl2java/pom.xml > > Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml > URL: > http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tools/wsdl2java/pom.xml?rev=611046&r1=611045&r2=611046&view=diff > > == > --- incubator/tuscany/java/sca/tools/wsdl2java/pom.xml (original) > +++ incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Thu Jan 10 20:50:35 > 2008 > @@ -191,26 +191,6 @@ > > > > -org.codehaus.mojo > -build-helper-maven-plugin > -1.0 > - > - > -add-test-source > -generate-sources > - > -add-test-source > - > - > - > -target/sdo-source > -target/wsdl2java-source > - > - > - > - > - > - > org.apache.tuscany.sdo > tuscany-sdo-plugin > 1.0-incubating-SNAPSHOT > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Hi Luciano It looks like this means that we are no longer trying to compile the source code that is generated as part of the generator test. I'm a little concerned that this means that we are not checking that the generator generates valid output. Looking at the tests though it doesn't seem that it does explicit checks anyhow. So how about we build on your change here and do a textual comparison of what was generated against what was expected to be generated? Simon
