Re: Getting started demo
Hi Kevin, thanks for catching that. I'll go and update that link to reflect what latest one that is now in the wiki as mentioned by Simon Laws. - Venkat On 10/16/07, Kevin Williams [EMAIL PROTECTED] wrote: I got to this version of the document from the give it a try link on this page: http://incubator.apache.org/tuscany/sca-java.html On 10/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Kevin Williams wrote: I just went through the excellent getting-started demo ( http://incubator.apache.org/tuscany/sca-overview.data/getting_started_Rest_099_07.pdf ) and I have some feedback. I think this is a very helpful demo and a great place to direct new Tuscany users and developers since it illustrates basic SCA concepts and also some Eclipse integration. I have some feedback regarding my experience with the application but want to check first if there is updated documentation somewhere that I may have missed. Thanks, --Kevin The latest one is: http://incubator.apache.org/tuscany/sca-java-10-incubating-release-summary.data/getting-started-1.0.pdf for use with the Tuscany SCA Java 1.0 release. Perhaps the first feedback is that there's a link to an outdated doc on the Tuscany web site :) Which page did get that link from? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading in Tuscany
Sebastien, I have the second path - (multiple application loaders, one runtime loader) working in my sandbox. I need to write some tests and run all the existing tests before I submit the patch. This works without OSGi, and is a very minor change. For the first path, I am still running under OSGi. At the moment I have four different scenarios (they are all running tests using Axis2 binding to support distributed-OSGi): 1. One Tuscany bundle containing Tuscany + dependencies (one classloader for all the jars referred to in tuscany-sca-manifest.jar). This works and corresponds to CL1 application loader, CL2 runtime loader. 2. Two Tuscany bundles, one containing Tuscany, another containing all 3rd party dependencies(Axis2 etc.). This also works and corresponds to CL1 application loader, and CL2 Tuscany, CL3 3rd party code. 3. Split Tuscany bundles into multiple bundles, one bundle for 3rd party (splitting CL2 into multiple loaders from 2.) 4. Split 3rd party into multiple bundles, one bundle for Tuscany (splitting CL3 into multiple loaders from 2.) 3. and 4. dont work yet. From your note (and Raymond's), I think I should have another scenario before 3. which splits Tuscany into API and runtime. I think that should work without much trouble (ie, CL1 application loader, CL2 Tuscany API loader, CL3 Tuscany runtime loader, CL4 3rd party loader). The tests for multiple application loaders (second path in your note) will be non-OSGi tests - Tuscany OSGi contributions are already tested with multiple bundles and hence multiple classloaders. For the first path, I haven't really considered testing without OSGi - I would probably still continue to work with OSGi to isolate the issues, but try and introduce tests later which run without OSGi. Thank you... Regards, Rajini On 10/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Raymond, Thank you for your reply (and the diagram). The biggest advantage of migrating to an OSGi classloader scheme would be that apart from module isolation, OSGi would also provide module versioning, enabling multiple versions of SCA runtime to exist within a single VM. OSGi would also enable Tuscany modules to be dynamically installed, started and uninstalled. The use of multi-parent classloaders to load modules in Tuscany would require the same amount of code changes as migrating to OSGi, but it would be much harder to implement versioning and dynamic replacement of modules (which come for free with OSGi). The desired visibility of classes that you have listed correspond to the static dependencies that currently exist in the code. The actual visibility that exists today includes arrows from the core modules to extensions, forming a cycle. It is this visibility that is used to locate and start modules dynamically in Tuscany today. There is also an arrow from the Axis library to binding.ws.axis2, through the thread context classloader, and even though not particularly desirable, it is not avoidable. Thank you... Regards, Rajini How about going step by step and: 1. try to bootstrap the tuscany runtime with two classloaders: CL1 application code, CL2 runtime 2. extend to CL1 application code, CL2 Tuscany and SCA APIs, CL3 runtime 3. split the runtime in multiple CLs and on a separate path: 1. try to bootstrap the tuscany runtime with two classloaders: CL1 application code, CL2 runtime 2. split the application code in multiple CLs We could create integration tests for these configurations (not necessarily using OSGi, as these can be built with just plain classloaders IMO), and it would help us identify bad classloader usages, fix them, and detect+prevent classloader issues over time. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1845) SDODataTypeHelper.columnTypeForSDOType() throws RuntimeException for DateTime SDO Type.
[ https://issues.apache.org/jira/browse/TUSCANY-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1845: - Attachment: 1845.patch new test - TypeTests.testTypeMapping(). Matched all types with SDO spec. SDODataTypeHelper.columnTypeForSDOType() throws RuntimeException for DateTime SDO Type. - Key: TUSCANY-1845 URL: https://issues.apache.org/jira/browse/TUSCANY-1845 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Environment: Windows XP, Sun JDK 1.4.2_11 Reporter: Ron Gavlin Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1845.patch When SDODataTypeHelper.columnTypeForSDOType(Type sdoType) is invoked for sdoType DateTime, a RuntimeException is thrown. It appears that SDODataTypes.DATETIME is being initialized incorrectly. There are other constants in SDODataTypes that also appear to be initialized incorrectly. I would suggest that the initialization of all constants in SDODataTypes be reviewed for accuracy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1851) DAS relationship helper API improvement
[ https://issues.apache.org/jira/browse/TUSCANY-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1851: - Attachment: 1851.patch new apis in MappingWrapper and ConfigHelper to accept relationshipName. can be null - in which case relationship name will come from foreign key table name as per convention. new methods - addRelationship(Vector parentNames, Vector childNames, String relationshipName); addRelationship(String parentName, String childName, String relationshipName); new test cases - ProgrammaticConfigTests.testAddRelationshipWithName(), testAddRelationshipMultiKeyWithName() DAS relationship helper API improvement --- Key: TUSCANY-1851 URL: https://issues.apache.org/jira/browse/TUSCANY-1851 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1851.patch support api addRelationship() with relationship name as param -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1845) SDODataTypeHelper.columnTypeForSDOType() throws RuntimeException for DateTime SDO Type.
[ https://issues.apache.org/jira/browse/TUSCANY-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535495 ] Adriano Crestani commented on TUSCANY-1845: --- patch applied under revision 585433 SDODataTypeHelper.columnTypeForSDOType() throws RuntimeException for DateTime SDO Type. - Key: TUSCANY-1845 URL: https://issues.apache.org/jira/browse/TUSCANY-1845 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Environment: Windows XP, Sun JDK 1.4.2_11 Reporter: Ron Gavlin Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1845.patch When SDODataTypeHelper.columnTypeForSDOType(Type sdoType) is invoked for sdoType DateTime, a RuntimeException is thrown. It appears that SDODataTypes.DATETIME is being initialized incorrectly. There are other constants in SDODataTypes that also appear to be initialized incorrectly. I would suggest that the initialization of all constants in SDODataTypes be reviewed for accuracy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1771) Creating JavaDoc for the integration tests listed under sca/itest folder
[ https://issues.apache.org/jira/browse/TUSCANY-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Naveen updated TUSCANY-1771: Attachment: contribution.patch I have attached the patch file which is created for the test /itest/contribution with JavaDoc comments. Creating JavaDoc for the integration tests listed under sca/itest folder -- Key: TUSCANY-1771 URL: https://issues.apache.org/jira/browse/TUSCANY-1771 Project: Tuscany Issue Type: Improvement Components: Java SCA Integration Tests Affects Versions: Java-SCA-0.91 Environment: Windows XP. Java 1.5, Reporter: Naveen Assignee: Venkatakrishnan Fix For: Java-SCA-Next Attachments: contribution.patch, operation-overloading.patch, properties.patch JavaDoc creation is very much necessary. JavaDoc for integration tests helps to describe the intent of the test case. JavaDoc should have details about, what exactly the test case seeks to test, verify or accomplish. It also should specify the the function of each method used in the itest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1771) Creating JavaDoc for the integration tests listed under sca/itest folder
[ https://issues.apache.org/jira/browse/TUSCANY-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mayank sharma updated TUSCANY-1771: --- Attachment: callback-api-javadoc.patch Java document incorporated for callback-api in itest folder Creating JavaDoc for the integration tests listed under sca/itest folder -- Key: TUSCANY-1771 URL: https://issues.apache.org/jira/browse/TUSCANY-1771 Project: Tuscany Issue Type: Improvement Components: Java SCA Integration Tests Affects Versions: Java-SCA-0.91 Environment: Windows XP. Java 1.5, Reporter: Naveen Assignee: Venkatakrishnan Fix For: Java-SCA-Next Attachments: callback-api-javadoc.patch, contribution.patch, operation-overloading.patch, properties.patch JavaDoc creation is very much necessary. JavaDoc for integration tests helps to describe the intent of the test case. JavaDoc should have details about, what exactly the test case seeks to test, verify or accomplish. It also should specify the the function of each method used in the itest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots
XSD2JavaGenerator generates Java identifier with dots
-
Key: TUSCANY-1853
URL: https://issues.apache.org/jira/browse/TUSCANY-1853
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: Windows XP, jre 1.5
Reporter: Cezary Tkaczyk
Hello,
While I'm trying to compile generated by XSD2JavaGenerator Java classes, I've
got such an error:
[javac]
C:\projekty\eclipse-workspace-rbpl-sdo-1.0\REB-Catalog-SDO-Java\src-autogen\pl\esb\impl\EsbFactoryImpl.java:169:
';' expected
[javac] pl.esb.blm.adapter.AdapterFactory
pl.esb.blm.adapter.AdapterFactoryInstance =
pl.esb.blm.adapter.AdapterFactory.INSTANCE;
[javac]^
The problem is: variable identifier cannot contain dots.
The place, where this error appears looks like this:
public static EsbFactoryImpl init()
{
if (instance != null ) return instance;
instance = new EsbFactoryImpl();
// Initialize dependent packages
AdapterFactory AdapterFactoryInstance = AdapterFactory.INSTANCE;
RebFactory RebFactoryInstance = RebFactory.INSTANCE;
pl.raiffeisen.esb.blm.adapter.AdapterFactory
pl.raiffeisen.esb.blm.adapter.AdapterFactoryInstance =
pl.raiffeisen.esb.blm.adapter.AdapterFactory.INSTANCE;
// Create package meta-data objects
instance.createMetaData();
// Initialize created meta-data
instance.initializeMetaData();
// Mark meta-data to indicate it can't be changed
//theEsbFactoryImpl.freeze(); //FB do we need to freeze / should we freeze
return instance;
}
I think the problem is that I have two namespaces of the same suffix:
http://www.esb.pl/blm/adapter
http://www.esb.pl/ods1/adapter
So, generator is trying to avoid the problem creating unique variable name:
pl.esb.blm.adapter.AdapterFactoryInstance
Unfortunately, this is not valid identifier.
Kind Regards,
Czarek
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1854) ConversationID is not set correctly when using Conversational with WS
ConversationID is not set correctly when using Conversational with WS - Key: TUSCANY-1854 URL: https://issues.apache.org/jira/browse/TUSCANY-1854 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Environment: Windows XP Reporter: bjoern When unsing the @Conversational with webservices on serverside the @conversationID is not filled with the vlaue of the SOAP-Header but is filled with a newly generated. The information from the User-List I collected with Simon: Hi, I logged the SOAP messages that go form the WS-Client to the WS-Server and I found out something strange: On client-side a ConverstionID is generated (5756de5a-904e-4834-aaf4-6249d74b702e) and passed using the SOAP-header To the server-side. I expected that the anootated variable @ConversationID public String lConversationID; Is filled with this value (5756de5a-904e-4834-aaf4-6249d74b702e) but it seams to get a differend id (194e6a05-8b80-42e4-a380-5e43fffcdb14). As long as the conversation is up the ID send by the client stays the same (5756de5a-904e-4834-aaf4-6249d74b702e) but on server side I get a differend ID for every call. SOAP LOGFILE: soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header To xmlns=http://www.w3.org/2005/08/addressing; wsa:Address xmlns:wsa=http://www.w3.org/2005/08/addressing; http://localhost:8082/SOULSessionService /wsa:Address wsa:ReferenceParameters xmlns:wsa=http://www.w3.org/2005/08/addressing; axis2ns1:ConversationID xmlns:axis2ns1=http://tuscany.apache.org/xmlns/sca/1.0; 5756de5a-904e-4834-aaf4-6249d74b702e /axis2ns1:ConversationID /wsa:ReferenceParameters /To /soapenv:Header soapenv:Body _ns_:getSessionID xmlns:_ns_=http://SOULSessionService; _ns_:getName/_ns_:getName /_ns_:getSessionID /soapenv:Body /soapenv:Envelope soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getSessionIDResponse xmlns:_ns_=http://SOULSessionService; _ns_:getNameReturn 194e6a05-8b80-42e4-a380-5e43fffcdb14 /_ns_:getNameReturn /_ns_:getSessionIDResponse /soapenv:Body /soapenv:Envelope soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header To xmlns=http://www.w3.org/2005/08/addressing; wsa:Address xmlns:wsa=http://www.w3.org/2005/08/addressing; http://localhost:8082/SOULSessionService /wsa:Address wsa:ReferenceParameters xmlns:wsa=http://www.w3.org/2005/08/addressing; axis2ns2:ConversationID xmlns:axis2ns2=http://tuscany.apache.org/xmlns/sca/1.0; 5756de5a-904e-4834-aaf4-6249d74b702e /axis2ns2:ConversationID /wsa:ReferenceParameters /To /soapenv:Header soapenv:Body _ns_:getSessionID xmlns:_ns_=http://SOULSessionService; _ns_:getName/_ns_:getName /_ns_:getSessionID /soapenv:Body /soapenv:Envelope soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getSessionIDResponse xmlns:_ns_=http://SOULSessionService; _ns_:getNameReturn 4002d850-bc7c-47b0-b866-99d1f3bfdfad /_ns_:getNameReturn /_ns_:getSessionIDResponse /soapenv:Body /soapenv:Envelope
[jira] Created: (TUSCANY-1855) Possible incorrect comparison in SCADomainImpl in the domain-impl project
Possible incorrect comparison in SCADomainImpl in the domain-impl project
-
Key: TUSCANY-1855
URL: https://issues.apache.org/jira/browse/TUSCANY-1855
Project: Tuscany
Issue Type: Bug
Environment: Tuscany SVN revision #585076
Linux
Reporter: Mark Combellack
Priority: Minor
Fix For: Java-SCA-Next
Attachments: DomainImplComparisonFix.patch
I think there is a possible comparison problem in the SCADomainImpl class in
the domain-impl project. The code currently has:
for (QName nodeCompositeName : nodeInfo.getCompositeNames()){
if (compositeName.equals(nodeCompositeName) ) {
startNode = true;
}
}
if (startNode = true){
Notice that there is only one equals ('=') character in the if comparison on
startNode.
Since this is an assignment, the if statement will always be true.
Perhaps the code should read:
if (startNode == true){
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1854) ConversationID is not set correctly when using Conversational with WS
[ https://issues.apache.org/jira/browse/TUSCANY-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-1854: --- Assignee: Simon Laws ConversationID is not set correctly when using Conversational with WS - Key: TUSCANY-1854 URL: https://issues.apache.org/jira/browse/TUSCANY-1854 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Environment: Windows XP Reporter: bjoern Assignee: Simon Laws When unsing the @Conversational with webservices on serverside the @conversationID is not filled with the vlaue of the SOAP-Header but is filled with a newly generated. The information from the User-List I collected with Simon: Hi, I logged the SOAP messages that go form the WS-Client to the WS-Server and I found out something strange: On client-side a ConverstionID is generated (5756de5a-904e-4834-aaf4-6249d74b702e) and passed using the SOAP-header To the server-side. I expected that the anootated variable @ConversationID public String lConversationID; Is filled with this value (5756de5a-904e-4834-aaf4-6249d74b702e) but it seams to get a differend id (194e6a05-8b80-42e4-a380-5e43fffcdb14). As long as the conversation is up the ID send by the client stays the same (5756de5a-904e-4834-aaf4-6249d74b702e) but on server side I get a differend ID for every call. SOAP LOGFILE: soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header To xmlns=http://www.w3.org/2005/08/addressing; wsa:Address xmlns:wsa=http://www.w3.org/2005/08/addressing; http://localhost:8082/SOULSessionService /wsa:Address wsa:ReferenceParameters xmlns:wsa=http://www.w3.org/2005/08/addressing; axis2ns1:ConversationID xmlns:axis2ns1=http://tuscany.apache.org/xmlns/sca/1.0; 5756de5a-904e-4834-aaf4-6249d74b702e /axis2ns1:ConversationID /wsa:ReferenceParameters /To /soapenv:Header soapenv:Body _ns_:getSessionID xmlns:_ns_=http://SOULSessionService; _ns_:getName/_ns_:getName /_ns_:getSessionID /soapenv:Body /soapenv:Envelope soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getSessionIDResponse xmlns:_ns_=http://SOULSessionService; _ns_:getNameReturn 194e6a05-8b80-42e4-a380-5e43fffcdb14 /_ns_:getNameReturn /_ns_:getSessionIDResponse /soapenv:Body /soapenv:Envelope soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header To xmlns=http://www.w3.org/2005/08/addressing; wsa:Address xmlns:wsa=http://www.w3.org/2005/08/addressing; http://localhost:8082/SOULSessionService /wsa:Address wsa:ReferenceParameters xmlns:wsa=http://www.w3.org/2005/08/addressing; axis2ns2:ConversationID xmlns:axis2ns2=http://tuscany.apache.org/xmlns/sca/1.0; 5756de5a-904e-4834-aaf4-6249d74b702e /axis2ns2:ConversationID /wsa:ReferenceParameters /To /soapenv:Header soapenv:Body _ns_:getSessionID xmlns:_ns_=http://SOULSessionService; _ns_:getName/_ns_:getName /_ns_:getSessionID /soapenv:Body /soapenv:Envelope soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getSessionIDResponse xmlns:_ns_=http://SOULSessionService; _ns_:getNameReturn
[jira] Assigned: (TUSCANY-1855) Possible incorrect comparison in SCADomainImpl in the domain-impl project
[
https://issues.apache.org/jira/browse/TUSCANY-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-1855:
---
Assignee: Simon Laws
Possible incorrect comparison in SCADomainImpl in the domain-impl project
-
Key: TUSCANY-1855
URL: https://issues.apache.org/jira/browse/TUSCANY-1855
Project: Tuscany
Issue Type: Bug
Environment: Tuscany SVN revision #585076
Linux
Reporter: Mark Combellack
Assignee: Simon Laws
Priority: Minor
Fix For: Java-SCA-Next
Attachments: DomainImplComparisonFix.patch
I think there is a possible comparison problem in the SCADomainImpl class in
the domain-impl project. The code currently has:
for (QName nodeCompositeName : nodeInfo.getCompositeNames()){
if (compositeName.equals(nodeCompositeName) ) {
startNode = true;
}
}
if (startNode = true){
Notice that there is only one equals ('=') character in the if comparison on
startNode.
Since this is an assignment, the if statement will always be true.
Perhaps the code should read:
if (startNode == true){
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1855) Possible incorrect comparison in SCADomainImpl in the domain-impl project
[
https://issues.apache.org/jira/browse/TUSCANY-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535539
]
Simon Laws commented on TUSCANY-1855:
-
Thanks Mark. Am just putting some more changes into domain-impl to make the
domain model clearer and to make it easier for the web app story to work with
the new domain apis. I'll roll your patch in with these.
Thanks
Simon
Possible incorrect comparison in SCADomainImpl in the domain-impl project
-
Key: TUSCANY-1855
URL: https://issues.apache.org/jira/browse/TUSCANY-1855
Project: Tuscany
Issue Type: Bug
Environment: Tuscany SVN revision #585076
Linux
Reporter: Mark Combellack
Assignee: Simon Laws
Priority: Minor
Fix For: Java-SCA-Next
Attachments: DomainImplComparisonFix.patch
I think there is a possible comparison problem in the SCADomainImpl class in
the domain-impl project. The code currently has:
for (QName nodeCompositeName : nodeInfo.getCompositeNames()){
if (compositeName.equals(nodeCompositeName) ) {
startNode = true;
}
}
if (startNode = true){
Notice that there is only one equals ('=') character in the if comparison on
startNode.
Since this is an assignment, the if statement will always be true.
Perhaps the code should read:
if (startNode == true){
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots
[
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535581
]
Frank Budinsky commented on TUSCANY-1853:
-
Hi Czarek, This looks familiar, I think we may have fixed it already. Can you
try the latest from trunk and see if you still experience problems. Thanks.
XSD2JavaGenerator generates Java identifier with dots
-
Key: TUSCANY-1853
URL: https://issues.apache.org/jira/browse/TUSCANY-1853
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: Windows XP, jre 1.5
Reporter: Cezary Tkaczyk
Hello,
While I'm trying to compile generated by XSD2JavaGenerator Java classes, I've
got such an error:
[javac]
C:\projekty\eclipse-workspace-rbpl-sdo-1.0\REB-Catalog-SDO-Java\src-autogen\pl\esb\impl\EsbFactoryImpl.java:169:
';' expected
[javac] pl.esb.blm.adapter.AdapterFactory
pl.esb.blm.adapter.AdapterFactoryInstance =
pl.esb.blm.adapter.AdapterFactory.INSTANCE;
[javac]^
The problem is: variable identifier cannot contain dots.
The place, where this error appears looks like this:
public static EsbFactoryImpl init()
{
if (instance != null ) return instance;
instance = new EsbFactoryImpl();
// Initialize dependent packages
AdapterFactory AdapterFactoryInstance = AdapterFactory.INSTANCE;
RebFactory RebFactoryInstance = RebFactory.INSTANCE;
pl.raiffeisen.esb.blm.adapter.AdapterFactory
pl.raiffeisen.esb.blm.adapter.AdapterFactoryInstance =
pl.raiffeisen.esb.blm.adapter.AdapterFactory.INSTANCE;
// Create package meta-data objects
instance.createMetaData();
// Initialize created meta-data
instance.initializeMetaData();
// Mark meta-data to indicate it can't be changed
//theEsbFactoryImpl.freeze(); //FB do we need to freeze / should we
freeze
return instance;
}
I think the problem is that I have two namespaces of the same suffix:
http://www.esb.pl/blm/adapter
http://www.esb.pl/ods1/adapter
So, generator is trying to avoid the problem creating unique variable name:
pl.esb.blm.adapter.AdapterFactoryInstance
Unfortunately, this is not valid identifier.
Kind Regards,
Czarek
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading in Tuscany
I'm just catching up with this very interesting thread. Comments inline. Rajini Sivaram wrote: Sebastien, I have the second path - (multiple application loaders, one runtime loader) working in my sandbox. I need to write some tests and run all the existing tests before I submit the patch. This works without OSGi, and is a very minor change. For the first path, I am still running under OSGi. At the moment I have four different scenarios (they are all running tests using Axis2 binding to support distributed-OSGi): 1. One Tuscany bundle containing Tuscany + dependencies (one classloader for all the jars referred to in tuscany-sca-manifest.jar). This works and corresponds to CL1 application loader, CL2 runtime loader. 2. Two Tuscany bundles, one containing Tuscany, another containing all 3rd party dependencies(Axis2 etc.). This also works and corresponds to CL1 application loader, and CL2 Tuscany, CL3 3rd party code. 3. Split Tuscany bundles into multiple bundles, one bundle for 3rd party (splitting CL2 into multiple loaders from 2.) 4. Split 3rd party into multiple bundles, one bundle for Tuscany (splitting CL3 into multiple loaders from 2.) 3. and 4. dont work yet. From your note (and Raymond's), I think I should have another scenario before 3. which splits Tuscany into API and runtime. I think that should work without much trouble (ie, CL1 application loader, CL2 Tuscany API loader, CL3 Tuscany runtime loader, CL4 3rd party loader). Where do the SPIs fit into this? They aren't really part of the API loader, because aplication code shouldn't see them. The aren't really part of the runtime loader, because they need to be exposed between different runtime modules, but the runtime code shouldn't be exposed. I think Raymond's graph of dependencies was helpful in laying out the visbility relationships. There's also a counterpoint for what things should NOT be visible. In the following, see means that it's statically referenceable using the same classloader. 1. Application code shouldn't be able to see non-imported contributions, Tuscany SPIs, or Tuscany runtime code. 2. Tuscany APIs shouldn't be able to see anything else. 3. Tuscany SPIs shouldn't be able to see Tuscany runtime code or application code. 4. Tuscany runtime code shouldn't be able to see Tuscany runtime code in other modules, or application code. 5. 3rd party code (not written with knowledge of Tuscany) shouldn't be able to see Tuscany runtime code, Tuscany SPIs, Tuscany APIs, or application code. Simon The tests for multiple application loaders (second path in your note) will be non-OSGi tests - Tuscany OSGi contributions are already tested with multiple bundles and hence multiple classloaders. For the first path, I haven't really considered testing without OSGi - I would probably still continue to work with OSGi to isolate the issues, but try and introduce tests later which run without OSGi. Thank you... Regards, Rajini On 10/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Raymond, Thank you for your reply (and the diagram). The biggest advantage of migrating to an OSGi classloader scheme would be that apart from module isolation, OSGi would also provide module versioning, enabling multiple versions of SCA runtime to exist within a single VM. OSGi would also enable Tuscany modules to be dynamically installed, started and uninstalled. The use of multi-parent classloaders to load modules in Tuscany would require the same amount of code changes as migrating to OSGi, but it would be much harder to implement versioning and dynamic replacement of modules (which come for free with OSGi). The desired visibility of classes that you have listed correspond to the static dependencies that currently exist in the code. The actual visibility that exists today includes arrows from the core modules to extensions, forming a cycle. It is this visibility that is used to locate and start modules dynamically in Tuscany today. There is also an arrow from the Axis library to binding.ws.axis2, through the thread context classloader, and even though not particularly desirable, it is not avoidable. Thank you... Regards, Rajini How about going step by step and: 1. try to bootstrap the tuscany runtime with two classloaders: CL1 application code, CL2 runtime 2. extend to CL1 application code, CL2 Tuscany and SCA APIs, CL3 runtime 3. split the runtime in multiple CLs and on a separate path: 1. try to bootstrap the tuscany runtime with two classloaders: CL1 application code, CL2 runtime 2. split the application code in multiple CLs We could create integration tests for these configurations (not necessarily using OSGi, as these can be built with just plain classloaders IMO), and it would help us identify bad classloader usages, fix them, and detect+prevent classloader issues over time. Thoughts? -- Jean-Sebastien
Re: ApacheCon Europe 2008
Hi Patrick In lieu of Kelvin responding to this (I was going to help Kelvin out and make the slides) I think it would be really good to have you be part of the presentation. It brings a slightly different perspective and broadens the appeal I think. Regards Simon On 10/16/07, Patrick Leonard [EMAIL PROTECTED] wrote: Haleh, the abstract looks good. Kelvin, I would be happy to join you if you want to do the multi-presenter. From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 16, 2007 1:08 PM To: tuscany-dev@ws.apache.org Subject: Re: ApacheCon Europe 2008 How about the following. The talk is in April and by then there might be other releases beyond release 1.0 which is emphasized in the original text. An update on Apache Tuscany project- Building SOA solutions is easy Apache Tuscany provides an open-source services infrastructure for constructing SOA solutions from heterogeneous and distributed services. This talk will focus on Apache Tuscany's implementation of Service Component Architecture which is based on V1.0 specification that is now under OASIS for standardization. In addition, the talk will cover Apache Tuscany added extensions such as web 2.0, scripting, distribution and multi-language support as well as integration with other Apache projects such as ODE and Geronimo. Some of the interesting topics that are under discussion in Apache Tuscany will be highlighted. The talk will be complemented with a demo to demonstrate how easy it is to use Apache Tuscany to develop SOA solutions. On 10/11/07, Simon Laws [EMAIL PROTECTED] wrote: On 10/9/07, kelvin goodson [EMAIL PROTECTED] wrote: ApacheCon Europe is coming up, 7th to 11th of April 2008 [1], and the deadline for submission of abstracts is coming up fast, on 26th of this month. What should we aim to do here? The options seem to be (60 minutes) Multi-person panel discussion (60 minutes) Normal presentation Intensive topical training (full-day) Intensive topical training (half-day) Intensive topical training (two-day) My guess is that we should submit for a 60 minute presentation, but should we go for a tutorial session as well? I'm happy to coordinate, and although presenting on SCA would take me a little out of my comfort zone, I would welcome the chance to do so. As a possible starting point for thinking about this I was looking at Simon Laws' abstract and presentation for the recent JavaZone conference [2], [3]. What would we want to update or emphasize differently from this? In the short term we just need to get an abstract together and think about who will do the presentation. Regards, Kelvin. [1] http://www.eu.apachecon.com/ [2] http://www4.java.no/web/show.do?page=92articleid=5343 [3] http://cwiki.apache.org/confluence/download/attachments/68184/BuildingSO AWithApacheTuscany.ppt?version=1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would certainly submit an abstract for a 60 minute presentation. I know others in the community have been working on tutorial material. What's the state of that? If that is going ahead then that material could be reused and a proposal made. Would be good to get more mileage out of it. Regards Simon
Re: Changes to store sample
Luciano Resende wrote: Based on your suggestion, do we keep sca/sample/store and add variations to sca/demo/store-with-catalog-db as suggested, +1, /samples for simple programs that help you quickly understand the basic programming model (and the getting-started store is in that category) and /demos for more complicated applications and variations that demo the integration of more Tuscany features and other technologies. or we move sca/sample/store as it was originally designed to sca/demo and make the variations there ? On 10/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I like what you've done to show access to a DB, but I didn't think that we were going to make these changes right in the original getting started sample directory. Would it be possible to keep the original getting started store sample to the bare minimum so that the getting-started document can continue to describe how to build it in a few minutes with reasonable steps, and have a series of evolutions, like: - store - store-with-catalog-db (which is I think what you've done here) - store-with-a-ws, - store-using-a-live-catalog (which could go to an Amazon or eBay catalog for example) - store-distributed (I started to work on something like that to play with Simon's latest domain API) etc. We could put these variations under a tutorial directory or the demos directory... Thanks. Independent of what we eventually decide to do with samples/store, I have copied the simple getting-started store under demos/training, as I'd like to integrate it with some of Mario's contribution that's currently in that directory. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
Hi, Thank you for participating the discussion. I collected all the input we have so far at the following WIKI page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion Please feel free to add/update to make it an ongoing community effect. Hopefully we can start to turn them into actions and I believe some specific discussions have been carried on the ML. As always, your contributions are welcome. Thanks, Raymond - Original Message - From: wang feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, October 16, 2007 7:18 PM Subject: Re: Re: [DISCUSS] Tuscany SCA Roadmap and next releases Hi all, We have used Tuscany 1.0 in our product and found some features is important to us. - Support hot deployable on contribution and composite. This should be have a recursive algorithm to update the correlated component when it has been referenced. - Support SDO namespace when using websservice. Deploy a service to webservice,a schema file used in SDO and have sdo namespace such as commonj.sdo/java or commonj.sdo/xml,we should support the feature when parsing the wsdl. - Support load contribution as a osgi bundle. Thanks, wangfeng On 2007-10-17, Simon Laws [EMAIL PROTECTED] wrote: On 10/16/07, Luciano Resende [EMAIL PROTECTED] wrote: For implementation.bpel, we need to finalize support for references, and we might want to do introspection of the BPEL process. On 10/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: - Fix nightly builds (looks like this may be going again now) Yes it is. http://vmbuild1.apache.org/continuum/buildResults.action?projectGroupId=19projectId=277 [snip] - Fix all the build issues (maven 2.0.6/2.0.7/JDK6/empty repository) so new users building Tuscany have a good experience After the changes I made last week I think this is now all fixed (except for JIRAs TUSCANY-1846 and TUSCANY-1847). I am currently building with Maven 2.0.7 and both JDK5 and JDK6. Could people please try other Maven combinations? 2.0.5, 2.0.6, and report any errors? Thanks. [snip] - Get binding.jms and implementation.bpel more spec complete. - For JMS maybe have a host-jms module so you don't have to start a separate JMS server or can use the the Geronimo one if thats where Tuscany is running What's missing in binding.jms and implementation.bpel? Could people working on these modules give a quick overview? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For binding.jms the user guide shows you that most of the options still need to be implemented. http://incubator.apache.org/tuscany/sca-java-bindingjms.html There are a few people either working on this or have expressed an interest in working on it. There is quite a lot on incremental stuff that can be done for anyone else who is interested. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon Europe 2008
Simon, I don't have anything to add to the updated abstract. My whole goal was to make the first abstract a bit clearer and it seems like now it is there. Thanks, Haleh On 10/17/07, Simon Laws [EMAIL PROTECTED] wrote: Hi Patrick In lieu of Kelvin responding to this (I was going to help Kelvin out and make the slides) I think it would be really good to have you be part of the presentation. It brings a slightly different perspective and broadens the appeal I think. Regards Simon On 10/16/07, Patrick Leonard [EMAIL PROTECTED] wrote: Haleh, the abstract looks good. Kelvin, I would be happy to join you if you want to do the multi-presenter. From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 16, 2007 1:08 PM To: tuscany-dev@ws.apache.org Subject: Re: ApacheCon Europe 2008 How about the following. The talk is in April and by then there might be other releases beyond release 1.0 which is emphasized in the original text. An update on Apache Tuscany project- Building SOA solutions is easy Apache Tuscany provides an open-source services infrastructure for constructing SOA solutions from heterogeneous and distributed services. This talk will focus on Apache Tuscany's implementation of Service Component Architecture which is based on V1.0 specification that is now under OASIS for standardization. In addition, the talk will cover Apache Tuscany added extensions such as web 2.0, scripting, distribution and multi-language support as well as integration with other Apache projects such as ODE and Geronimo. Some of the interesting topics that are under discussion in Apache Tuscany will be highlighted. The talk will be complemented with a demo to demonstrate how easy it is to use Apache Tuscany to develop SOA solutions. On 10/11/07, Simon Laws [EMAIL PROTECTED] wrote: On 10/9/07, kelvin goodson [EMAIL PROTECTED] wrote: ApacheCon Europe is coming up, 7th to 11th of April 2008 [1], and the deadline for submission of abstracts is coming up fast, on 26th of this month. What should we aim to do here? The options seem to be (60 minutes) Multi-person panel discussion (60 minutes) Normal presentation Intensive topical training (full-day) Intensive topical training (half-day) Intensive topical training (two-day) My guess is that we should submit for a 60 minute presentation, but should we go for a tutorial session as well? I'm happy to coordinate, and although presenting on SCA would take me a little out of my comfort zone, I would welcome the chance to do so. As a possible starting point for thinking about this I was looking at Simon Laws' abstract and presentation for the recent JavaZone conference [2], [3]. What would we want to update or emphasize differently from this? In the short term we just need to get an abstract together and think about who will do the presentation. Regards, Kelvin. [1] http://www.eu.apachecon.com/ [2] http://www4.java.no/web/show.do?page=92articleid=5343 [3] http://cwiki.apache.org/confluence/download/attachments/68184/BuildingSO AWithApacheTuscany.ppt?version=1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would certainly submit an abstract for a 60 minute presentation. I know others in the community have been working on tutorial material. What's the state of that? If that is going ahead then that material could be reused and a proposal made. Would be good to get more mileage out of it. Regards Simon
