[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=611046view=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=611046r1=611045r2=611046view=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 @@ build plugins plugin -groupIdorg.codehaus.mojo/groupId -artifactIdbuild-helper-maven-plugin/artifactId -version1.0/version -executions -execution -idadd-test-source/id -phasegenerate-sources/phase -goals -goaladd-test-source/goal -/goals -configuration -sources -sourcetarget/sdo-source/source -sourcetarget/wsdl2java-source/source -/sources -/configuration -/execution -/executions -/plugin -plugin groupIdorg.apache.tuscany.sdo/groupId artifactIdtuscany-sdo-plugin/artifactId version1.0-incubating-SNAPSHOT/version - 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
[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
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=29577group=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=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/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,
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=611046view=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=611046r1=611045r2=611046view=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 @@ build plugins plugin -groupIdorg.codehaus.mojo/groupId -artifactIdbuild-helper-maven-plugin/artifactId -version1.0/version -executions -execution -idadd-test-source/id -phasegenerate-sources/phase -goals -goaladd-test-source/goal -/goals -configuration -sources -sourcetarget/sdo-source/source -sourcetarget/wsdl2java-source/source -/sources -/configuration -/execution -/executions -/plugin -plugin groupIdorg.apache.tuscany.sdo/groupId artifactIdtuscany-sdo-plugin/artifactId version1.0-incubating-SNAPSHOT/version - 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: 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=611046view=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=611046r1=611045r2=611046view=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 @@ build plugins plugin -groupIdorg.codehaus.mojo/groupId -artifactIdbuild-helper-maven-plugin/artifactId -version1.0/version -executions -execution -idadd-test-source/id -phasegenerate-sources/phase -goals -goaladd-test-source/goal -/goals -configuration -sources -sourcetarget/sdo-source/source -sourcetarget/wsdl2java-source/source -/sources -/configuration -/execution -/executions -/plugin -plugin groupIdorg.apache.tuscany.sdo/groupId artifactIdtuscany-sdo-plugin/artifactId version1.0-incubating-SNAPSHOT/version - 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]
[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: SCA runtimes
On Jan 10, 2008 11:13 PM, Simon Nash [EMAIL PROTECTED] wrote: snip 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
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]
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=611046view=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=611046r1=611045r2=611046view=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 @@ build plugins plugin -groupIdorg.codehaus.mojo/groupId -artifactIdbuild-helper-maven-plugin/artifactId -version1.0/version -executions -execution -idadd-test-source/id -phasegenerate-sources/phase -goals -goaladd-test-source/goal -/goals -configuration -sources -sourcetarget/sdo-source/source - sourcetarget/wsdl2java-source/source -/sources -/configuration -/execution -/executions -/plugin -plugin groupIdorg.apache.tuscany.sdo/groupId artifactIdtuscany-sdo-plugin/artifactId version1.0-incubating-SNAPSHOT/version - 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]
[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]
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=29577group=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=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/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 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, kelvin goodson [EMAIL PROTECTED] wrote: What should we be concentrating our efforts on in SDO Java. I posted a while back to suggest we think about the content of a next release. We've had a few fixes go in recently, but I'd like to see more consideration of release content before we crank the handle. It would
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: 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: 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 tuscany-dev@ws.apache.org 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 tuscany-dev@ws.apache.org 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] 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.http.tomcat.TomcatServeraddServletMapping INFO: Added Servlet mapping:
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: tuscany-dev@ws.apache.org 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
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: tuscany-dev@ws.apache.org 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)
[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-tabpanelfocusedCommentId=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]
[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.init(SCANodeImpl.java:136) [java] at org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54) [java] at org.apache.tuscany.sca.node.SCANodeFactory.createNodeWithComposite(SCANodeFactory.java:149) [java] ... 1 more [java] Caused by: org.apache.tuscany.sca.domain.DomainException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.createRuntime(SCADomainProxyImpl.java:299) [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.addNode(SCADomainProxyImpl.java:350) [java] at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:225) [java] ... 4 more [java] Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:756) [java] at org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.createRuntime(SCADomainProxyImpl.java:256) [java] ... 6 more [java] Caused by: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.getFactory(DefaultProviderFactoryExtensionPoint.java:182) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:195) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAServiceBindingProvider.init(RuntimeSCAServiceBindingProvider.java:88) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createServiceBindingProvider(RuntimeSCABindingProviderFactory.java:60) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory.createServiceBindingProvider(RuntimeSCABindingProviderFactory.java:39) [java] at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createServiceBindingProvider(DefaultProviderFactoryExtensionPoint.java:195) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addServiceBindingProvider(CompositeActivatorImpl.java:408) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:690) [java] at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:748) [java] ... 7 more [java] Caused by: java.lang.reflect.InvocationTargetException [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [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
[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] 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-tabpanelfocusedCommentId=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 tuscany-dev@ws.apache.org 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] 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]
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]
