[jira] Commented: (TUSCANY-331) No maven plugin for Java2WSDL
[ http://issues.apache.org/jira/browse/TUSCANY-331?page=comments#action_12379007 ] Jean-Sebastien Delfino commented on TUSCANY-331: Yes, this makes a lot of sense. I guess the change to the samples and other projects is not that bad, you'll just need to change the id of the current wsdl2java plugin. I suggest tuscany-wsdl2java-plugin instead of tuscany-sca-plugin-wsdl2java. To minimize the changes at this point (since we're trying to stabilize our M1 release), can you keep one tools project for now, but just create two different plugin projects under a plugins project? Thanks! No maven plugin for Java2WSDL - Key: TUSCANY-331 URL: http://issues.apache.org/jira/browse/TUSCANY-331 Project: Tuscany Type: New Feature Components: Java SCA Tools Reporter: Rick Rineholt Assignee: Jean-Sebastien Delfino There is no maven plugin for Java2WSDL as there is for SDO gen. and SCA gen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-287) Need to pick a selection of two Javascript samples for our release
[ http://issues.apache.org/jira/browse/TUSCANY-287?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-287: -- Assign To: ant elder (was: Jean-Sebastien Delfino) Ant, assigning to you as I understood from the recent chat discussions that you were working on a sample demonstrating the most relevant aspects of the javascript integration (incl. EAX support). The sample will have to be ready by EOD thursday to make the tentative cut for our release. Need to pick a selection of two Javascript samples for our release -- Key: TUSCANY-287 URL: http://issues.apache.org/jira/browse/TUSCANY-287 Project: Tuscany Type: New Feature Components: Java SCA Samples Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: ant elder Fix For: M1 We need to pick and clean up one or two Javascript samples for our first release. See the discussion on our Wiki at http://wiki.apache.org/ws/Tuscany/Tasks. Sebastien volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-297) Various cleanups and enhancements to the website
[ http://issues.apache.org/jira/browse/TUSCANY-297?page=all ] Jean-Sebastien Delfino resolved TUSCANY-297: Resolution: Duplicate Covered by TUSCANY-315 Various cleanups and enhancements to the website Key: TUSCANY-297 URL: http://issues.apache.org/jira/browse/TUSCANY-297 Project: Tuscany Type: Improvement Components: Website Versions: M1 Reporter: haleh mahbod Assignee: haleh mahbod Fix For: M1 Re-arranged the main page index to improve finding information. Added developer section and also added coding guidelines, JavaDocs. updated 'how to update website' instructions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-170) WSDL2Java and runtime have inconsistent name-mangling convention for WSDL portType and operation
[ http://issues.apache.org/jira/browse/TUSCANY-170?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-170: -- Assign To: Jean-Sebastien Delfino (was: Raymond Feng) WSDL2Java and runtime have inconsistent name-mangling convention for WSDL portType and operation Key: TUSCANY-170 URL: http://issues.apache.org/jira/browse/TUSCANY-170 Project: Tuscany Type: Bug Components: Java SCA Tools Versions: M1 Reporter: Raymond Feng Assignee: Jean-Sebastien Delfino Priority: Blocker Fix For: M1 Attachments: interopdoc.wsdl 1. For WSDL portType Doc_TestPortType, a java interface Doc_TestPortType is generated by WSDL2Java, but the runtime ( by XMLUtil ) expects DocTestPortType 2. WSDL2Java uses the name of WSDL operations as-is, for example, operation SingleTag -- java method SingleTag, but runtime expects singleTag (by XMLUtil). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-321) Injection of references into a simple POJO without annotations does not work
[ http://issues.apache.org/jira/browse/TUSCANY-321?page=all ] Jean-Sebastien Delfino updated TUSCANY-321: --- Fix Version: Mx Version: Mx (was: M1) I verified that if you create a .componentType file for your component implementation then references are correctly found. So basically the story is: - either you annotate your component with Java5 annotations, in this case you don't have to annotate properties, but you must annotate your references. - or you create an equivalent .componentType file - or you just use the POJO without annotations or .componentType but then the POJO can only have properties and no references. I think this is fine for M1, moving this issue to Mx. Jim, Thanks for investigating this! Injection of references into a simple POJO without annotations does not work Key: TUSCANY-321 URL: http://issues.apache.org/jira/browse/TUSCANY-321 Project: Tuscany Type: Bug Components: Java SCA Core, Java SCA POJO Container Versions: Mx Reporter: Jean-Sebastien Delfino Assignee: Jim Marino Priority: Critical Fix For: M1, Mx Attachments: undefreference.zip Injection of references into a simple POJO without annotations does not work. Create a simple POJO component without any SCA annotations. On the POJO declare public fields or public setters for the component's references. Wire the references in sca.module. When the module starts you will get the following exception: [surefire] Running calculator.CalculatorTestCase [surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.015 sec [surefire] [surefire] testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.999 sec ERROR! org.apache.tuscany.model.assembly.AssemblyInitializationException: Undefined reference [addService] at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:162) at org.apache.tuscany.model.assembly.impl.CompositeImpl.initialize(CompositeImpl.java:194) at org.apache.tuscany.model.assembly.impl.ModuleImpl.initialize(ModuleImpl.java:85) at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:135) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:156) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:36) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:285) at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:201) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:366) at
[jira] Updated: (TUSCANY-321) Injection of references into a simple POJO without annotations does not work
[ http://issues.apache.org/jira/browse/TUSCANY-321?page=all ] Jean-Sebastien Delfino updated TUSCANY-321: --- Priority: Minor (was: Critical) The exact behavior with non-annotated references will have to be clarified in the spec. Injection of references into a simple POJO without annotations does not work Key: TUSCANY-321 URL: http://issues.apache.org/jira/browse/TUSCANY-321 Project: Tuscany Type: Bug Components: Java SCA Core, Java SCA POJO Container Versions: Mx Reporter: Jean-Sebastien Delfino Assignee: Jim Marino Priority: Minor Fix For: M1, Mx Attachments: undefreference.zip Injection of references into a simple POJO without annotations does not work. Create a simple POJO component without any SCA annotations. On the POJO declare public fields or public setters for the component's references. Wire the references in sca.module. When the module starts you will get the following exception: [surefire] Running calculator.CalculatorTestCase [surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.015 sec [surefire] [surefire] testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.999 sec ERROR! org.apache.tuscany.model.assembly.AssemblyInitializationException: Undefined reference [addService] at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:162) at org.apache.tuscany.model.assembly.impl.CompositeImpl.initialize(CompositeImpl.java:194) at org.apache.tuscany.model.assembly.impl.ModuleImpl.initialize(ModuleImpl.java:85) at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:135) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:156) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:36) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:285) at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:201) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:366) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at
[jira] Resolved: (TUSCANY-170) WSDL2Java and runtime have inconsistent name-mangling convention for WSDL portType and operation
[ http://issues.apache.org/jira/browse/TUSCANY-170?page=all ] Jean-Sebastien Delfino resolved TUSCANY-170: Resolution: Fixed Will check in the fix as soon as SVN gets back up. WSDL2Java and runtime have inconsistent name-mangling convention for WSDL portType and operation Key: TUSCANY-170 URL: http://issues.apache.org/jira/browse/TUSCANY-170 Project: Tuscany Type: Bug Components: Java SCA Tools Versions: M1 Reporter: Raymond Feng Assignee: Jean-Sebastien Delfino Priority: Blocker Fix For: M1 Attachments: interopdoc.wsdl 1. For WSDL portType Doc_TestPortType, a java interface Doc_TestPortType is generated by WSDL2Java, but the runtime ( by XMLUtil ) expects DocTestPortType 2. WSDL2Java uses the name of WSDL operations as-is, for example, operation SingleTag -- java method SingleTag, but runtime expects singleTag (by XMLUtil). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-109) Marker files generated by the Tuscany WSDL2Java tool should not have a .wsdl extension
[ http://issues.apache.org/jira/browse/TUSCANY-109?page=all ] Jean-Sebastien Delfino resolved TUSCANY-109: Resolution: Fixed Fixed, will check in the fix as soon as SVN gets back up. Kept .gen# at the beginning of the file name, but added .wsdl2java (for the wsdl2java generator) and .xsd2java (for the sdo generator) at the end. Marker files generated by the Tuscany WSDL2Java tool should not have a .wsdl extension -- Key: TUSCANY-109 URL: http://issues.apache.org/jira/browse/TUSCANY-109 Project: Tuscany Type: Bug Components: Java SCA Tools Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: M1 Our WSDL2Java tool generates a target/wsdl2java-source/.gen#fileName.wsdl file to record the fact that Java interfaces have been generated from fileName.wsdl. The gen#fileName.wsdl marker file has a .wsdl extension but is not a valid WSDL file. This confuses IDEs (for example Eclipse) which attempt to validate this file, find it invalid, report validation errors and mark it with a red-x. This is going to confuse application developers. I recommend that we change the name pattern for these files to fileName.wsdl.gen. Adding the .gen extension at the end makes clear that these files are not WSDL files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-294) Document the assembly model
[ http://issues.apache.org/jira/browse/TUSCANY-294?page=comments#action_12379017 ] Jean-Sebastien Delfino commented on TUSCANY-294: First, removing the obsolete doc and diagrams from the model project. Document the assembly model --- Key: TUSCANY-294 URL: http://issues.apache.org/jira/browse/TUSCANY-294 Project: Tuscany Type: New Feature Components: Website Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: M1 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Sebastien has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-228) Maven plugin SDO Gen and WSDL2SDO tools do not allow individual wsdl files to be specified.
[ http://issues.apache.org/jira/browse/TUSCANY-228?page=all ] Jean-Sebastien Delfino updated TUSCANY-228: --- Fix Version: M1-tentative (was: M1) Version: M1-tentative (was: M1) Assign To: Rick Rineholt Rick, do you think that you could do the same thing you did in tuscany-sca-plugin also in tuscany-sdo-plugin? The fix should be very very similar. Thanks... Maven plugin SDO Gen and WSDL2SDO tools do not allow individual wsdl files to be specified. Key: TUSCANY-228 URL: http://issues.apache.org/jira/browse/TUSCANY-228 Project: Tuscany Type: Bug Components: Java SCA Tools, Java SDO Tools Versions: M1-tentative Environment: all Reporter: Rick Rineholt Assignee: Rick Rineholt Priority: Critical Fix For: M1-tentative For Maven plugins tuscany-sdo-plugin tuscany-sca-plugin there doesn't seem to be a way to specify individual wsdl files to work on. Repeating these blocks only seems to run the last one. Specifying a directory is not optimal either since: 1) you may not want to process all wsdl files there. 2) you may want to specify with each different options. (i.e. javapackage etc) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-228) Maven plugin SDO Gen and WSDL2SDO tools do not allow individual wsdl files to be specified.
[ http://issues.apache.org/jira/browse/TUSCANY-228?page=all ] Jean-Sebastien Delfino updated TUSCANY-228: --- Priority: Major (was: Critical) This is not a critical issue. A workaround is to just put your XSD files in a single directory and pass that directory to the tuscany-sdo-plugin. The more serious limitation is that you won't be able to specify a java package per XSD, but the recommended approach is to use SDO annotations to specify the java package anyway. Maven plugin SDO Gen and WSDL2SDO tools do not allow individual wsdl files to be specified. Key: TUSCANY-228 URL: http://issues.apache.org/jira/browse/TUSCANY-228 Project: Tuscany Type: Bug Components: Java SCA Tools, Java SDO Tools Versions: M1-tentative Environment: all Reporter: Rick Rineholt Assignee: Rick Rineholt Fix For: M1-tentative For Maven plugins tuscany-sdo-plugin tuscany-sca-plugin there doesn't seem to be a way to specify individual wsdl files to work on. Repeating these blocks only seems to run the last one. Specifying a directory is not optimal either since: 1) you may not want to process all wsdl files there. 2) you may want to specify with each different options. (i.e. javapackage etc) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-74) Support wire multiplicty in JavaScript components
[ http://issues.apache.org/jira/browse/TUSCANY-74?page=all ] Jean-Sebastien Delfino updated TUSCANY-74: -- Fix Version: Mx (was: M1) Version: Mx (was: M1) I suggest we document this as a limitation. Support wire multiplicty in JavaScript components - Key: TUSCANY-74 URL: http://issues.apache.org/jira/browse/TUSCANY-74 Project: Tuscany Type: Bug Components: Java SCA JavaScript Container Versions: Mx Reporter: Jim Marino Assignee: ant elder Fix For: Mx JavaScript components do not support wire multiplicity; JavaScriptComponentContextBuilder needs to be updated. For an example of what needs to be done, see JavaComponentContextBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-288) Document the SCA programming model supported by this release
[ http://issues.apache.org/jira/browse/TUSCANY-288?page=all ] Jean-Sebastien Delfino updated TUSCANY-288: --- Fix Version: Mx (was: M1) Version: Mx (was: M1) We need a list of limitations and big differences between the programming model supported in M1 and the 0.9 spec posted on the Website, but I don't think we have the time and resources to rewrite a complete PM tutorial document better than the spec. I'm moving this to Mx, if somebody volunteers and has the time to provide all the detailed technical input in the next 2 or 3 days please feel free to move back to M1. Document the SCA programming model supported by this release Key: TUSCANY-288 URL: http://issues.apache.org/jira/browse/TUSCANY-288 Project: Tuscany Type: Improvement Components: Website Versions: Mx Reporter: Jean-Sebastien Delfino Assignee: haleh mahbod Fix For: Mx This has been identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. The consensus is that we need a tutorial doc easier to read than the spec. Jim has volunteered to provide the technical input to Haleh. Haleh volunteering to put the document together, assigning to Jim for now since he's a committer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-285) Sample showing how to import an XML schema in SCDL
[ http://issues.apache.org/jira/browse/TUSCANY-285?page=all ] Jean-Sebastien Delfino resolved TUSCANY-285: Resolution: Fixed Assign To: Jean-Sebastien Delfino (was: Jeremy Boynes) This is fixed, covered by the customerinfo sample. Sample showing how to import an XML schema in SCDL -- Key: TUSCANY-285 URL: http://issues.apache.org/jira/browse/TUSCANY-285 Project: Tuscany Type: New Feature Components: Java SCA Samples Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: M1 Need a sample showing how to import an XML schema in SCDL. See the discussion on our Wiki at http://wiki.apache.org/ws/Tuscany/Tasks. Jeremy volunteered to provide this sample. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-180) Clarify/decide how to express portType and port QNames in SCDL
[ http://issues.apache.org/jira/browse/TUSCANY-180?page=all ]
Jean-Sebastien Delfino reassigned TUSCANY-180:
--
Assign To: Jean-Sebastien Delfino (was: Michael John Edwards)
Clarify/decide how to express portType and port QNames in SCDL
--
Key: TUSCANY-180
URL: http://issues.apache.org/jira/browse/TUSCANY-180
Project: Tuscany
Type: Bug
Components: Specification
Versions: M1
Reporter: Jean-Sebastien Delfino
Assignee: Jean-Sebastien Delfino
Fix For: M1
Several proposals are on the table and have been discussed on the dev list
there:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL
PROTECTED]
- the WSDL 2.0 notation, as described in the current SCA 0.9 spec
- a legacy {ns}localname notation
- the usual XMLish notation xmlns:p=ns at the top of the SCDL doc or an
enclosing scope, and a p:localname notation
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-180) Clarify/decide how to express portType and port QNames in SCDL
[ http://issues.apache.org/jira/browse/TUSCANY-180?page=all ]
Jean-Sebastien Delfino updated TUSCANY-180:
---
Starting to work on a fix, will add support for the notation described in the
spec.
Clarify/decide how to express portType and port QNames in SCDL
--
Key: TUSCANY-180
URL: http://issues.apache.org/jira/browse/TUSCANY-180
Project: Tuscany
Type: Bug
Components: Specification
Versions: M1
Reporter: Jean-Sebastien Delfino
Assignee: Jean-Sebastien Delfino
Fix For: M1
Several proposals are on the table and have been discussed on the dev list
there:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL
PROTECTED]
- the WSDL 2.0 notation, as described in the current SCA 0.9 spec
- a legacy {ns}localname notation
- the usual XMLish notation xmlns:p=ns at the top of the SCDL doc or an
enclosing scope, and a p:localname notation
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-281) BigBank sample should use Java2WSDL tool
[ http://issues.apache.org/jira/browse/TUSCANY-281?page=all ] Jean-Sebastien Delfino updated TUSCANY-281: --- Fix Version: Mx Version: Mx (was: M1) BigBank sample should use Java2WSDL tool Key: TUSCANY-281 URL: http://issues.apache.org/jira/browse/TUSCANY-281 Project: Tuscany Type: New Feature Components: Java BigBank Scenario Versions: Mx Reporter: Jean-Sebastien Delfino Assignee: Rick Rineholt Fix For: M1, Mx The account module in the bigbank sample should use the Java2WSDL tool to generate a WSDL portType from the account service Java interface. This is identified as a work item for our release, see http://wiki.apache.org/ws/Tuscany/Tasks. Rick volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-61) ?WSDL on WS binding entryPoints fails
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=comments#action_12379031 ] ant elder commented on TUSCANY-61: -- Tried ?wsdl with the latest code and its completely broken again, not just the incorrect endpoint. ?WSDL on WS binding entryPoints fails - Key: TUSCANY-61 URL: http://issues.apache.org/jira/browse/TUSCANY-61 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: M1 Reporter: ant elder Assignee: Raymond Feng Fix For: M1 Appending ?WSDL to the url of a entryPoint with a WS binding should return the WSDL, but it fails, first as its missing the xmlschema jar then once thats available with the following exception. Looks like its trying to gen a new wsdl but it should be able to use the definition from the model. org.apache.axis2.AxisFault: no scheam found for the service; nested exception is: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:373) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:322) at org.apache.axis2.transport.http.ListingAgent.listService(ListingAgent.java:469) at org.apache.axis2.transport.http.ListingAgent.handle(ListingAgent.java:393) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doGet(WebServiceEntryPointServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService2WOM.generateWOM(AxisService2WOM.java:86) at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:362) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-217) WSDLDefinition caching allows EntryPoint WS URLs to clobber ExternalService URLs
[ http://issues.apache.org/jira/browse/TUSCANY-217?page=all ] Jean-Sebastien Delfino updated TUSCANY-217: --- Assign To: Jim Marino (was: Rick Rineholt) Priority: Critical (was: Minor) This is actually a critical issue... WSDLs from different applications collide in the WSDLDefinitionRegistry singleton and this is very confusing. Jim and I discussed this issue yesterday. The problem is that there is a single instance of the WSDLDefinitionRegistry and therefore one WSDL definition cache for the whole Tuscany runtime. Instead what we need is an instance per application... Jim, I'm assigning this one to you because you may find an easy way to fix or workaround this issue. If you find a way in the runtime to scope the WSDLDefinitionRegistry per application then great! otherwise we'll have to maintain a per-app cache in WSDLDefinitionRegistry and pass the app key to the methods that populate or query the cache... WSDLDefinition caching allows EntryPoint WS URLs to clobber ExternalService URLs - Key: TUSCANY-217 URL: http://issues.apache.org/jira/browse/TUSCANY-217 Project: Tuscany Type: Improvement Components: Java SCA Model Versions: M1 Environment: Windows - Tomcat - April 17th download of Tuscany SVN Reporter: Scott Kurz Assignee: Jim Marino Priority: Critical Fix For: M1 At a high-level, the problem is just that the URL in the EntryPoint-side WSDL used in a WS binding.sometimes matters and sometimes does not. When invoking over a WS binding, it might be nice to say that, although both client and server have a copy of the WSDL, that only the client URL matters, but not the server's. The URL I'm talking about appears in the WSDL's wsdlsoap:address tag. If an ExternalService using a WS binding with the same namespace as the Entry Point is hosted in the same process as the Entry Point, then the URL used to invoke the ExternalService will come from whichever WSDL Definition is loaded first, the EntryPoint's or the ExternalService's. To be sure that the correct URL is used, you must keep both URLs in synch with the URL corresponding to the URL at which the app is actually hosted (i.e. the IP address and port of your Tomcat service, plus your app's context root, plus the SCA-specific portion of the URL at the end). If the ExternalService lives in another JVM, however, then the EntryPoint WSDL's URL is irrelevant for invoking the SCA WS over the External Service WS binding. Then you only need to synchronize the External Service URL with the URL at which the app is actually hosted. By adding an External Service into the same JVM as the SCA WS with Entry Point , then, you all of a sudden make the Entry Point WSDL's URL relevant. To recreate this problem, take the HelloWorldWSClient sample, and put a JSP front-end on it, and package it into a WAR.Then take the HelloWorld WS sample WAR, and tweak the URL to something that doesn't match your Tomcat server's URL. If you install both WARs and you ensure that the newly-created HelloWorldWSClient WAR starts before the HelloWorld WS WAR (with bad URL), the sample will work fine... HelloWorldWSClient WAR will call out the WS in HelloWorld WS. If, however, the apps are started in reverse order, the garbage URL on the EntryPoint-side will take effect and it don't work. At a low-level, the problem seems to be the definitionsByNamespace map used by the method org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions, which maps namespaces to WSDL Definitions. Assuming there is value caching WSDL Definitions per Namespace, maybe the cache should be implemented such that EntryPoint-side URLs would not take precedence over an ExternalService-side URL in this manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-326) Components declared in an sca.fragment file cannot be found
[ http://issues.apache.org/jira/browse/TUSCANY-326?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-326: -- Assign To: Jean-Sebastien Delfino (was: Jim Marino) Components declared in an sca.fragment file cannot be found --- Key: TUSCANY-326 URL: http://issues.apache.org/jira/browse/TUSCANY-326 Project: Tuscany Type: Bug Components: Java SCA Model, Java SCA Core Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Critical Fix For: M1 Attachments: fragmentnotfound.zip Declare a component in an sca.fragment file, declare another component in an sca.module file, wire the first component to the second. When the application starts, you will get an exception reporting that the second component is not found. This pretty much makes the use of SCA fragments impossible. [surefire] Running calculator.CalculatorTestCase [surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.122 sec [surefire] [surefire] testCalculator(calculator.CalculatorTestCase) Time elapsed: 1.087 sec ERROR! java.lang.IllegalArgumentException: Cannot find service for sca:AddServiceComponent at org.apache.tuscany.model.assembly.impl.CompositeImpl.initialize(CompositeImpl.java:296) at org.apache.tuscany.model.assembly.impl.ModuleImpl.initialize(ModuleImpl.java:81) at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:135) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:156) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:36) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:285) at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:201) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:366) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at
[jira] Updated: (TUSCANY-183) Tuscany news page points to an obsolete set up document on our Wiki page
[ http://issues.apache.org/jira/browse/TUSCANY-183?page=all ] Jean-Sebastien Delfino updated TUSCANY-183: --- Priority: Major (was: Minor) This is a minor fix, but a major issue for new users. Tuscany news page points to an obsolete set up document on our Wiki page Key: TUSCANY-183 URL: http://issues.apache.org/jira/browse/TUSCANY-183 Project: Tuscany Type: Bug Components: Website Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: haleh mahbod Fix For: M1 The Tuscany news page should point to the correct set up instructions on the web site, the Wiki page is an obsolete version of what we now have on the web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-215) Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository
[ http://issues.apache.org/jira/browse/TUSCANY-215?page=all ] Jean-Sebastien Delfino updated TUSCANY-215: --- Fix Version: M1-tentative (was: M1) Version: M1-tentative (was: M1) Priority: Minor (was: Major) Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository --- Key: TUSCANY-215 URL: http://issues.apache.org/jira/browse/TUSCANY-215 Project: Tuscany Type: Sub-task Components: Build System Versions: M1-tentative Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: M1-tentative We need to document the steps to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository. Dan suggested mvn source:jar javadoc:jar deploy. We need to add these steps to our Wiki or Web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-184) SCA Java tools documentation is out of sync with the current implementation
[ http://issues.apache.org/jira/browse/TUSCANY-184?page=all ] Jean-Sebastien Delfino resolved TUSCANY-184: Resolution: Fixed I just checked the web site and it's actually fixed. SCA Java tools documentation is out of sync with the current implementation --- Key: TUSCANY-184 URL: http://issues.apache.org/jira/browse/TUSCANY-184 Project: Tuscany Type: Bug Components: Website Versions: M1 Reporter: Jean-Sebastien Delfino Fix For: M1 The documentation at http://incubator.apache.org/tuscany/SCA_Java_Tools_documentation.html is describing a nice set of tools... there is just a small problem, the current tools implemented in Tuscany are completely different from what is described on that page :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-280) Port the WS binding implementation to the new protocol and transport binding APIs
[ http://issues.apache.org/jira/browse/TUSCANY-280?page=all ] Jean-Sebastien Delfino resolved TUSCANY-280: Resolution: Fixed This was fixed by Ant. Port the WS binding implementation to the new protocol and transport binding APIs - Key: TUSCANY-280 URL: http://issues.apache.org/jira/browse/TUSCANY-280 Project: Tuscany Type: New Feature Components: Java SCA Axis Binding Versions: M1 Reporter: Jean-Sebastien Delfino Fix For: M1 This is one of the tasks for our release, see our Wiki page http://wiki.apache.org/ws/Tuscany/Tasks The WS binding needs to be adjusted to use the core transport extensibility API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-333) BigBank intermittently gets ClassCastException
[ http://issues.apache.org/jira/browse/TUSCANY-333?page=all ] Jean-Sebastien Delfino updated TUSCANY-333: --- Priority: Critical (was: Major) I'm not sure anymore that this is related to 226 but this is a serious problem. We need the complete stack trace and also info on which classloaders are actually used for the business interface for the service and the dataobject flowing through it. Rick was going to investigate. BigBank intermittently gets ClassCastException --- Key: TUSCANY-333 URL: http://issues.apache.org/jira/browse/TUSCANY-333 Project: Tuscany Type: Bug Components: Java BigBank Scenario Versions: M1 Reporter: Rick Rineholt Priority: Critical Fix For: M1 I have noticed this behavior but it's really hard to repro. I have debugged it once and it occured in the sun proxyy code I think right after JDKInvocationHandler.invoke call. The only regular pattern I've been able to see if there is a previous un releated exception like an invalid user name is entered that generates an expected exception it seems sometimes after this, this exception continues to get thrown for any activity. Once this happens it seems the only cure is to recycle TC server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-333) BigBank intermittently gets ClassCastException
[ http://issues.apache.org/jira/browse/TUSCANY-333?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-333: -- Assign To: Rick Rineholt BigBank intermittently gets ClassCastException --- Key: TUSCANY-333 URL: http://issues.apache.org/jira/browse/TUSCANY-333 Project: Tuscany Type: Bug Components: Java BigBank Scenario Versions: M1 Reporter: Rick Rineholt Assignee: Rick Rineholt Priority: Critical Fix For: M1 I have noticed this behavior but it's really hard to repro. I have debugged it once and it occured in the sun proxyy code I think right after JDKInvocationHandler.invoke call. The only regular pattern I've been able to see if there is a previous un releated exception like an invalid user name is entered that generates an expected exception it seems sometimes after this, this exception continues to get thrown for any activity. Once this happens it seems the only cure is to recycle TC server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-79) Document the JavaScript component type
[ http://issues.apache.org/jira/browse/TUSCANY-79?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-79: - Assign To: ant elder Document the JavaScript component type -- Key: TUSCANY-79 URL: http://issues.apache.org/jira/browse/TUSCANY-79 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Versions: M1 Reporter: ant elder Assignee: ant elder Priority: Minor Fix For: M1 Create some doc describing a JavaScript component and script file, and how to configure them with componentType side files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-244) BuilderConfigException thrown when trying to build config for reference with multiplicity 1..n
[ http://issues.apache.org/jira/browse/TUSCANY-244?page=all ]
Jean-Sebastien Delfino resolved TUSCANY-244:
Resolution: Fixed
I believe that this has been fixed by Jim 2 days ago (under a similar JIRA
issue that I had created). Could you please try again now with the latest
code... and reopen if this is not actually fixed? Thanks.
BuilderConfigException thrown when trying to build config for reference with
multiplicity 1..n
--
Key: TUSCANY-244
URL: http://issues.apache.org/jira/browse/TUSCANY-244
Project: Tuscany
Type: Bug
Components: Java SCA Core
Versions: M1
Environment: Eclipse 3.1.1 on Windows XP SP2
Reporter: Ignacio Silva-Lepe
Priority: Minor
Fix For: M1
Exception in thread main
org.apache.tuscany.core.builder.BuilderConfigException: Incompatible source
and target interface types for reference [warehouses]
Context stack trace:
[tuscany.root][supplychain][supplychain][RetailerComponent][WarehouseComponent1][tuscany.root]
at
org.apache.tuscany.core.builder.impl.DefaultWireBuilder.connect(DefaultWireBuilder.java:64)
...
(SupplychainClient.java:43)
using SCDL:
module xmlns=http://www.osoa.org/xmlns/sca/0.9;
xmlns:v=http://www.osoa.org/xmlns/sca/values/0.9;
name=SupplyChain
component name=CustomerComponent
implementation.java
class=org.apache.tuscany.samples.supplychain.CustomerComponentImpl/
references
v:retailerRetailerComponent/v:retailer
/references
/component
component name=RetailerComponent
implementation.java
class=org.apache.tuscany.samples.supplychain.RetailerComponentImpl/
references
v:warehousesWarehouseComponent1/v:warehouses
v:warehousesWarehouseComponent2/v:warehouses
/references
/component
component name=WarehouseComponent1
implementation.java
class=org.apache.tuscany.samples.supplychain.WarehouseComponentImpl/
references
v:shipperShipperComponent/v:shipper
/references
/component
component name=WarehouseComponent2
implementation.java
class=org.apache.tuscany.samples.supplychain.WarehouseComponentImpl/
references
v:shipperShipperComponent/v:shipper
/references
/component
component name=ShipperComponent
implementation.java
class=org.apache.tuscany.samples.supplychain.ShipperComponentImpl/
references
v:customerCustomerComponent/v:customer
/references
/component
/module
and component interfaces:
package org.apache.tuscany.samples.supplychain;
/**
* This is the business interface of the Retailer service component.
*/
public interface Retailer {
public void submitOrder(String order);
}
and
package org.apache.tuscany.samples.supplychain;
/**
* This is the business interface of the Warehouse service component.
*/
public interface Warehouse {
public void fulfillOrder(String order);
}
with implementation of Retailer given by
package org.apache.tuscany.samples.supplychain;
import java.util.List;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Service;
/**
* This class implements the Customer service component.
*/
@Service(Retailer.class)
public class RetailerComponentImpl implements Retailer {
@Reference(name=warehouses,required=true)
private ListWarehouse warehouses;
public void submitOrder(String order) {
for(Warehouse warehouse : warehouses) {
warehouse.fulfillOrder(order + , submitted);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-313) Tuscany SCA and SDO plugins attempt to generate code on incorrect goals
[ http://issues.apache.org/jira/browse/TUSCANY-313?page=all ] Jean-Sebastien Delfino updated TUSCANY-313: --- Fix Version: M1-tentative (was: M1) Version: M1-tentative (was: M1) This is an inconvenience but not a big issue. Not very important for M1. Tuscany SCA and SDO plugins attempt to generate code on incorrect goals --- Key: TUSCANY-313 URL: http://issues.apache.org/jira/browse/TUSCANY-313 Project: Tuscany Type: Bug Components: Java SCA Tools, Java SDO Tools Versions: M1-tentative Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: M1-tentative The tuscany SCA and SDO plugins attempt to generate code on incorrect goals, for example the eclipse:eclipse goal. To reproduce the problem, from the tuscany/java directory do the following: mvn clean eclipse:eclipse The SCA and SDO maven plugins will generate Java interfaces for services and SDO classes. They shouldn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-341) system:implementation.system ... elements should be changed to tuscany:implementation.system ...
[ http://issues.apache.org/jira/browse/TUSCANY-341?page=all ] Jean-Sebastien Delfino resolved TUSCANY-341: Resolution: Fixed Assign To: Jean-Sebastien Delfino Fixed, will check in the fix as soon as SVN gets back up. system:implementation.system ... elements should be changed to tuscany:implementation.system ... Key: TUSCANY-341 URL: http://issues.apache.org/jira/browse/TUSCANY-341 Project: Tuscany Type: Bug Components: Java SCA Core Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: M1 In the SCDL files packaged with the runtime, the tuscany SCDL extension namespace should be mapped to prefix tuscany instead of system, system:implementation.system is very confusing. This is an easy rename fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-343) WSDL2JavaGenerator fails if the wsdl have an import for the XSD types
[ http://issues.apache.org/jira/browse/TUSCANY-343?page=all ] Jean-Sebastien Delfino updated TUSCANY-343: --- Fix Version: M1 Version: M1 (was: Mx) Priority: Critical (was: Major) WSDL2JavaGenerator fails if the wsdl have an import for the XSD types - Key: TUSCANY-343 URL: http://issues.apache.org/jira/browse/TUSCANY-343 Project: Tuscany Type: Bug Components: Java SCA Tools Versions: M1 Environment: Windows XP Reporter: Jojo Joseph Assignee: Frank Budinsky Priority: Critical Fix For: M1 Attachments: testing-interop-uddi.zip I have a WSDL (uddi_api_v3_portType.wsdl) which import the types schema as : types xsd:schema targetNamespace=urn:uddi-org:api_v3_portType xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:import namespace=urn:uddi-org:api_v3 schemaLocation=uddi_v3.xsd/ /xsd:schema /types If I specify this WSDL as a parameter to the tuscany-sca-plugin for java code generation, it fails with the following exception : [INFO] Generating Java service interfaces from C:\Project\Tuscany\ws0508\testing-interop-uddi\src\main\resources\wsdl\test.wsdl java.lang.NullPointerException at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:191) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:161) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:132) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) As a side note I would like to mention that if I specify the WSDL as a parameter to tuscany-sdo-plugin, then that too fails with the same exception. But there is a work-around for SDO code generation as I can specify the XSD file containing the types schema as the parameter to the tuscany-sdo-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL
[ http://issues.apache.org/jira/browse/TUSCANY-120?page=all ] Jean-Sebastien Delfino updated TUSCANY-120: --- Fix Version: M1-tentative Version: M1-tentative Tentative for M1, we should integrate this if we manage to get Java2WSDL to generate the correct namespaces. The namespace for the generated XSD types should match the namespace of the (Java) SDO types that you start with... Axis2 WS binding support for entryPoint without pre-existing WSDL -- Key: TUSCANY-120 URL: http://issues.apache.org/jira/browse/TUSCANY-120 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: M1-tentative Reporter: ant elder Assignee: Raymond Feng Fix For: M1-tentative Where the entryPoint doesn't use interface.wsdl then the pre-existing WSDL document shouldn't be required. Axis2 can generate WSDL at runtime based on the service interface so the Axis2 binding can use that to support the following: entryPoint name=AccountService interface.java interface=org.apache.tuscany.binding.axis2.assembly.tests.bigbank.account.services.account.AccountService/ binding.ws/ referenceAccountServiceComponent/reference /entryPoint See ML discussion: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-331) No maven plugin for Java2WSDL
[ http://issues.apache.org/jira/browse/TUSCANY-331?page=all ] Jean-Sebastien Delfino updated TUSCANY-331: --- Fix Version: M1-tentative Version: M1-tentative No maven plugin for Java2WSDL - Key: TUSCANY-331 URL: http://issues.apache.org/jira/browse/TUSCANY-331 Project: Tuscany Type: New Feature Components: Java SCA Tools Versions: M1-tentative Reporter: Rick Rineholt Assignee: Jean-Sebastien Delfino Fix For: M1-tentative There is no maven plugin for Java2WSDL as there is for SDO gen. and SCA gen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-81) Make .componentType side files optional for JavaScript components
[ http://issues.apache.org/jira/browse/TUSCANY-81?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-81: - Assign To: ant elder Make .componentType side files optional for JavaScript components - Key: TUSCANY-81 URL: http://issues.apache.org/jira/browse/TUSCANY-81 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Reporter: ant elder Assignee: ant elder Priority: Minor Currently JavaScript components require a .componentType side file. Thats because currently its the only way of defining the interface being implemented by the component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-82) Enable using E4X to access the message in a JavaScript component
[ http://issues.apache.org/jira/browse/TUSCANY-82?page=all ] Jean-Sebastien Delfino updated TUSCANY-82: -- Fix Version: M1-tentative Version: M1-tentative Enable using E4X to access the message in a JavaScript component Key: TUSCANY-82 URL: http://issues.apache.org/jira/browse/TUSCANY-82 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Versions: M1-tentative Reporter: ant elder Assignee: ant elder Priority: Minor Fix For: M1-tentative E4X is an extension to JavaScript for processing XML. It would be really nice if this could be used with SCA JavaScript components so that wiring up JavaScript components to WS entryPoints or externalServices gives access to the SOAP Body payload via E4X. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-344) Add a note to the GetTuscanyLinux wiki page noting that Fedora Core 5 comes with svn 1.3.1
[ http://issues.apache.org/jira/browse/TUSCANY-344?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-344: -- Assign To: Jean-Sebastien Delfino Add a note to the GetTuscanyLinux wiki page noting that Fedora Core 5 comes with svn 1.3.1 -- Key: TUSCANY-344 URL: http://issues.apache.org/jira/browse/TUSCANY-344 Project: Tuscany Type: Improvement Components: Website Versions: M1 Environment: Fedora Core 5 Reporter: Simon Laws Assignee: Jean-Sebastien Delfino Priority: Minor There is no readily available rpm for svn on Fedora Core but Fedora Core 5 come with subversion 1.3.1 in the install. Add a note to the GetTuscanyLinux instructions here: http://wiki.apache.org/ws/Tuscany/GetTuscany/Linux -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-344) Add a note to the GetTuscanyLinux wiki page noting that Fedora Core 5 comes with svn 1.3.1
[ http://issues.apache.org/jira/browse/TUSCANY-344?page=all ] Jean-Sebastien Delfino updated TUSCANY-344: --- Fix Version: M1 Add a note to the GetTuscanyLinux wiki page noting that Fedora Core 5 comes with svn 1.3.1 -- Key: TUSCANY-344 URL: http://issues.apache.org/jira/browse/TUSCANY-344 Project: Tuscany Type: Improvement Components: Website Versions: M1 Environment: Fedora Core 5 Reporter: Simon Laws Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: M1 There is no readily available rpm for svn on Fedora Core but Fedora Core 5 come with subversion 1.3.1 in the install. Add a note to the GetTuscanyLinux instructions here: http://wiki.apache.org/ws/Tuscany/GetTuscany/Linux -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-349) Check correctness of required Jar list
[ http://issues.apache.org/jira/browse/TUSCANY-349?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-349: -- Assign To: Rick Rineholt Check correctness of required Jar list -- Key: TUSCANY-349 URL: http://issues.apache.org/jira/browse/TUSCANY-349 Project: Tuscany Type: Improvement Components: Build System Versions: M1 Environment: all Reporter: Simon Laws Assignee: Rick Rineholt Fix For: M1 The required jars are listed on the sample setup page (/tuscany/java/sampleSetup.htm) needs to be checked to make sure that it matches what is atually required by the released code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-349) Check correctness of required Jar list
[ http://issues.apache.org/jira/browse/TUSCANY-349?page=all ] Jean-Sebastien Delfino updated TUSCANY-349: --- Fix Version: M1 Check correctness of required Jar list -- Key: TUSCANY-349 URL: http://issues.apache.org/jira/browse/TUSCANY-349 Project: Tuscany Type: Improvement Components: Build System Versions: M1 Environment: all Reporter: Simon Laws Assignee: Rick Rineholt Fix For: M1 The required jars are listed on the sample setup page (/tuscany/java/sampleSetup.htm) needs to be checked to make sure that it matches what is atually required by the released code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-83) JavaScript components don't support init/destroy/scope
[ http://issues.apache.org/jira/browse/TUSCANY-83?page=all ] Jean-Sebastien Delfino updated TUSCANY-83: -- Fix Version: Mx (was: M1-tentative) Version: Mx (was: M1-tentative) JavaScript components don't support init/destroy/scope -- Key: TUSCANY-83 URL: http://issues.apache.org/jira/browse/TUSCANY-83 Project: Tuscany Type: Bug Components: Java SCA JavaScript Container Versions: Mx Reporter: ant elder Assignee: Michael John Edwards Priority: Minor Fix For: Mx You can't use init, destroy or scope with JavaScript components as currently the .componetType schema doesn't support these so there's no way of specifying them. Need to get the schema changed or come up with something similar to Java annotations for JavaScript -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-347) Add note to sample html describing where to find the sample code
[ http://issues.apache.org/jira/browse/TUSCANY-347?page=all ] Jean-Sebastien Delfino updated TUSCANY-347: --- Fix Version: M1 Assign To: Rick Rineholt Add note to sample html describing where to find the sample code Key: TUSCANY-347 URL: http://issues.apache.org/jira/browse/TUSCANY-347 Project: Tuscany Type: Improvement Components: Java SCA Samples Versions: M1 Environment: all Reporter: Simon Laws Assignee: Rick Rineholt Fix For: M1 When you navigate down to the sample readmes its not obvious to the new user where the sample code actually is that is being discussed. Add a note to each readme giving the directory path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-348) Sample readme link consistency
[ http://issues.apache.org/jira/browse/TUSCANY-348?page=all ] Jean-Sebastien Delfino updated TUSCANY-348: --- Fix Version: M1 Sample readme link consistency -- Key: TUSCANY-348 URL: http://issues.apache.org/jira/browse/TUSCANY-348 Project: Tuscany Type: Improvement Components: Java SCA Samples Versions: M1 Environment: all Reporter: Simon Laws Priority: Minor Fix For: M1 The page that links to the big bank samples ( /tuscany/java/samples/readme.htm) doesn't point to readmes in the same way that the SCA samples page does (/tuscany/java/sca/samples/readme.htm) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-352) Improve the error message given when sca.modules is not found.
[ http://issues.apache.org/jira/browse/TUSCANY-352?page=all ] Jean-Sebastien Delfino updated TUSCANY-352: --- Fix Version: M1 Improve the error message given when sca.modules is not found. -- Key: TUSCANY-352 URL: http://issues.apache.org/jira/browse/TUSCANY-352 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Environment: all Reporter: Simon Laws Assignee: Jim Marino Priority: Minor Fix For: M1 Currently you get the following when sca.modules is not picked up. Exception in thread main org.apache.tuscany.core.config.ConfigurationLoadException: sca.module at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent (AbstractModuleComponentConfigurationLoader.java:116) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent (AbstractModuleComponentConfigurationLoader.java:100) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:102) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67) at org.sample.helloworld.HelloWorldClient.main(HelloWorldClient.java:17) This should probably be a FAQ entry as well ponting out that a bit of fidling with the classpath will fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-81) Make .componentType side files optional for JavaScript components
[ http://issues.apache.org/jira/browse/TUSCANY-81?page=all ] Jean-Sebastien Delfino updated TUSCANY-81: -- Fix Version: M1-tentative Version: M1-tentative Make .componentType side files optional for JavaScript components - Key: TUSCANY-81 URL: http://issues.apache.org/jira/browse/TUSCANY-81 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Versions: M1-tentative Reporter: ant elder Assignee: ant elder Priority: Minor Fix For: M1-tentative Currently JavaScript components require a .componentType side file. Thats because currently its the only way of defining the interface being implemented by the component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-226) Generated SDO Factories/Packages should not automatically register in EPackage.Registry.INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-226?page=all ] Jean-Sebastien Delfino updated TUSCANY-226: --- Fix Version: Mx Version: Mx Generated SDO Factories/Packages should not automatically register in EPackage.Registry.INSTANCE Key: TUSCANY-226 URL: http://issues.apache.org/jira/browse/TUSCANY-226 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Mx Reporter: Jean-Sebastien Delfino Priority: Critical Fix For: Mx This prevents us from using a module scoped TypeHelper. SDOUtil.registerStaticTypes() always registers the static generated types in the .INSTANCE registry. Even if you do not call registerStaticTypes, just touching the generated factory or package triggers the registration in the .INSTANCE registry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-358) TypeHelper.getType(Class ...) either returns unexpected Type or throws ClassCastException for java .lang.String or other simple java types
[ http://issues.apache.org/jira/browse/TUSCANY-358?page=all ] Jean-Sebastien Delfino updated TUSCANY-358: --- Fix Version: M1-tentative Version: M1-tentative (was: M1) (was: Mx) TypeHelper.getType(Class ...) either returns unexpected Type or throws ClassCastException for java .lang.String or other simple java types -- Key: TUSCANY-358 URL: http://issues.apache.org/jira/browse/TUSCANY-358 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: M1-tentative Reporter: Raymond Feng Assignee: Frank Budinsky Priority: Critical Fix For: M1-tentative I ran into two problems: 1) If I happens to initialize EMF XMLTypePackage, TypeHelper.getType(String.class) throws a ClassCastException java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EDataTypeImpl incompatible with commonj.sdo.Type at org.apache.tuscany.sdo.helper.TypeHelperImpl.getType(TypeHelperImpl.java:92) 2) Otherwise I received [EMAIL PROTECTED] (name: LangType) (instanceClassName: java.lang.String) (serializable: true) and the EPackage is: [EMAIL PROTECTED] (name: namespace) (nsURI: http://www.w3.org/XML/1998/namespace, nsPrefix: xml) It seems that the SDO spec doesn't well define the behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-22) Errors serializing an SDO2 graph
[ http://issues.apache.org/jira/browse/TUSCANY-22?page=all ] Jean-Sebastien Delfino updated TUSCANY-22: -- Fix Version: Mx Version: Mx Errors serializing an SDO2 graph Key: TUSCANY-22 URL: http://issues.apache.org/jira/browse/TUSCANY-22 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Mx Environment: 2/2 EMF integration build Reporter: Brent Daniel Fix For: Mx I am having a problem with serialization of an SDO2 datagraph Using java serialization (ObjectOutputStream.writeObject()), I receive the following exception: java.lang.UnsupportedOperationException at org.eclipse.emf.common.util.ECollections$EmptyUnmodifiableEList.add(ECollections.java:638) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTrackingModification(ResourceImpl.java:1212) at org.apache.tuscany.sdo.impl.DataGraphImpl.getWriteReplacement(DataGraphImpl.java:740) at org.apache.tuscany.sdo.impl.DataGraphImpl.getWriteReplacement(DataGraphImpl.java:766) at org.apache.tuscany.sdo.impl.DataObjectImpl.writeReplace(DataObjectImpl.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:1059) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1063) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:324) at org.apache.tuscany.das.rdb.test.SerializationTests.testReadandSerialize(SerializationTests.java:69) Note, the same test case works with SDO 1 and is currently available in SVN (org.apache.tuscany.das.rdb.test.SerializationTests) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-115) Property.isMany() returns false instead of true for global properties
[ http://issues.apache.org/jira/browse/TUSCANY-115?page=all ] Jean-Sebastien Delfino updated TUSCANY-115: --- Fix Version: Mx Version: Mx Property.isMany() returns false instead of true for global properties - Key: TUSCANY-115 URL: http://issues.apache.org/jira/browse/TUSCANY-115 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Mx Reporter: Raymond Feng Fix For: Mx I have this global element defined in the XSD: element name=comment1 type=string/ Property c1 = xsdHelper.getGlobalProperty(http://complex;, comment1, true); boolean isMany = c1.isMany(); // returns false. According to Frank, it should return true instead -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-154) DAS should create graphs with a dynamic root data object even when using generated static SDOs
[ http://issues.apache.org/jira/browse/TUSCANY-154?page=all ] Jean-Sebastien Delfino updated TUSCANY-154: --- Fix Version: Mx Version: Mx DAS should create graphs with a dynamic root data object even when using generated static SDOs -- Key: TUSCANY-154 URL: http://issues.apache.org/jira/browse/TUSCANY-154 Project: Tuscany Type: New Feature Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx The DAS always returns a graph of Data Objects with a dummy root container. This is fine for dynamic scenarios but not so fine when the client is providing a set of generated Types. It is not reasonable to expect the user to provide a dummy root type. Instead, we should return a dynamic dummy root containing the instances of the Types provided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-93) Interoperability tests from the test suite
[ http://issues.apache.org/jira/browse/TUSCANY-93?page=all ] Jean-Sebastien Delfino updated TUSCANY-93: -- Fix Version: Cpp-current Version: Cpp-current Interoperability tests from the test suite -- Key: TUSCANY-93 URL: http://issues.apache.org/jira/browse/TUSCANY-93 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Assignee: Ed Slattery Priority: Minor Fix For: Cpp-current The SDO test suite contains many cases where an XSD is loaded, XML data is loaded and the results verified. We need to add the step of saving the XML/XSD output for all these, then test the same round-trip with the Java SDO. This task covers getting those tests in a suitable form, and making the XSD/XML available to the java community. It would be a useful exercise to also write the java test cases to deliver the same output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-33) Add working SCA C++ samples
[ http://issues.apache.org/jira/browse/TUSCANY-33?page=all ] Jean-Sebastien Delfino updated TUSCANY-33: -- Fix Version: Cpp-current Version: Cpp-current Add working SCA C++ samples --- Key: TUSCANY-33 URL: http://issues.apache.org/jira/browse/TUSCANY-33 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current Add MyValue and Amazon webservice samples to SCA C++ base. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-164) Add encoding of parameter types to Operation
[ http://issues.apache.org/jira/browse/TUSCANY-164?page=all ] Jean-Sebastien Delfino updated TUSCANY-164: --- Fix Version: Cpp-current Version: Cpp-current Add encoding of parameter types to Operation Key: TUSCANY-164 URL: http://issues.apache.org/jira/browse/TUSCANY-164 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current The Operation message passed internally requires an encoding of the parameters' types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-97) Read only properties
[ http://issues.apache.org/jira/browse/TUSCANY-97?page=all ] Jean-Sebastien Delfino updated TUSCANY-97: -- Fix Version: Cpp-current Version: Cpp-current Read only properties Key: TUSCANY-97 URL: http://issues.apache.org/jira/browse/TUSCANY-97 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Priority: Trivial Fix For: Cpp-current Read-only properties are not fully supported, and should be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-339) calculator sample improvements
[ http://issues.apache.org/jira/browse/TUSCANY-339?page=all ] Jean-Sebastien Delfino updated TUSCANY-339: --- Fix Version: Cpp-current Version: Cpp-current calculator sample improvements -- Key: TUSCANY-339 URL: http://issues.apache.org/jira/browse/TUSCANY-339 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Environment: Windows Reporter: Ed Slattery Assignee: Ed Slattery Priority: Minor Fix For: Cpp-current Attachments: calc.patch Calculator sample has old env vars, and doesnt describe scagen very well. Also add +,- and . as useful characters in numerics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-100) Group/AttributeGroup support
[ http://issues.apache.org/jira/browse/TUSCANY-100?page=all ] Jean-Sebastien Delfino updated TUSCANY-100: --- Fix Version: Cpp-current Version: Cpp-current Group/AttributeGroup support Key: TUSCANY-100 URL: http://issues.apache.org/jira/browse/TUSCANY-100 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current groups and attribute groups are missing from the C++ implementation. An easy way to implement them might be to pre-parse the schema, and insert the group into its correct locations before really parsing the file . This task covers finding the best way to support groups, and implementing it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-99) Big Numbers
[ http://issues.apache.org/jira/browse/TUSCANY-99?page=all ] Jean-Sebastien Delfino updated TUSCANY-99: -- Fix Version: Cpp-current Version: Cpp-current Big Numbers --- Key: TUSCANY-99 URL: http://issues.apache.org/jira/browse/TUSCANY-99 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current The java SDO supports BigDecimal and BigInteger. This task covers defining wether they add value to a C++ interface or add interoperability possiblilities, and implementing any support required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-101) Performance analysis and improvements
[ http://issues.apache.org/jira/browse/TUSCANY-101?page=all ] Jean-Sebastien Delfino updated TUSCANY-101: --- Fix Version: Cpp-current Version: Cpp-current Performance analysis and improvements - Key: TUSCANY-101 URL: http://issues.apache.org/jira/browse/TUSCANY-101 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current There are a number of areas which are central to the SDO core, and need to be analysed to see if they are optimal. These include: The parser - particularly where it needs to traverse the type system. The data access at the centre of the dataobject, and the conversion from property index to property name. Change summary, and the effect of storing lists for multi-valued items. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-91) Replace Tuscany-model.config with import.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-91?page=all ] Jean-Sebastien Delfino updated TUSCANY-91: -- Fix Version: Cpp-current Version: Cpp-current Replace Tuscany-model.config with import.wsdl --- Key: TUSCANY-91 URL: http://issues.apache.org/jira/browse/TUSCANY-91 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Priority: Minor Fix For: Cpp-current Sync with Java SCA method of defining wsdls -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-90) SCA Remotable binding
[ http://issues.apache.org/jira/browse/TUSCANY-90?page=all ] Jean-Sebastien Delfino updated TUSCANY-90: -- Fix Version: Cpp-current Version: Cpp-current SCA Remotable binding - Key: TUSCANY-90 URL: http://issues.apache.org/jira/browse/TUSCANY-90 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current Add support for remotable interfaces ans pass-by-value semantics -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-98) Date/Time support
[ http://issues.apache.org/jira/browse/TUSCANY-98?page=all ] Jean-Sebastien Delfino updated TUSCANY-98: -- Fix Version: Cpp-current Version: Cpp-current Date/Time support - Key: TUSCANY-98 URL: http://issues.apache.org/jira/browse/TUSCANY-98 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current The Java SDO carries a large amount of support for various date/time classes. The C++ interface works with a time_t. This task covers planning wether date/time functions are really added value to a C++ developer, and adding any support which is deemed necessary as a result of the analysis. The work should be based on consistency with the java specification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-89) Provide Axis2C bindings
[ http://issues.apache.org/jira/browse/TUSCANY-89?page=all ] Jean-Sebastien Delfino updated TUSCANY-89: -- Fix Version: Cpp-current Version: Cpp-current Provide Axis2C bindings --- Key: TUSCANY-89 URL: http://issues.apache.org/jira/browse/TUSCANY-89 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current Provide support for Axis2 ws bindings using Axis2C -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-113) Provide Windows batch file to run SCA C++ test
[ http://issues.apache.org/jira/browse/TUSCANY-113?page=all ] Jean-Sebastien Delfino updated TUSCANY-113: --- Fix Version: Cpp-current Version: Cpp-current Provide Windows batch file to run SCA C++ test -- Key: TUSCANY-113 URL: http://issues.apache.org/jira/browse/TUSCANY-113 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Priority: Minor Fix For: Cpp-current Add a scatest.bat to perform the same function as scatest.sh does on linux -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-95) TYpesafe SDO interface
[ http://issues.apache.org/jira/browse/TUSCANY-95?page=all ] Jean-Sebastien Delfino updated TUSCANY-95: -- Fix Version: Cpp-current Version: Cpp-current TYpesafe SDO interface -- Key: TUSCANY-95 URL: http://issues.apache.org/jira/browse/TUSCANY-95 Project: Tuscany Type: Task Components: C++ SDO Versions: Cpp-current Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current The C++ SDO has no typesafe interface at present. There is seed code to show how a typesafe interface might be developed related to a DataFactory. This task covers documenting the proposed solution, discussion of the pros and cons, then implementing the resulting solution , either based on the seed code, or from scratch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-81) Make .componentType side files optional for JavaScript components
[ http://issues.apache.org/jira/browse/TUSCANY-81?page=all ] ant elder updated TUSCANY-81: - Fix Version: Java-Mx (was: Java-M1-tentative) Assign To: (was: ant elder) Make .componentType side files optional for JavaScript components - Key: TUSCANY-81 URL: http://issues.apache.org/jira/browse/TUSCANY-81 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Versions: Java-M1-tentative Reporter: ant elder Priority: Minor Fix For: Java-Mx Currently JavaScript components require a .componentType side file. Thats because currently its the only way of defining the interface being implemented by the component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-72) Improve handling of Axis exceptions
[ http://issues.apache.org/jira/browse/TUSCANY-72?page=all ] Jean-Sebastien Delfino updated TUSCANY-72: -- Fix Version: Cpp-current Version: Cpp-current Improve handling of Axis exceptions --- Key: TUSCANY-72 URL: http://issues.apache.org/jira/browse/TUSCANY-72 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current Axis exceptions should be caught and handled to give better feedback on the causes of problems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-155) Move to JSR 47 logging
[ http://issues.apache.org/jira/browse/TUSCANY-155?page=all ] Jean-Sebastien Delfino updated TUSCANY-155: --- Fix Version: Java-Mx Version: Java-Mx Move to JSR 47 logging -- Key: TUSCANY-155 URL: http://issues.apache.org/jira/browse/TUSCANY-155 Project: Tuscany Type: Improvement Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Priority: Minor Fix For: Java-Mx We should move from our custom logging framework to java.util.logging -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-204) DAS should allow for convention to reduce need for configuration
[ http://issues.apache.org/jira/browse/TUSCANY-204?page=all ] Jean-Sebastien Delfino updated TUSCANY-204: --- Fix Version: Java-Mx Version: Java-Mx DAS should allow for convention to reduce need for configuration Key: TUSCANY-204 URL: http://issues.apache.org/jira/browse/TUSCANY-204 Project: Tuscany Type: New Feature Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx DAS should allow users to avoid configuration items by following specific conventions. For example, in the absence of configuration specifying the prmary key for a table, the DAS could assume that a table column named ID is the PK. Taking this a step further, in the absence of config info specifying a relationship, the DAS could assume any column named _ID is a foreign key key to table . A column named _c could be assumed to be a collision column while _v could be considered a version column. This feature will enable a large set of DAS clients to operate without specifying any separate configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-144) Need to provide a better naming scheme for relationships
[ http://issues.apache.org/jira/browse/TUSCANY-144?page=all ] Jean-Sebastien Delfino updated TUSCANY-144: --- Fix Version: Java-Mx Version: Java-Mx Need to provide a better naming scheme for relationships Key: TUSCANY-144 URL: http://issues.apache.org/jira/browse/TUSCANY-144 Project: Tuscany Type: Improvement Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Priority: Minor Fix For: Java-Mx The current naming scheme allows users to specify a relationship name in the relationship defintion section of the config file. Users tend to name this in terms of their view of the relationship. For example, if I am trying to describe a relationship between Company and EmployeeOfTheMonth then I might logically name the relationship Company-EOM. Then I would expect to be able to use the dynamic SDO apis to traverse this relationship like this: DataObject empOfTheMonth = aCompany.getDataObject(Company-EOM) Currently, the situation is such that the name really applies to the path on the relationship from the parent to the child. That is , the name refers to the direction from the parent row (row holding the PK) to the child (row holding the FK). The DAS then generates a name for the other side of the relationship by taking name and adding _opposite. The reult for the example above is that the name for the side of the relationship from Company to Employee of the month is actually Company-EOM_opposite which is very confusing. The current convention works well for mostof the time but we may want to allow the user to name both sides of the relationship and provide documentaiton about what is actually being named. OneToOneRelationshipTests.test3 illustrates this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-250) Need better error message when config entered incorrectly
[ http://issues.apache.org/jira/browse/TUSCANY-250?page=all ] Jean-Sebastien Delfino updated TUSCANY-250: --- Fix Version: Java-Mx Version: Java-Mx Need better error message when config entered incorrectly - Key: TUSCANY-250 URL: http://issues.apache.org/jira/browse/TUSCANY-250 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Incorrect config innformation often results in EMF index out of bounds exceptions. We should prevent these errors if possible by recognizing invalid config and throwing an meaningful exception. ExceptionsTests.test_4() demonstrates this problem -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-69) Provide an extension API in Tucany's SDO implementation to support environments with multiple classloaders
[ http://issues.apache.org/jira/browse/TUSCANY-69?page=all ] Jean-Sebastien Delfino updated TUSCANY-69: -- Fix Version: Java-Mx Version: Java-Mx Provide an extension API in Tucany's SDO implementation to support environments with multiple classloaders -- Key: TUSCANY-69 URL: http://issues.apache.org/jira/browse/TUSCANY-69 Project: Tuscany Type: Sub-task Components: Java SDO Implementation Versions: Java-Mx Reporter: Jeremy Boynes Fix For: Java-Mx Provide a documented API in Tuscany's SDO implementation that provides an interface to SDO for applications that utilize multiple classloaders. Remove any implicit assumptions on the Thread context ClassLoader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-278) DAS sometimes obtaining Connection objects twice
[ http://issues.apache.org/jira/browse/TUSCANY-278?page=all ] Jean-Sebastien Delfino updated TUSCANY-278: --- Fix Version: Java-Mx Version: Java-Mx DAS sometimes obtaining Connection objects twice Key: TUSCANY-278 URL: http://issues.apache.org/jira/browse/TUSCANY-278 Project: Tuscany Type: Improvement Components: Java DAS RDB Versions: Java-Mx Reporter: Brent Daniel Priority: Minor Fix For: Java-Mx When a CommandGroup is used, the DAS will obtain Connection objects twice. At initialization, individual runtime command objects will be created, which will cause each of them to obtain a Connection. Then, when the user requests a Command, the CommandGroup will obtain the Connection and set it on the Command object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-263) SDO2Java generator should allow multiple files or directories to be specified
[ http://issues.apache.org/jira/browse/TUSCANY-263?page=all ] Jean-Sebastien Delfino resolved TUSCANY-263: Resolution: Duplicate SDO2Java generator should allow multiple files or directories to be specified - Key: TUSCANY-263 URL: http://issues.apache.org/jira/browse/TUSCANY-263 Project: Tuscany Type: Bug Components: Java SDO Tools Reporter: Jean-Sebastien Delfino Currently, only one XSD or WSDL file can be specified for the whole project, or only one directory, forcing the user to put all his WSDL and XSD files in that directory. This is a significant limitation. The tool should allow the user to specify a list of files or a list or directories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-336) After comonent is stopped, can still locateService
[ http://issues.apache.org/jira/browse/TUSCANY-336?page=all ]
Jean-Sebastien Delfino resolved TUSCANY-336:
Resolution: Fixed
Assign To: Jim Marino
This looks very similar to another issue that Jim fixed last week. Could you
please verify that this is now fixed on the latest code? Thanks!
After comonent is stopped, can still locateService
--
Key: TUSCANY-336
URL: http://issues.apache.org/jira/browse/TUSCANY-336
Project: Tuscany
Type: Bug
Environment: Win2000
Reporter: Yang Lei
Assignee: Jim Marino
I was using the following code to stop a context ( component)
public void stopModule(String name) {
System.out.println(action stop module);
Context context = getContext(name);
display(context);
if (context!=null)
{
if (context.getLifecycleState() == context.STOPPED)
System.out.println(The module has already
stopped.);
else
{
System.out.println(Stopping module...);
context.stop();
}
}else
{
System.out.println(The module is not available...);
}
display(context);
}
I can still locate the service after the context (component) is stopped:
my service starting
The next holiday is: Mon May 29 00:00:00 EDT 2006
...Stop MyService in Client1
action stop module
Context [MyServiceComponent] in state [RUNNING]
Stopping module...
Context [MyServiceComponent] in state [STOPPED]
The next holiday is: Mon May 29 00:00:00 EDT 2006
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-346) Add note about regular maven warnings during build
[ http://issues.apache.org/jira/browse/TUSCANY-346?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-346: -- Assign To: Jean-Sebastien Delfino Add note about regular maven warnings during build -- Key: TUSCANY-346 URL: http://issues.apache.org/jira/browse/TUSCANY-346 Project: Tuscany Type: Improvement Components: Build System Versions: Java-M1 Environment: all Reporter: Simon Laws Assignee: Jean-Sebastien Delfino jsdefino - We're getting this question all the time whenever ibiblio gets slow or just times out. We need a big note in the build instructions to warn people about that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-353) The helloword sidefile (with no annotations) test I created does not read the default value from the side files
[ http://issues.apache.org/jira/browse/TUSCANY-353?page=all ] Jean-Sebastien Delfino updated TUSCANY-353: --- Fix Version: Java-M1-tentative Version: Java-M1-tentative (was: Java-M1) I think that this is not critical to fix for our M1. Leaving it in the M1-tentative category for now, if anyone volunteers to fix it soon we may still be able to get it fixed for M1. The helloword sidefile (with no annotations) test I created does not read the default value from the side files Key: TUSCANY-353 URL: http://issues.apache.org/jira/browse/TUSCANY-353 Project: Tuscany Type: Bug Versions: Java-M1-tentative Environment: Fedora Core 5 Reporter: Simon Laws Fix For: Java-M1-tentative Attachments: helloworld2.tar I attached the sample as a tar file. It looks like this... hellworld2 src main java - where the java source files go org sample helloworld HelloWorldService.java HelloWorldServiceImpl.java HelloWorldClient.java resource - where data and configuration files go org sample helloworld HelloWorldServiceImpl.componentType sca.module test java - where the files used to test the above source files go target classes - where the compile class files will go compile.sh run.sh If you put this in a directory alongside the tuscany project and you have populated target/j2se then compile.sh and run.sh should work, i.e. somedir helloworld2 tuscany java target j2se lots of jars when I run the test the property value null is returned and I was expecting the default value from the side file so I expect I have done something stupid! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-351) New FAQ Entry: Getting a null pointer for HelloWorldWeb
[ http://issues.apache.org/jira/browse/TUSCANY-351?page=all ] Jean-Sebastien Delfino updated TUSCANY-351: --- Fix Version: Java-M1 Assign To: haleh mahbod New FAQ Entry: Getting a null pointer for HelloWorldWeb --- Key: TUSCANY-351 URL: http://issues.apache.org/jira/browse/TUSCANY-351 Project: Tuscany Type: Improvement Versions: Java-M1 Environment: all Reporter: Simon Laws Assignee: haleh mahbod Fix For: Java-M1 If you get null pointers for all of the samples that use Tomcat then check that the Host element in the conf/server.xml has been updated in accordance with the instructions here: java/sampleSetup.htm. For some reason the xslt script that does this from the build.xml failed on my fedora setup and didn't report and error. I will chase it a bit further and raise a seaprate JIRA if it seems to be a bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-346) Add note about regular maven warnings during build
[ http://issues.apache.org/jira/browse/TUSCANY-346?page=all ] Jean-Sebastien Delfino updated TUSCANY-346: --- Fix Version: Java-M1 Add note about regular maven warnings during build -- Key: TUSCANY-346 URL: http://issues.apache.org/jira/browse/TUSCANY-346 Project: Tuscany Type: Improvement Components: Build System Versions: Java-M1 Environment: all Reporter: Simon Laws Assignee: Jean-Sebastien Delfino Fix For: Java-M1 jsdefino - We're getting this question all the time whenever ibiblio gets slow or just times out. We need a big note in the build instructions to warn people about that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-350) Make the useful testing/tomcat/build.xml more readily available.
[ http://issues.apache.org/jira/browse/TUSCANY-350?page=all ] Jean-Sebastien Delfino updated TUSCANY-350: --- Fix Version: Java-M1-tentative Version: Java-M1-tentative (was: Java-Mx) Assign To: Raymond Feng Raymond, could you please investigate and find which targets in this build.xml are still useful now we have our distribution build in place? Thanks. Make the useful testing/tomcat/build.xml more readily available. Key: TUSCANY-350 URL: http://issues.apache.org/jira/browse/TUSCANY-350 Project: Tuscany Type: Improvement Components: Java SCA Samples Versions: Java-M1-tentative Environment: all Reporter: Simon Laws Assignee: Raymond Feng Priority: Minor Fix For: Java-M1-tentative The very useful ant script that performs various configuration steps has a few real gems that could be wrapped to to make them more obvious targets for new users to use, e.g. project name=useful targets default=prepareForHelloWorld basedir='.' target name=prepareForHelloWorld ant antfile=testing/tomcat/build.xml target=j2se property name=tuscany.acceptance.target.dir value=target/ /ant /target target name=runHelloWorld java classname=org.apache.tuscany.samples.helloworldmc.HelloWorldClient fork=true jvmarg value=-Djava.ext.dirs=./target/j2se/ classpath pathelement location=samples/helloworld/helloworldmc/target/helloworldmc-SNAPSHOT.jar / /classpath /java /target /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-321) Injection of references into a simple POJO without annotations does not work
[ http://issues.apache.org/jira/browse/TUSCANY-321?page=all ] Jean-Sebastien Delfino updated TUSCANY-321: --- Fix Version: (was: Java-M1) Injection of references into a simple POJO without annotations does not work Key: TUSCANY-321 URL: http://issues.apache.org/jira/browse/TUSCANY-321 Project: Tuscany Type: Bug Components: Java SCA Core, Java SCA POJO Container Versions: Java-Mx Reporter: Jean-Sebastien Delfino Assignee: Jim Marino Priority: Minor Fix For: Java-Mx Attachments: undefreference.zip Injection of references into a simple POJO without annotations does not work. Create a simple POJO component without any SCA annotations. On the POJO declare public fields or public setters for the component's references. Wire the references in sca.module. When the module starts you will get the following exception: [surefire] Running calculator.CalculatorTestCase [surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.015 sec [surefire] [surefire] testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.999 sec ERROR! org.apache.tuscany.model.assembly.AssemblyInitializationException: Undefined reference [addService] at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:162) at org.apache.tuscany.model.assembly.impl.CompositeImpl.initialize(CompositeImpl.java:194) at org.apache.tuscany.model.assembly.impl.ModuleImpl.initialize(ModuleImpl.java:85) at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:135) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:156) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:36) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:285) at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:201) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:366) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at
[jira] Updated: (TUSCANY-61) ?WSDL on WS binding entryPoints fails
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ] Jean-Sebastien Delfino updated TUSCANY-61: -- Fix Version: Java-Mx (was: Java-M1) Version: Java-Mx (was: Java-M1) Ok, looks like this is really flaky at this point. I recommend that we look at this again after M1. After all it's easy to publish your own WSDL, you just need to put it under the webapp context to allow people to download it. If we had support for entry points without a pre-authored or pre-generated WSDL then it would be important to have this feature, but we don't support this in M1 so we always have the WSDL file handy, and again it's easy to publish it in your web app. ?WSDL on WS binding entryPoints fails - Key: TUSCANY-61 URL: http://issues.apache.org/jira/browse/TUSCANY-61 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: Java-Mx Reporter: ant elder Assignee: Raymond Feng Fix For: Java-Mx Appending ?WSDL to the url of a entryPoint with a WS binding should return the WSDL, but it fails, first as its missing the xmlschema jar then once thats available with the following exception. Looks like its trying to gen a new wsdl but it should be able to use the definition from the model. org.apache.axis2.AxisFault: no scheam found for the service; nested exception is: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:373) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:322) at org.apache.axis2.transport.http.ListingAgent.listService(ListingAgent.java:469) at org.apache.axis2.transport.http.ListingAgent.handle(ListingAgent.java:393) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doGet(WebServiceEntryPointServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService2WOM.generateWOM(AxisService2WOM.java:86) at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:362) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-257?page=all ] Jean-Sebastien Delfino updated TUSCANY-257: --- Fix Version: Java-Mx (was: Java-M1) Version: Java-Mx recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 --- Key: TUSCANY-257 URL: http://issues.apache.org/jira/browse/TUSCANY-257 Project: Tuscany Type: Bug Components: Java SDO Tools Versions: Java-Mx Environment: all Reporter: Paul Golick Fix For: Java-Mx Attachments: newFiles.jar, patchInterface2JavaGenerator.txt, patchUpdated.txt Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and java.lang.reflect.Type that were added in Java 5 for generics. It appears that the portion of Interface2JavaGenerator that uses ParameterizedType and Type is not needed for Java 1.4 classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Site Map
How about a site map for the Tuscany Web Site? There's lots of good information there, some of which is hard to find Any tips on how this are managed? What's the potential for automation? Would we want to point to content in the Wiki, or just stable content in the website? I'm happy to put some effort into this, but I've never done one before, so please share your experiences. Thoughts? -- Best Regards Kelvin Goodson
Cleaning up JIRA issues for our M1 release
Hi all, I spent some time today cleaning up and organizing our JIRA issues. I organized them in different categories. - Java-M1: I'd like to see the issues in this category fixed for our M1 release. Some of these issues are related to our web site, so they should not affect the production, test and validation of our distribution. I think that we can continue to work on the documentation that will go on the web site after we have finalized the distribution and while some of us are validating it. - Java-M1-tentative It was not clear to me that these issues should be fixed for M1. I need your input on these ones. In general it would be cool to have them fixed for M1, but they shouldn't really block us and are good candidates for readme / last minute release notes. - Java-Mx Not in the M1 release. - Cpp-current Issues on our C++ components (not in M1 either). Could you please take a look at the JIRA issues that you are interested in, and make sure that you agree with how I categorized them. If you don't agree then let's discuss the specifics on the dev list and/or our next IRC chat (May-11 at 9am PDT I'll send the details in a separate email). Lastly, if some of these bugs are already fixed, please don't hesitate to close them :) Thanks! -- Jean-Sebastien
[jira] Commented: (TUSCANY-282) Add to our build the production of a distribution for our release
[ http://issues.apache.org/jira/browse/TUSCANY-282?page=comments#action_12379057 ] ant elder commented on TUSCANY-282: --- A couple of changes to enable exposing JavaScript/E4X components with web service entryPoints: - the container-rhino jar needs to be included in the tomcat server/lib directory and the js and xbean jars need to be included in the tomcat common/lib. - the StAX jars need to be moved from Tomcat server/lib to common/lib, thats stax-api and wstx-asl. Add to our build the production of a distribution for our release - Key: TUSCANY-282 URL: http://issues.apache.org/jira/browse/TUSCANY-282 Project: Tuscany Type: New Feature Components: Build System Versions: Java-M1 Reporter: Jean-Sebastien Delfino Assignee: Raymond Feng Priority: Critical Fix For: Java-M1 Attachments: dist-patch-v1.diff, tuscany-distribution.tar.gz, tuscany-distribution.zip, tuscany-distribution2.tar.gz We need to add to our build the production of a distribution Zip for our release. The distribution should include a preconfigured Tomcat. See discussion on our wiki page at http://wiki.apache.org/ws/Tuscany/Tasks and a proposal on the dev list at http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL PROTECTED] Jeremy and Raymond are volunteering to work on this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Tuscany IRC chat - Thursday May 11
Hi folks! I would like to propose a Tuscany developer chat on Wednesday, May 11, at: 16:00 GMT, 17:00 BST, 09:00am PDT, 12:00pm EDT, 21:30 Bangalore, to cover the remaining JIRA issues for our M1 release. We should also start to discuss what people want to present or demo at JavaOne next week. Same place as usual, channel #tuscany on the freenode IRC network (use server irc.freenode.net). Please join us! Thanks, -- Jean-Sebastien
[jira] Commented: (TUSCANY-345) Consolidate and check consistency of build and run instructions
[ http://issues.apache.org/jira/browse/TUSCANY-345?page=comments#action_12379068 ] Simon Laws commented on TUSCANY-345: I note that there are build instructions for developers on the web site under /development/java projects This is similar to (and I believe has been derived from) the wiki version at http://wiki.apache.org/ws/Tuscany/GetTuscany/WinXP but omits the screen shots wich is a shame. It also refers to the linux wiki version at http://wiki.apache.org/ws/Tuscany/GetTuscany/Linux. I assume at some point the linux instructions will be migrated to the web site. Can we keep the screen shots? The wiki versions of the instructions make good user build instructions but obviously need to be edited down to match the release package and have things like svn instructions removed. In this case the screen shots are particularly useful. Consolidate and check consistency of build and run instructions --- Key: TUSCANY-345 URL: http://issues.apache.org/jira/browse/TUSCANY-345 Project: Tuscany Type: Improvement Components: Website, Java SCA Samples, Java BigBank Scenario Versions: Java-M1 Environment: Fedora Core 5 Reporter: Simon Laws Assignee: haleh mahbod Fix For: Java-M1 There are several different sets of build instructions, e, g, Website - SCA Installation instructions sampleSetup.htm java/BUILDING.txt, testing/tomcat/readme new wiki Get Tuscany pages. Personally I prefer the format of the last one for users. Should also remove the svn stuff for the binary release though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-228) Maven plugin SDO Gen and WSDL2SDO tools do not allow individual wsdl files to be specified.
[ http://issues.apache.org/jira/browse/TUSCANY-228?page=comments#action_12379069 ] Kapil Katyal commented on TUSCANY-228: -- Hi, I'm working on doing the same thing for the tuscany-sdo-plugin using Rick's changes as a template. Will hopefully get a patch submitted today. Thanks, Kapil Maven plugin SDO Gen and WSDL2SDO tools do not allow individual wsdl files to be specified. Key: TUSCANY-228 URL: http://issues.apache.org/jira/browse/TUSCANY-228 Project: Tuscany Type: Bug Components: Java SCA Tools, Java SDO Tools Versions: Java-M1-tentative Environment: all Reporter: Rick Rineholt Assignee: Rick Rineholt Fix For: Java-M1-tentative For Maven plugins tuscany-sdo-plugin tuscany-sca-plugin there doesn't seem to be a way to specify individual wsdl files to work on. Repeating these blocks only seems to run the last one. Specifying a directory is not optimal either since: 1) you may not want to process all wsdl files there. 2) you may want to specify with each different options. (i.e. javapackage etc) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[PHP] PHP wish list?
Pete has recently followed the java team's lead and initiated a to do/wish list up on the Tuscany wiki for the C++ implementation effort. The PHP/SDO PECL project needs to do the same thing but we don't have a wiki over at PECL at the moment. It would seem sensible (to me at least) if we borrow a page of the project Tuscany wiki for this purpose as many of the same items will appear for PHP as for Java and C++. We would then link this wiki page from our PHP/SDO PECL project page ( http://pecl.php.net/package/sdo) and vice versa. Does anyone have any objections to me doing this? Regards Simon
[jira] Commented: (TUSCANY-343) WSDL2JavaGenerator fails if the wsdl have an import for the XSD types
[ http://issues.apache.org/jira/browse/TUSCANY-343?page=comments#action_12379074 ] Michael John Edwards commented on TUSCANY-343: -- I found the last comment from Jean-Sebastien surprising - I am not expecting the tool to process the imported XSD Surely you DO want the tool to process the imported XSD? Why force the user to go find the XSD and use a tool to generate Java from it separately. With a large complex WSDL this could be a nightmare. I can understand a temporary limitation while we build up the function, but not a permanent solution with this limitation. WSDL2JavaGenerator fails if the wsdl have an import for the XSD types - Key: TUSCANY-343 URL: http://issues.apache.org/jira/browse/TUSCANY-343 Project: Tuscany Type: Bug Components: Java SCA Tools Versions: Java-M1 Environment: Windows XP Reporter: Jojo Joseph Assignee: Frank Budinsky Priority: Critical Fix For: Java-M1 Attachments: testing-interop-uddi.zip I have a WSDL (uddi_api_v3_portType.wsdl) which import the types schema as : types xsd:schema targetNamespace=urn:uddi-org:api_v3_portType xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:import namespace=urn:uddi-org:api_v3 schemaLocation=uddi_v3.xsd/ /xsd:schema /types If I specify this WSDL as a parameter to the tuscany-sca-plugin for java code generation, it fails with the following exception : [INFO] Generating Java service interfaces from C:\Project\Tuscany\ws0508\testing-interop-uddi\src\main\resources\wsdl\test.wsdl java.lang.NullPointerException at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:191) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:161) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:132) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) As a side note I would like to mention that if I specify the WSDL as a parameter to tuscany-sdo-plugin, then that too fails with the same exception. But there is a work-around for SDO code generation as I can specify the XSD file containing the types schema as the parameter to the tuscany-sdo-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-343) WSDL2JavaGenerator fails if the wsdl have an import for the XSD types
[ http://issues.apache.org/jira/browse/TUSCANY-343?page=comments#action_12379080 ] Frank Budinsky commented on TUSCANY-343: Sorry folks, I should have added a comment earlier. I've been trying to commit the fix for this since yesterday afternoon but failing because of the problems with svn.apache.org. I will resolve this issue as soon as I can commit the fix. And yes, the XSDHelper.define() method should (and does) process imported schemas. WSDL2JavaGenerator fails if the wsdl have an import for the XSD types - Key: TUSCANY-343 URL: http://issues.apache.org/jira/browse/TUSCANY-343 Project: Tuscany Type: Bug Components: Java SCA Tools Versions: Java-M1 Environment: Windows XP Reporter: Jojo Joseph Assignee: Frank Budinsky Priority: Critical Fix For: Java-M1 Attachments: testing-interop-uddi.zip I have a WSDL (uddi_api_v3_portType.wsdl) which import the types schema as : types xsd:schema targetNamespace=urn:uddi-org:api_v3_portType xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:import namespace=urn:uddi-org:api_v3 schemaLocation=uddi_v3.xsd/ /xsd:schema /types If I specify this WSDL as a parameter to the tuscany-sca-plugin for java code generation, it fails with the following exception : [INFO] Generating Java service interfaces from C:\Project\Tuscany\ws0508\testing-interop-uddi\src\main\resources\wsdl\test.wsdl java.lang.NullPointerException at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:191) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:161) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:132) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) As a side note I would like to mention that if I specify the WSDL as a parameter to tuscany-sdo-plugin, then that too fails with the same exception. But there is a work-around for SDO code generation as I can specify the XSD file containing the types schema as the parameter to the tuscany-sdo-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-82) Enable using E4X to access the message in a JavaScript component
[ http://issues.apache.org/jira/browse/TUSCANY-82?page=all ] ant elder updated TUSCANY-82: - Fix Version: Java-M1 (was: Java-M1-tentative) Priority: Major (was: Minor) Enable using E4X to access the message in a JavaScript component Key: TUSCANY-82 URL: http://issues.apache.org/jira/browse/TUSCANY-82 Project: Tuscany Type: Improvement Components: Java SCA JavaScript Container Versions: Java-M1-tentative Reporter: ant elder Assignee: ant elder Fix For: Java-M1 E4X is an extension to JavaScript for processing XML. It would be really nice if this could be used with SCA JavaScript components so that wiring up JavaScript components to WS entryPoints or externalServices gives access to the SOAP Body payload via E4X. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-351) New FAQ Entry: Getting a null pointer for HelloWorldWeb
[ http://issues.apache.org/jira/browse/TUSCANY-351?page=comments#action_12379081 ] Simon Laws commented on TUSCANY-351: I did a bit more investigation as to why my test server was not being set up properly. Basically is was user error but useful to know anyhow. The build/test instructions say (somewhere!) that to run the hello worl tomcat test you got to testing/tomcat and run mvn. When I do this everything works fine. Result happiness. However for some reason when I was playing at creating my own examples I ignored this instruction and used the prepareTomcat ant target that the maven pom refers to. This fails to run the XSLT script as it can't find XslpLiaison and TraXLiaison. So maven must set up some environment that makes this work. The twist is that there is a flag in the ant file that only allows it to run the XSLT conversion once based on the presence of the service.xml.original file (the backup copy). Hence when you run ant again no errors are reported and all looks well, except that the tomcat configuration is incorrect. New FAQ Entry: Getting a null pointer for HelloWorldWeb --- Key: TUSCANY-351 URL: http://issues.apache.org/jira/browse/TUSCANY-351 Project: Tuscany Type: Improvement Versions: Java-M1 Environment: all Reporter: Simon Laws Assignee: haleh mahbod Fix For: Java-M1 If you get null pointers for all of the samples that use Tomcat then check that the Host element in the conf/server.xml has been updated in accordance with the instructions here: java/sampleSetup.htm. For some reason the xslt script that does this from the build.xml failed on my fedora setup and didn't report and error. I will chase it a bit further and raise a seaprate JIRA if it seems to be a bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-61) ?WSDL on WS binding entryPoints fails
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ] Raymond Feng updated TUSCANY-61: Attachment: patch.txt Hi, Ant. I fixed the WSDL problem (we can now display the WSDL but the endpoint address is still wrong). Please review the patch and apply. Thanks, Raymond ?WSDL on WS binding entryPoints fails - Key: TUSCANY-61 URL: http://issues.apache.org/jira/browse/TUSCANY-61 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: Java-Mx Reporter: ant elder Assignee: Raymond Feng Fix For: Java-Mx Attachments: patch.txt Appending ?WSDL to the url of a entryPoint with a WS binding should return the WSDL, but it fails, first as its missing the xmlschema jar then once thats available with the following exception. Looks like its trying to gen a new wsdl but it should be able to use the definition from the model. org.apache.axis2.AxisFault: no scheam found for the service; nested exception is: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:373) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:322) at org.apache.axis2.transport.http.ListingAgent.listService(ListingAgent.java:469) at org.apache.axis2.transport.http.ListingAgent.handle(ListingAgent.java:393) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doGet(WebServiceEntryPointServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService2WOM.generateWOM(AxisService2WOM.java:86) at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:362) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [PHP] PHP wish list?
This is good since we get a consistent view of how implementation for SDO is progressing in different languages. On 5/11/06, Simon Laws [EMAIL PROTECTED] wrote: Pete has recently followed the java team's lead and initiated a to do/wish list up on the Tuscany wiki for the C++ implementation effort. The PHP/SDO PECL project needs to do the same thing but we don't have a wiki over at PECL at the moment. It would seem sensible (to me at least) if we borrow a page of the project Tuscany wiki for this purpose as many of the same items will appear for PHP as for Java and C++. We would then link this wiki page from our PHP/SDO PECL project page ( http://pecl.php.net/package/sdo) and vice versa. Does anyone have any objections to me doing this? Regards Simon
[jira] Assigned: (TUSCANY-354) Celtix/JMS Sample needed
[ http://issues.apache.org/jira/browse/TUSCANY-354?page=all ] Daniel Kulp reassigned TUSCANY-354: --- Assign To: Daniel Kulp Celtix/JMS Sample needed Key: TUSCANY-354 URL: http://issues.apache.org/jira/browse/TUSCANY-354 Project: Tuscany Type: Improvement Components: Java SCA Samples Versions: Java-M1 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: Java-M1 The Celtix binding support XML over JMS. It would be nice to have a sample that shows using that instead of SOAP/HTTP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Java Doc
Will the distribution build also generate and publish java doc? Thanks, --Kevin
Re: Java Doc
Just saw the JIRA for this ... T-310 Kevin Williams wrote: Will the distribution build also generate and publish java doc? Thanks, --Kevin
[jira] Updated: (TUSCANY-317) Java SCA Groovy Container
[ http://issues.apache.org/jira/browse/TUSCANY-317?page=all ] Meeraj Kunnumpurath updated TUSCANY-317: Attachment: container.groovy.zip Refactored to use the extension support classes from core. Ta Java SCA Groovy Container - Key: TUSCANY-317 URL: http://issues.apache.org/jira/browse/TUSCANY-317 Project: Tuscany Type: New Feature Versions: Java-Mx Reporter: Meeraj Kunnumpurath Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-Mx Attachments: container.groovy.zip, container.groovy.zip SCA Container for running Groovy scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-358) TypeHelper.getType(Class ...) either returns unexpected Type or throws ClassCastException for java .lang.String or other simple java types
[ http://issues.apache.org/jira/browse/TUSCANY-358?page=comments#action_12379129 ] Frank Budinsky commented on TUSCANY-358: 1) you shouldn't be touching XMLTypePackage or any other EMF things directly. If you stick to the SDO API, this can't happen. 2) This is not well defined in the spec, but I added support to return the most appropriate commonj.sdo built-in type for the simple Java types - according to the tables on pg.69-71 of the spec. I'll commit the change as soon as svn.apache.org is up again. TypeHelper.getType(Class ...) either returns unexpected Type or throws ClassCastException for java .lang.String or other simple java types -- Key: TUSCANY-358 URL: http://issues.apache.org/jira/browse/TUSCANY-358 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M1-tentative Reporter: Raymond Feng Assignee: Frank Budinsky Priority: Critical Fix For: Java-M1-tentative I ran into two problems: 1) If I happens to initialize EMF XMLTypePackage, TypeHelper.getType(String.class) throws a ClassCastException java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EDataTypeImpl incompatible with commonj.sdo.Type at org.apache.tuscany.sdo.helper.TypeHelperImpl.getType(TypeHelperImpl.java:92) 2) Otherwise I received [EMAIL PROTECTED] (name: LangType) (instanceClassName: java.lang.String) (serializable: true) and the EPackage is: [EMAIL PROTECTED] (name: namespace) (nsURI: http://www.w3.org/XML/1998/namespace, nsPrefix: xml) It seems that the SDO spec doesn't well define the behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Specification of model object 'Data Graph Root' for BB sample?
Excuse my ignorance, but I am trying to figure out how the sdo-source for bigbank/account gets generated. I am assuming (of course, I could be wrong) that there should be a specification file somewhere in the sample. So far, I can only find DasAccountConfiguration.xml in bigbank/account/src/main/resources, but I am not sure that is the whole story. Ideally, I would like to add a log summary object that can be returned by the account service to, eg, the web client to query the log. Hopefully this is not too involved and can be done with relatively little modification to the code. Any pointers? Thanks
