[jira] Created: (TUSCANY-1543) Demonstrate faulty transaction support in DAS
Demonstrate faulty transaction support in DAS - Key: TUSCANY-1543 URL: https://issues.apache.org/jira/browse/TUSCANY-1543 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Fix For: Java-DAS-Next Sample test cases showing where DAS is falling short in providing adequate transaction support. -- 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: Home page for Tuscany standalone runtime
On 8/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: The runtime currently prints the servlet mappings to System.out when it starts. In order to make that kind of information easier to use, I've started to put together a home page that people can point their Web browser to, listing some basic information about the running Tuscany runtime, servlet endpoints, etc. I'm planning to start adding some of this home page support to a new home module. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sounds like a great idea. I'd like to provide and extension to this to add some more information for when tuscany is running across several nodes. I think it would be useful to show which nodes are running and, based on what you say about endpoints, which references are resolved to those endpoints. I'll look out for the new module. Simon
Re: Tuscany/Geronimo Integration Demo
I am not referencing this class directly in my code. Can it be that the published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or not the latest?? I can not think of other possibilities. Vamsi On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT . The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png . The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. After switching to 1.0-incubating-SNAPSHOT, I have run into a NoClassDefFoundError: org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? GERONIMO-3351 has not been integrated into 2.0 release. Part of the problem is addressed in branches\2.0 and trunk. It affects only SNAPSHOT dependencies and there is some discussion on whether the downloaded version (if it is different from SNAPSHOT) should be renamed, by the plugin installer, to SNAPSHOT or the dependency resolution is Geronimo should handle it in a different way. The problem we have run into is in conjunction with another problem that occurs when a trailing / is not present in the maven repo URL. This has been fixed in branches\2.0 and trunk (not in 2.0 release though) and the work around for this is to put that trailing / in the maven repo URLs in geronimo-plugin.xml. These two fixes will (most likely, but not guaranteed) go into 2.0.1 due to be released soon (probably this week). [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a week or so ago when I moved the majority of sca binding into the binding-sca module. I'm thinking that I was a little overzealous when I took this out and that it probably needs to go back in. In the mean time can you create a org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl instead? Regards Simon
Re: [DAS] Transaction support
Hi Haleh, Please see all the use case details below. There are three user cases going wrong which I am trying to fix. I have created a JIRA-1543 to demonstrate with examples how DAS is failing in these use case scenarios. Patch contains 3 new test cases as below in TransactionTests.java. So far TransactionTests.java had only 1 test case and was not enough to uncover these issues. 1) when user passes connection to DAS, it is obvious that user is always going to have a handle to it and so the only option should be to make user control the transaction. Current DAS code issues commit/rollback / Command for this case, which is an erroneous behavior. Due to this user loses its ability to group commands based on business need in a transaction. ---check testUserUnableToControlExternallyInitedTransaction() 2) when managedtx=false and connection is created by DAS, NEITHER DAS NOR USER issue any commit/rollback ANYTIME. This is equaly wrong. This way the Transaction control is at the mercy of How DBMS behaves upon close of a connection. This can be corrected if getConnection() is exposed. ---check testUnableToCommitTransaction() 3) most important-data integrity violation! When managedtx=true and Connection is created by DAS, and there are multiple applyChanges() which need to be in same transaction to ensure data integrity, DAS fails completely. Here exposing getConnection() won't do, as with this user can even issue closeConnection() and DAS will not function with that. Instead, if startTransaction(), endTransaction() are exposed, user will be able to maintain data integrity based on his demand. ---check testDataIntegrityViolation() ___ Alternative approach will be remove managedtx attribute itself from config.xsd and let user do whatever he wants with the connection, in this case just making sure user has handle to connection (either because he created it or because of getConnection()) will be enough. i.e. always delegate transaction control to the caller and don't handle it in DAS. ___ 1testUserUnableToControlExternallyInitedTransaction Scenario:- Stopped Employee department transfer 0) John Jones is in Advanced Technologies(Department1) 1) John Jones is removed from Advanced Technologies 2) User decides to revert the decision and rollsback the transaction Ideally, it is expected that remove from Department1 (1)) should not have happened and John Jones should still be in Department1. What is found in the end result is John Jones is removed from Department1 even though user has issued rollback. _ 2testUnableToCommitTransaction Scenario:- Employee department transfer 0) John Jones is in Advanced Technologies(Department1) 1) John Jones is removed from Advanced Technologies 2) John Jones is added to New Technologies(Department2) DAS Config has ConnectionInfo specified and user does not pass Connection to DAS. Thus Connection is created by DAS and used in Commands. Also, in DAS Config ConnectionInfo, managedtx=FALSE is set by user. This signals DAS to stop issuing any commit/rollback. Also, as Connection is internally formed by DAS and not exposed to user, there is no way user can handle commit/rollback. After , 0), 1), 2), user assumes that change has happened and John Jones is removed from Department1 and added to Department2. He creates a new Connection and a new DAS instance and checks data in database. When he issues query using new connection and new DAS ., he gets SQLException indicating lock could not be obtained on tables of interest and query could not go thru. This is because 1),2) are not commited by DAS nor user and so tables remained locked. ___ 3testDataIntegrityViolation Scenario:- Bank account money transter 0) Account1 original balance $1, account2 original balance $500 1) user removes $200 from account1 2) user adds $200 into account2 DAS Config has ConnectionInfo specified and user does not pass Connection to DAS. Thus Connection is created by DAS and used in Commands. Also, in DAS Config ConnectionInfo, managedtx=TRUE is set by user. This signals DAS to issue commit/rollback/Command. Also, as Connection is internally formed by DAS and not exposed to user, there is no way user can handle commit/rollback. After , 0), 1), there is a network crash during 2) and so 2) does not go thru, but on the other hand there is a SQLException thrown during 2) due to which DAS attempts a rollback. Now what is expected is 1) and 2) should both be rolled back, and account1 and account2 should have old balaces. This will ensure data integrity. When user checks data in DBMS, what is found is account1 is $200
Re: Tuscany/Geronimo Integration Demo
On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I am not referencing this class directly in my code. Can it be that the published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or not the latest?? I can not think of other possibilities. Vamsi On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT . The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png . The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. After switching to 1.0-incubating-SNAPSHOT, I have run into a NoClassDefFoundError: org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? GERONIMO-3351 has not been integrated into 2.0 release. Part of the problem is addressed in branches\2.0 and trunk. It affects only SNAPSHOT dependencies and there is some discussion on whether the downloaded version (if it is different from SNAPSHOT) should be renamed, by the plugin installer, to SNAPSHOT or the dependency resolution is Geronimo should handle it in a different way. The problem we have run into is in conjunction with another problem that occurs when a trailing / is not present in the maven repo URL. This has been fixed in branches\2.0 and trunk (not in 2.0 release though) and the work around for this is to put that trailing / in the maven repo URLs in geronimo-plugin.xml . These two fixes will (most likely, but not guaranteed) go into 2.0.1 due to be released soon (probably this week). [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a week or so ago when I moved the majority of sca binding into the binding-sca module. I'm thinking that I was a little overzealous when I took this out and that it probably needs to go back in. In the mean time can you create a org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl instead? Regards Simon You may very well be right. Time to push some new snapshots out! Let me find out how to do that. Simon
[jira] Assigned: (TUSCANY-1543) Demonstrate faulty transaction support in DAS
[ https://issues.apache.org/jira/browse/TUSCANY-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar reassigned TUSCANY-1543: Assignee: Amita Vadhavkar Demonstrate faulty transaction support in DAS - Key: TUSCANY-1543 URL: https://issues.apache.org/jira/browse/TUSCANY-1543 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Sample test cases showing where DAS is falling short in providing adequate transaction support. -- 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-1543) Demonstrate faulty transaction support in DAS
[ https://issues.apache.org/jira/browse/TUSCANY-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1543: - Attachment: 1543.patch testUnableToCommitTransaction - is commented in patch as it locks tables in database and so disturbs other test cases. It can be uncommented and run stanalone though. Demonstrate faulty transaction support in DAS - Key: TUSCANY-1543 URL: https://issues.apache.org/jira/browse/TUSCANY-1543 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1543.patch Sample test cases showing where DAS is falling short in providing adequate transaction support. -- 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: XQuery Implementation type for SCA
[snip] Raymond Feng wrote: Hi, MPL seems to be acceptable if we don't modify the sources. Please see http://people.apache.org/~rubys/3party.html. The SAXON is available at http://repo1.maven.org/maven2/net/sf/saxon/saxon/8.7/saxon-8.7.jar. Thanks, Raymond - Original Message - From: Vasil Vasilev [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, August 14, 2007 11:04 AM Subject: Re: XQuery Implementation type for SCA Sure! That is a perfect idea! However, we should think of the Saxon binaries. Are they already available in the repository or we should add them? Are there any legal issues also involved? Bye, Vasil Оригинално писмо От: ant elder [EMAIL PROTECTED] Относно: Re: XQuery Implementation type for SCA До: tuscany-dev@ws.apache.org Изпратено на: Вторник, 2007, Август 14 18:45:26 EEST -- Thats a pretty impressive amount of work! In the JIRA you comment that its not ready for checkin yet, i know it needs things like the pom.xml's fixed up before it will run as part of the build but how about we check in to the svn trunk code now anyway and just not include the new modules in the build and then we can all help incrementally fix it up? ...ant Pretty impressive indeed! I took a look at what you attached to the JIRA and was able to get your databinding-saxon and implementation-xquery modules and the quote-xquery sample working almost right away. I just had to download saxonb8-9j.zip manually, install saxon8.jar and saxon8-dom.jar in my local Maven repository (as the public Maven repos seems to only have an old saxon 8.7), come up with Maven pom.xml files for your three modules, move TestHelper.java from quote-xquery/src/test/java to src/main/java (as with Maven code under src/main doesn't see src/test) and... --- T E S T S --- Running xquery.quote.XQueryQuoteClientTestCase Added Servlet mapping: http://localhost:8085/QuoteJoinService Added Servlet mapping: http://localhost:8085/AvailQuoteProviderService Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.591 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 ... [INFO] [INFO] BUILD SUCCESSFUL [INFO] :) That's really great work! I have checked in the three modules for others to take a look. They are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-saxon/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-xquery http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/quote-xquery I have also put in databinding-saxon/mvn-install-saxon.sh a small Linux script to help people download and install saxon in their local Maven repositories for now. At some point we're going to need saxonb 8.9 in a public Maven repository to avoid this manual install step. I think we should start new discussion threads on the dev list to discuss: - how implementation-xquery works and how we can leverage it to do interesting things - the questions and issues you raised in http://issues.apache.org/jira/browse/TUSCANY-1536 Thanks again for this contribution! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1536) Implementation type for XQuery
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-1536: --- Assignee: Jean-Sebastien Delfino Implementation type for XQuery -- Key: TUSCANY-1536 URL: https://issues.apache.org/jira/browse/TUSCANY-1536 Project: Tuscany Issue Type: New Feature Components: Java SCA Misc Implementation Extensions Reporter: Vasil Janov Vasilev Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next Attachments: xquery_impl.tar.gz An implementation type for components written using the XQuery script. Some notes about this prototype: 1. I see XQuery as a mighty data integration technology, that's why, in my opinion, the SCA specification should be enhanced with XQuery-related implementation type. 2. In order to prove this concept I created simple extension to Tuscany, which interprets implementation type implementation.xquery. Generally the following contributions were done: - xquery artifact resolver - xquery implementation provider - Saxon data binding and transormes for DOM Nodes and SDO DataObjects 3. As underlying implementation Saxon B is used. This has its limitations - it is not schema aware, but it is free (MPL - licensed). 4. I created test cases for the following scenarios: - Sending data from one SCA component to XQuery component - Feeding data to XQuery component by using properties - Binding XQuery component as a web service - referencing other SCA components from the XQuery component 5. In order to allow integration of XQuery in SCA I have also provided some specification of how references, services and properties can be defined in the XQuery file (see examples). The prototype is not ready to checkin, i.e. for example: it is not formated, there are no all needed unit tests, it is not made runnable with Maven, i.e. it is compilable with Eclipse (I have used Eclipse 3.2) It consists of the following projects (you can find them in the attachment) - tuscany-implementation-xquery - provides the xquery implementation - tuscany-databinding-saxon - provides saxon-related databindings and transformations - sample-quote-xquery - integration scenario for the prototype - saxon-lib - the saxon libraries This prototype has the following limitations - as currently seen by me: 1. The Saxon should be enhanced so that one can set external variables (of Object type) when making single function call 2. Currently in create of XQueryImplementationProvider I set data bindings for the services and references. In order to have a data transformer later, all these references and services should be with remotable interfaces, so that their original bindings are set. Is this the correct way to do it? Or may be I should provide my own binding (not databinding, but binding)? 3. Limitation - only Java interfaces can be implemented by XQuery implementations 4. Is there any way to say which configuration is associated with a given invocation? Currently NodeInfo objects are transformed from one configuration to another which has performance impact. I.e. can I associate an object with an invocaion in some kind of context? 5. Limitation: currently the result of XQuery cane be only a single item, not a collection 6. Saxon B can not interpret XML documents in which there are namespace declarations. This requires conversion, which is a step that increases memory overhead and speed 7. For DataObjects transformation, it is presupposed that that their starting element is the name of the implemented interface with its first letter made to lower case. Is this the best variant? 8. Why I can not invoke directly from the client a component with data binding, i.e. why the self reference can not contain Data transformation interceptor? -- 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-1536) Implementation type for XQuery
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520172 ] Jean-Sebastien Delfino commented on TUSCANY-1536: - I have commited the three modules: - tuscany-databinding-saxon - tuscany-implementation-xquery - sample-quote-xquery under revision r566530. Thanks a lot for this great contribution to Tuscany! Implementation type for XQuery -- Key: TUSCANY-1536 URL: https://issues.apache.org/jira/browse/TUSCANY-1536 Project: Tuscany Issue Type: New Feature Components: Java SCA Misc Implementation Extensions Reporter: Vasil Janov Vasilev Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next Attachments: xquery_impl.tar.gz An implementation type for components written using the XQuery script. Some notes about this prototype: 1. I see XQuery as a mighty data integration technology, that's why, in my opinion, the SCA specification should be enhanced with XQuery-related implementation type. 2. In order to prove this concept I created simple extension to Tuscany, which interprets implementation type implementation.xquery. Generally the following contributions were done: - xquery artifact resolver - xquery implementation provider - Saxon data binding and transormes for DOM Nodes and SDO DataObjects 3. As underlying implementation Saxon B is used. This has its limitations - it is not schema aware, but it is free (MPL - licensed). 4. I created test cases for the following scenarios: - Sending data from one SCA component to XQuery component - Feeding data to XQuery component by using properties - Binding XQuery component as a web service - referencing other SCA components from the XQuery component 5. In order to allow integration of XQuery in SCA I have also provided some specification of how references, services and properties can be defined in the XQuery file (see examples). The prototype is not ready to checkin, i.e. for example: it is not formated, there are no all needed unit tests, it is not made runnable with Maven, i.e. it is compilable with Eclipse (I have used Eclipse 3.2) It consists of the following projects (you can find them in the attachment) - tuscany-implementation-xquery - provides the xquery implementation - tuscany-databinding-saxon - provides saxon-related databindings and transformations - sample-quote-xquery - integration scenario for the prototype - saxon-lib - the saxon libraries This prototype has the following limitations - as currently seen by me: 1. The Saxon should be enhanced so that one can set external variables (of Object type) when making single function call 2. Currently in create of XQueryImplementationProvider I set data bindings for the services and references. In order to have a data transformer later, all these references and services should be with remotable interfaces, so that their original bindings are set. Is this the correct way to do it? Or may be I should provide my own binding (not databinding, but binding)? 3. Limitation - only Java interfaces can be implemented by XQuery implementations 4. Is there any way to say which configuration is associated with a given invocation? Currently NodeInfo objects are transformed from one configuration to another which has performance impact. I.e. can I associate an object with an invocaion in some kind of context? 5. Limitation: currently the result of XQuery cane be only a single item, not a collection 6. Saxon B can not interpret XML documents in which there are namespace declarations. This requires conversion, which is a step that increases memory overhead and speed 7. For DataObjects transformation, it is presupposed that that their starting element is the name of the implemented interface with its first letter made to lower case. Is this the best variant? 8. Why I can not invoke directly from the client a component with data binding, i.e. why the self reference can not contain Data transformation interceptor? -- 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-1536) Implementation type for XQuery
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520173 ] Jean-Sebastien Delfino commented on TUSCANY-1536: - I am leaving the JIRA open for now as you have raised interesting design limitations / issues, which still need to be addressed. Implementation type for XQuery -- Key: TUSCANY-1536 URL: https://issues.apache.org/jira/browse/TUSCANY-1536 Project: Tuscany Issue Type: New Feature Components: Java SCA Misc Implementation Extensions Reporter: Vasil Janov Vasilev Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next Attachments: xquery_impl.tar.gz An implementation type for components written using the XQuery script. Some notes about this prototype: 1. I see XQuery as a mighty data integration technology, that's why, in my opinion, the SCA specification should be enhanced with XQuery-related implementation type. 2. In order to prove this concept I created simple extension to Tuscany, which interprets implementation type implementation.xquery. Generally the following contributions were done: - xquery artifact resolver - xquery implementation provider - Saxon data binding and transormes for DOM Nodes and SDO DataObjects 3. As underlying implementation Saxon B is used. This has its limitations - it is not schema aware, but it is free (MPL - licensed). 4. I created test cases for the following scenarios: - Sending data from one SCA component to XQuery component - Feeding data to XQuery component by using properties - Binding XQuery component as a web service - referencing other SCA components from the XQuery component 5. In order to allow integration of XQuery in SCA I have also provided some specification of how references, services and properties can be defined in the XQuery file (see examples). The prototype is not ready to checkin, i.e. for example: it is not formated, there are no all needed unit tests, it is not made runnable with Maven, i.e. it is compilable with Eclipse (I have used Eclipse 3.2) It consists of the following projects (you can find them in the attachment) - tuscany-implementation-xquery - provides the xquery implementation - tuscany-databinding-saxon - provides saxon-related databindings and transformations - sample-quote-xquery - integration scenario for the prototype - saxon-lib - the saxon libraries This prototype has the following limitations - as currently seen by me: 1. The Saxon should be enhanced so that one can set external variables (of Object type) when making single function call 2. Currently in create of XQueryImplementationProvider I set data bindings for the services and references. In order to have a data transformer later, all these references and services should be with remotable interfaces, so that their original bindings are set. Is this the correct way to do it? Or may be I should provide my own binding (not databinding, but binding)? 3. Limitation - only Java interfaces can be implemented by XQuery implementations 4. Is there any way to say which configuration is associated with a given invocation? Currently NodeInfo objects are transformed from one configuration to another which has performance impact. I.e. can I associate an object with an invocaion in some kind of context? 5. Limitation: currently the result of XQuery cane be only a single item, not a collection 6. Saxon B can not interpret XML documents in which there are namespace declarations. This requires conversion, which is a step that increases memory overhead and speed 7. For DataObjects transformation, it is presupposed that that their starting element is the name of the implemented interface with its first letter made to lower case. Is this the best variant? 8. Why I can not invoke directly from the client a component with data binding, i.e. why the self reference can not contain Data transformation interceptor? -- 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: Move up to Axis2 1.3?
+1 to do this now. - Venkat On 8/14/07, ant elder [EMAIL PROTECTED] wrote: Axis2 1.3 has just been released so how about moving up to that? There's a lot of improvements and bug fixes in it and as its the level we'll likely go 1.0 with i think it would be good to get it in sooner so we have time to find and fixes any problems. There's a few minor changes we need to do in Tuscany to move up but I have it almost going, just one failing testcase remaining, so what do people think, should we move up now or wait till after our next release? ...ant
Re: DAS - relationship with composite keys
I think with JIRA-1464 resolved, this issue is fixed. Regards, Amita On 4/28/07, Adriano Crestani [EMAIL PROTECTED] wrote: Sorry, the query above should be SELECT A.id http://a.id/, A.b_id1, B_id1, B_id2 from A, B; instead of SELECT A.id http://a.id/, A.b_id1 from A, B; Adriano Crestani On 4/27/07, Adriano Crestani [EMAIL PROTECTED] wrote: I guess the relationship is considered for the key part present in select. e.g. if you look at the current CompoundKeyRelationshipTests in java rdb das, If the relationship is considered only for the keypart present in select, the populated graph will possible not correctly represent the data on the database. For example: Table A: Metadata = id, b_id1, b_id2 (composed foreign key) Row1 = 1, 1, 1 Row2 = 2, 2, 1 Row3 = 3, 1, 2 Row4 = 4, 2, 2 Table B: Metadata = id1, id2 (composed primary key) Row1 = 1, 1 Row2 = 2, 1 Row3 = 1, 2 Row4 = 2, 2 To clarify the references between tables mapped to ERD(Entity Relationship Diagram): B(Row1) - A(Row1) B(Row2) - A(Row2) B (Row3) - A (Row3) B(Row4) - A(Row4) Relationship definition: Relationship name=*A-B* primaryKeyTable=B foreignKeyTable=Amany =*true* KeyPair primaryKeyColumn=id1 foreignKeyColumn =*b_id1* / KeyPair primaryKeyColumn =id2 foreignKeyColumn=*b_id2* / /Relationship The query SELECT A.id, A.b_id1 from A, B; Supposing that the relationship is created even if not all the keypairs are present on the result, the sdo graph references created, if I'm not missing anything, as described bellow: B(1, 1) - A(1, 1) B(3, 1) - A(1, 1) B(2, 1) - A(2, 2) B(2, 2) - A(2, 2) B(1, 1) - A(3, 1) B(3, 1) - A(3, 1) B(2, 1) - A(4, 2) B(2, 2) - A(4, 2) Concluding, the data related on sdo graph are not correctly described, cause it is different from how they are related on the database. Though, if the sdo user does not know how the data are on the database, the user would get a wrong idea of how data are linked. On the example above the sdo user may think that a row of table A is referenced by two different rows of table B, but on the database it does not exist. Adriano Crestani On 4/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: I am not sure if I am interpreting the question correct, but please see below findings. I guess the relationship is considered for the key part present in select. e.g. if you look at the current CompoundKeyRelationshipTests in java rdb das, Data: - protected static Object[][] orderDetailsData = {{ Integer.valueOf (1), Integer.valueOf(1), new Float(1.1)}, {Integer.valueOf(1), Integer.valueOf(2), new Float(1.2)}, {Integer.valueOf(2), Integer.valueOf(1), new Float(2.1)}, {Integer.valueOf (2), Integer.valueOf(2), new Float(2.2)}}; protected static Object[][] orderDetailsDescriptionData = { {Integer.valueOf(1), Integer.valueOf(1), Integer.valueOf(1), Descr 1,1,1}, { Integer.valueOf(2), Integer.valueOf(1), Integer.valueOf(1), Descr 2,1,1}, {Integer.valueOf(3), Integer.valueOf(1), Integer.valueOf(2), Descr 3,1,2}, {Integer.valueOf(4), Integer.valueOf(1), Integer.valueOf(2), Descr 4,1,2}, {Integer.valueOf(5), Integer.valueOf(2), Integer.valueOf(1), Descr 6,2,1}, {Integer.valueOf(6), Integer.valueOf(2), Integer.valueOf(2), Descr 6,2,2}}; SQL: - the below statement's graph does consider relationship String statement = SELECT ORDERDETAILS.ORDERID, ORDERDETAILSDESC.ORDERID FROM ORDERDETAILS LEFT JOIN ORDERDETAILSDESC + ON ORDERDETAILS.ORDERID = ORDERDETAILSDESC.ORDERIDAND + ORDERDETAILS.PRODUCTID = ORDERDETAILSDESC.PRODUCTID + WHERE ORDERDETAILS.ORDERID = 1 AND ORDERDETAILS.PRODUCTID = 1; where the compound key is {ORDERID, PRODUCTID}. Similar is case when we have SELECT ORDERDETAILS.ORDERID, ORDERDETAILSDESC.PRODUCTID OR basically at lease any one column from ORDERDETAILS.ORDERID/PRODUCTID and at least any one column from ORDERDETAILSDESC.ORDERID/PRODUCTID - makes DAS to look at relationship. But I see there one more confusion:- even if the relationship is getting considered, in above cases or even case like below which covers the complete compound key:- SELECT ORDERDETAILS.ORDERID, ORDERDETAILS.PRODUCTID, ORDERDETAILSDESC.ORDERID,ORDERDETAILSDESC.PRODUCTID+ FROM ORDERDETAILS LEFT JOIN ORDERDETAILSDESC + ON ORDERDETAILS.ORDERID = ORDERDETAILSDESC.ORDERID AND + ORDERDETAILS.PRODUCTID = ORDERDETAILSDESC.PRODUCTID + WHERE ORDERDETAILS.ORDERID = 1 AND ORDERDETAILS.PRODUCTID = 1; As, TableData.columnData is a java Map, the returned count of orderdetailsdesc for the orderdetail(1,1)
Re: Move up to Axis2 1.3?
On 8/14/07, ant elder [EMAIL PROTECTED] wrote: Axis2 1.3 has just been released so how about moving up to that? There's a lot of improvements and bug fixes in it and as its the level we'll likely go 1.0 with i think it would be good to get it in sooner so we have time to find and fixes any problems. There's a few minor changes we need to do in Tuscany to move up but I have it almost going, just one failing testcase remaining, so what do people think, should we move up now or wait till after our next release? ...ant Actually, I've been talking to one of our big Tuscany users about this and it would be more convenient for them if we stayed at Axis2 1.2 for the time being so they don't have to update all their associated Axis2 code. ...ant
Re: Contribute to SCA-OSGi integration
Hi SCA/OSGi-ers, Just bringing this up again to see if there is any interesting in moving this along still. We've been talking about having a Tuscany 1.0 release in a couple of months, be great if we could have a good OSGi story for that. Also the Apache Felix 1.0 release is out now and the existing implemention.osgicode has been moved off SNAPSHOTs to use Felix 1.0 so we can now include that in releases (though i think one of the itests still has an intermittent failure so would be good to fix that as well). ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520208 ] Ron Gavlin commented on TUSCANY-1541: - Hi Sunny, In order to correctly identify whether this is an SCA databinding problem or an SDO problem, would it be possible for you to invoke XMLHelper.load() with the same xml stream outside of the SCA environment? Thanks, - Ron XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical Fix For: Java-SDO-Next When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- 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]
Spec clarification for conversational/callback semantics
While reviewing support for conversational services there were a few outstanding issues (https://issues.apache.org/jira/browse/TUSCANY-1511). A couple of these issues require a little clarification of the SCA specifications. Can someone with their SCA spec hat on help out? Here are the two primary issues: 1/ Stateful Callbacks - Given the the following scenario where the ConversationalClient has a reference to a ConversationalService @Remotable @Conversational public interface ConversationalCallback { ... } @Remotable @Conversational @Callback(ConversationalCallback.class) public interface ConversationalService { } @Scope(CONVERSATION) public class ConversationalClientImpl implements ConversationalClient, ConversationalCallback { @Reference protected ConversationalService conversationalService; } @Scope(CONVERSATION) public class ConversationalServiceImpl implements ConversationalService { @Callback protected ConversationalCallback conversationalCallback; ... } In the current implementation the specification has been interpreted to mean that the client component, i.e. the component implementing the callback interface, must be marked as having conversational scope if it is required that callback messages return to the same instance of the client component that originated the conversational call. Is this the correct interpretation of the specification, in particular Section 1.6.7.1 of the SCA Java Annotations and APIs V1.0 specification. 2/ The specifications describe the freeing of state associated with a conversation when Conversation.end() is called on a conversation object . See section 1.6.5 of the SCA Java Annotations and APIs V1.0 specification. Assuming that the Conversation object is available from a service reference within the client of the conversation then, in the current implementation, the state associated with the conversation held by the service will not be freed directly if end() is called. A separate message exchange would be required between client and service to carry this end() instruction directly. As it stands the target conversation will eventually time out. What is the specification's intention in this case? Regards Simon
Re: Monitoring, logging and exceptions (again)
On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/8/07, ant elder [EMAIL PROTECTED] wrote: On 8/7/07, Simon Laws [EMAIL PROTECTED] wrote: We talked about this before ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16784.html) but didn't come to any conclusions. So, 1/ What is the requirement? 2/ What is the technical solution? 3/ When should we try and get it done? To get things going again here are some thoughts drawn from what was said in the referenced thread. 1/ An API in line with accepted logging/management practices to support arbitrary debugging and runtime info, warning and error logging A common approach to exception/error handling specifically around the detail recorded in the error messages Internationalization/localization Execution Tracing 2/ Keeping it simple was a popular sentiment A number of java logging solutions have been proposed Log4J, SLF4J etc. I believe DAS is using Log4J. We have dependencies that also use logging tools. We can take a look at how others approach this, e.g, quick glance at the last CxF release shows they include SLF4J jars Aspects were investigated to show how they can be used for tracing, seems like an interesting optional facility but adds extra complexity/dependencies There was also a suggestion that we could implement some higher level tracing, e.g. runtime starts, stops, application loading, component instance creation etc. We need to move error message out of the code and into resource files 3/ I think we can reasonably expect to agree what approach we are going to take fairly quickly and provide some examples, i.e. before the next release? People suggested before that we take time out to go through the code based and bring it into line. This will take a lot of time but can we get it into 1.0? Please add your thoughts to the list and we can then draw them together, try some of it out and come to some conclusions. Simon +1 for going with SLF4J. If we can decide on this soon then we can all just start adding it in to the code we're working on and debugging, and then maybe have a focused sweep before 1.0 to make sure its in everywhere useful. ...ant Cross posting to the user list also as I expect this is close to everyone heart. Can everyone reply to both lists. Thanks Simon We had a similar discussion in April [1]. Here's what I suggest for logging: - Separate the trace calls from the runtime code. Insert them automatically at build time or run time using Aspectj. Raymond on SCA and Kelvin on SDO already showed how to do it. - Use SLF4J in these generated trace calls. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] Thoughts? There were several posts on that referenced thread less keen on using aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the simplicity of the more traditional approach of explicit logging calls in Tuscany. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] OK then, I don't care much about whether or not we use aspects, but I think that calls to trace method entry/exit+parameters should be externalized and inserted automatically when we build Tuscany, as IMO writing all these repetitive calls by hand will be problematic: - it's a lot of work and will be difficult to maintain and keep consistent (when methods are renamed, parameters added etc.) - it puts a big requirement on people contributing Tuscany extensions to write all these calls in their extensions as well - it will make Tuscany difficult to integrate in an environment using a different logging framework Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] A number of different requirements have been discussed and solutions proposed. My 2p (I'm using Raymond's definitions b.t.w) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) I feel that tracing of execution paths through the Tuscany codebase would be useful but agree that it's a lot of work and will be difficult to maintain and keep consistent if we did it manually. I'm happy
Re: Late resolution of reference targets - was:Accessing global domain information
On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, August 14, 2007 12:37 AM Subject: Late resolution of reference targets - was:Accessing global domain information Currently in CompositeWireBuilderImpl.connectComponentReference all targets are converted to bindings on a reference and the targets are removed. During this process the source and target bindings are compared until matching wireable bindings are found. This is not always possible because some of the targets are not resolvable at this point. Currently only the sca binding implements WireableBinding. I've opened https://issues.apache.org/jira/browse/TUSCANY-1534 about this. If the domain is distributed then at the build stage some of the targets will remain unresolved. For the new sca binding I have made the assumption here that unresolved targets take a copy of the bindings they may be resolved against at a later date and that the targets are maintained on the reference after the build stage. I still assume that the SCA binding is the only valid wireable binding at present. I start to look into this area too from a different perspetive. Please see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References . So I'm proposing that 1. The builder should retain the list of unresolved targets for use after the build stage 2. The list of bindings that might be used to resolve a target at a later date are associated with each target +1. What will the data structure look like? There are some cases that mixed styles are used to define the binding endpoint if the reference multiplicity is greater than 1 and promotion is used. For example, we can have the following: InnerComposite: composite name=InnerComposite .. component name=C1 ... reference name=myRef target=C2/S1 C3/S1 binding.sca/ binding.x/ /reference /component component name=C2 ... ... /component component name=C3 ... ... /component reference name=myOuterRef promote=C1/myRef binding.y /reference /composite composite name=OuterComposite ... component name=C4 implementation.composite=ns1:InnerComposite reference name=myOuterRef target=C5/S1/ /component ... component name=C5 ... ... /component /composite Then the effective wires for myRef will be: C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1 (binidng.y) Come wire creation time care must be take to create remote wires for unresolved targets. What I do at the moment is: CompositeActivatorImpl.addReferenceBindingProviders As before, create providers for all bindings that represent resolved targets For all unresolved targets If support is enabled create a cloned SCA binding and add it to the reference binding list (so that a wire will be created). This is pretty much what goes on in the CompositeWireBuilder but I've delayed it until here in the expectation that we will do remote binding matching one wireable support is fixed Create an SCA binding provider which will look up the remote endpoint at start() time. Thoughts? Regards Simon Sorry, but I'm having trouble understanding all this, it's starting to get a little complicated for me... Could somebody please give a *short* summary of the scenario that this is attempting to cover? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Raymond is coming at the problem from a different direction to me so I'll let him give examples. For me the scenario is composite ... name=HelloWorld component name=HelloWorldClient implementation.java class=HelloWorldClient / reference name=helloWorldService target=HelloWorldService / /component /composite Where HelloWorldService does not appear in the loaded contributions. Simon Hi, as an alternative to this is there a way that we can just create all the bindings/wires for the unresolved targets and then select the correct wire either when the invocation handler is created or even as late as when the first call is made through a reference. I've been thinking about this because it is clear that we don't know how long in the future it will be before a target is available to
Javadoc in sca/itest
I'd like to take a crack at expanding the Javadoc in the sca itests, and I'd like some feedback on the benefit and conventions of doing so. I've noticed that the Javadoc in the sca/itests could be enhanced (or in many cases is absent altogether). Javadoc seems to me a great way to document the intent of the test cases. Including the package.html and overview.html files will allow a single source of documentation. This will allow us to more easily assess test coverage of concepts (rather than merely API's). As for javadoc conventions: I'd like to add javadoc to the src/test subdirectories. This is where we would document the scenario being tested. (e.g. Attempt to locate a service with an invalid name.) I'd like to add javadoc to the src/main subdirectories to describe the requirements on the services (e.g. This must be a composite within a composite) for the test case scenario to be achieved. Please let me know if you'd like me to add or subtract from the above.
Re: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project
[snip] [EMAIL PROTECTED] wrote: Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/381/buildId/257310 Build statistics: State: Failed [snip] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Java heap space [INFO] [INFO] Trace java.lang.OutOfMemoryError: Java heap space [INFO] [INFO] Total time: 29 minutes 48 seconds [INFO] Finished at: Wed Aug 15 02:00:26 PDT 2007 [INFO] Final Memory: 63M/63M [INFO] It looks like our nightly build is breaking with out of memory exceptions. Most of us are running with more than 63M allocated to Maven and are not running into this issue in our local builds. What needs to happen for the continuum build to allocate more than 63M heap to Maven as well? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1477) CompositeActivatorImpl.deactivate() is empty
[ https://issues.apache.org/jira/browse/TUSCANY-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-1477: --- Assignee: Jean-Sebastien Delfino CompositeActivatorImpl.deactivate() is empty Key: TUSCANY-1477 URL: https://issues.apache.org/jira/browse/TUSCANY-1477 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.91 Reporter: Vamsavardhana Reddy Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-Next CompositeActivatorImpl.deactivate() is empty. Should there be some code in there? I am seeing a problem with removing components and composites from EmbeddedSCADomain. I have called EmbeddedSCADomain.DomainCompositeHelper ().stopComponent() with all the component names in my composite and then EmbeddedSCADomain.DomainCompositeHelper ().removeComposite(). I am noticing that the components are not getting removed from EmbeddedSCADomain.domainComposite. EmbeddedSCADomain.DomainCompositeHelper.removeComposite() is calling compositeActivator.deactivate(). But CompositeActivatorImpl.deactivate() is empty. -- 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: Tuscany/Geronimo Integration Demo
Simon Laws wrote: On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I am not referencing this class directly in my code. Can it be that the published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or not the latest?? I can not think of other possibilities. Vamsi On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT . The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png . The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. After switching to 1.0-incubating-SNAPSHOT, I have run into a NoClassDefFoundError: org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? GERONIMO-3351 has not been integrated into 2.0 release. Part of the problem is addressed in branches\2.0 and trunk. It affects only SNAPSHOT dependencies and there is some discussion on whether the downloaded version (if it is different from SNAPSHOT) should be renamed, by the plugin installer, to SNAPSHOT or the dependency resolution is Geronimo should handle it in a different way. The problem we have run into is in conjunction with another problem that occurs when a trailing / is not present in the maven repo URL. This has been fixed in branches\2.0 and trunk (not in 2.0 release though) and the work around for this is to put that trailing / in the maven repo URLs in geronimo-plugin.xml . These two fixes will (most likely, but not guaranteed) go into 2.0.1 due to be released soon (probably this week). [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a week or so ago when I moved the majority of sca binding into the binding-sca module. I'm thinking that I was a little overzealous when I took this out and that it probably needs to go back in. In the mean time can you create a org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl instead? Regards Simon You may very well be right. Time to push some new snapshots out! Let me find out how to do that. Simon Yes I think that new published snapshots will resolve that issue. In addition, how about adding the Tuscany/Geronimo integration modules to our build? This will help us check that we're not breaking them when we make changes in the rest of the Tuscany code. It will also make it easier for people to try out the integration from their Tuscany workspace / development environment. The simplest is probably to point to these modules in the Geronimo sandbox SVN from our java/sca/modules directory using an SVN externals property... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc in sca/itest
Hi Brian, That will be a boon to developers who want's to get started with integration tests. In addition we can also have brief documentation about itests itself or FAQ about itest. Few things those can be included are What are itests?, How to create configure a new itest module? so that surefire plugin can execute the tests successfully. Thanks, Venu. On 8/16/07, Brian Murray [EMAIL PROTECTED] wrote: I'd like to take a crack at expanding the Javadoc in the sca itests, and I'd like some feedback on the benefit and conventions of doing so. I've noticed that the Javadoc in the sca/itests could be enhanced (or in many cases is absent altogether). Javadoc seems to me a great way to document the intent of the test cases. Including the package.html and overview.html files will allow a single source of documentation. This will allow us to more easily assess test coverage of concepts (rather than merely API's). As for javadoc conventions: I'd like to add javadoc to the src/test subdirectories. This is where we would document the scenario being tested. (e.g. Attempt to locate a service with an invalid name.) I'd like to add javadoc to the src/main subdirectories to describe the requirements on the services (e.g. This must be a composite within a composite) for the test case scenario to be achieved. Please let me know if you'd like me to add or subtract from the above. -- - A 'wish' changes nothing. A 'decision' changes everything! Anon Even if you're on the right track, you'll get run over if you just sit there. Will Rogers
build failure in java2wsdl
Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl
Re: build failure in java2wsdl
Are you using IBM JDK ? Looks like my latest changes have some issues with that JDK. On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build failure in java2wsdl
On 8/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Are you using IBM JDK ? Looks like my latest changes have some issues with that JDK. On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl -- 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] Yep - I'm on the IBM JDK. I guess I can get away without the wsdl generation pieces for now unless you know a quick fix? Simon
Re: Javadoc in sca/itest
Hi, Javadoc for iTests will help clearify what is there or missing and help the reader to better understand the tests. I went through itests once to try to figure out what is missing and how I can potentially contribute. I did not get too far. Venu, your idea of 'how to create configure a new itest module or what are itests' are things that can be covered in the development guide. There is already a 'test' section in this guide that seems to be a bit out dated. [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html#SCAJavaDevelopmentGuide-Testing Just a suggestion.. Haleh On 8/16/07, venu reddy [EMAIL PROTECTED] wrote: Hi Brian, That will be a boon to developers who want's to get started with integration tests. In addition we can also have brief documentation about itests itself or FAQ about itest. Few things those can be included are What are itests?, How to create configure a new itest module? so that surefire plugin can execute the tests successfully. Thanks, Venu. On 8/16/07, Brian Murray [EMAIL PROTECTED] wrote: I'd like to take a crack at expanding the Javadoc in the sca itests, and I'd like some feedback on the benefit and conventions of doing so. I've noticed that the Javadoc in the sca/itests could be enhanced (or in many cases is absent altogether). Javadoc seems to me a great way to document the intent of the test cases. Including the package.html and overview.html files will allow a single source of documentation. This will allow us to more easily assess test coverage of concepts (rather than merely API's). As for javadoc conventions: I'd like to add javadoc to the src/test subdirectories. This is where we would document the scenario being tested. (e.g. Attempt to locate a service with an invalid name.) I'd like to add javadoc to the src/main subdirectories to describe the requirements on the services (e.g. This must be a composite within a composite) for the test case scenario to be achieved. Please let me know if you'd like me to add or subtract from the above. -- - A 'wish' changes nothing. A 'decision' changes everything! Anon Even if you're on the right track, you'll get run over if you just sit there. Will Rogers
Distributed Runtime and Distributed Calculator
Hi, i'm highly interested in contributing to the distributed runtime. Actually I'm trying to understand if this component model could be the building block for creating autonomic components. An autonomic component can consist of one or more managed components coupled with a single manager that controls them. To pursue its goal, the manager may trigger an adaptation of the managed components to react to a run-time change (i.e. fault, load balancing, etc). Some questions..i've updated the svn and it builds but not the distributed-calculator. Why? (It could be for me a starting point). Cheers, Jo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build failure in java2wsdl
Hi, I fixed it under r566814. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 16, 2007 12:24 PM Subject: Re: build failure in java2wsdl On 8/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Are you using IBM JDK ? Looks like my latest changes have some issues with that JDK. On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl -- 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] Yep - I'm on the IBM JDK. I guess I can get away without the wsdl generation pieces for now unless you know a quick fix? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed Runtime and Distributed Calculator
On 8/16/07, Giorgio Zoppi [EMAIL PROTECTED] wrote: Hi, i'm highly interested in contributing to the distributed runtime. Actually I'm trying to understand if this component model could be the building block for creating autonomic components. An autonomic component can consist of one or more managed components coupled with a single manager that controls them. To pursue its goal, the manager may trigger an adaptation of the managed components to react to a run-time change (i.e. fault, load balancing, etc). Some questions..i've updated the svn and it builds but not the distributed-calculator. Why? (It could be for me a starting point). Cheers, Jo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Jo and welcome to Tuscany I'm just making some changes to the calculator sample to fix it up so it will work again. What we have is a a simple scenario where you start 3 nodes that run SCA components for different parts of the calculator application and the nodes talk to a registry to find out what components are on which node. Very simple at the moment but the framework is in place to add all sorts of interesting component management options. Sounds like you have some good ideas. Let me get the sample fixed up and I'll post back here. You can then look at something that runs. Regards Simon
Re: build failure in java2wsdl
On 8/16/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I fixed it under r566814. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 16, 2007 12:24 PM Subject: Re: build failure in java2wsdl On 8/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Are you using IBM JDK ? Looks like my latest changes have some issues with that JDK. On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl -- 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] Yep - I'm on the IBM JDK. I guess I can get away without the wsdl generation pieces for now unless you know a quick fix? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks guys Simon
[jira] Commented: (TUSCANY-1480) Calling EmbeddedSCADomain.activateDomain() after adding a contribution renders services from previous contribution unusable
[ https://issues.apache.org/jira/browse/TUSCANY-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520356 ] Vamsavardhana Reddy commented on TUSCANY-1480: -- The following may be used to create a testcase for this JIRA: 1.scaDomain = new EmbeddedSCADomain(...); scaDomain.start(); 2. // Add contribution from calculator sample 3. scaDomain.getDomainCompositeHelper().activateDomain() 4. // Call scaDomain.getDomainCompositeHelper().startComponent() on each of the components from calculator sample 5. //At this step access the service provided by calculator sample. 6. // Add contribution from helloworld sample 7. scaDomain.getDomainCompositeHelper().activateDomain() 8. // Call scaDomain.getDomainCompositeHelper().startComponent() on each of the components from helloworld sample 9. // At this step access service provided by calculator sample. calculator service should be accessible. Note:This is failing currenly // Access service provided by helloworld sample. helloworld service should be accessible. Calling EmbeddedSCADomain.activateDomain() after adding a contribution renders services from previous contribution unusable Key: TUSCANY-1480 URL: https://issues.apache.org/jira/browse/TUSCANY-1480 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.91 Reporter: Vamsavardhana Reddy Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-Next Here is a situation I am running into. Step 0: Create an EmbeddedSCADomain. Step 1: Add contribution from contribution1.jar (which provides say Service1) to EmbeddedSCADomain from Step 0. Step 2: Call EmbeddedSCADomain.DomainCompositeHelper.activateDomain() Step 3: Call EmbeddedSCADomain.DomainCompositeHelper.startComponent() on all componets from contribution1.jar. Step 4: Add contribution from contribution2.jar (which provides say Service2) to EmbeddedSCADomain from Step 0. Step 5: Call EmbeddedSCADomain.DomainCompositeHelper.activateDomain() Step 6: Call EmbeddedSCADomain.DomainCompositeHelper.startComponent() on all componets from contribution2.jar. After Step 3, I am able to run Service1 successfully. At Step 5, I get a message like the following: Composite assembly problem: Service not found for component service: CalculatorServiceComponent/$promoted$.CalculatorService After Step 6, Service1 no longer runs, where as Service2 runs successfully. If I call DomainCompositeHelper.startComponent() on each of the components from the first contribution after deploying the second, (that is after Step 6 from), it results in an Exception which I ignore and continue. But towards the end I have services from both contributions running successfully. -- 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]
[DAS Native] ant build
Adriano, You might have seen that both SCA and SDO native now have an ant build infrastructure. I briefly looked at doing the same for DAS, but couldn't get it to compile with configure, make, make install at the time, and never got a chance to come back to it. I think it should be very easy to copy the SDO ant stuff over to DAS, what do you think? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Monday, July 23, 2007 11:21 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build Great idea, soon I will try to apply this idea to Native DAS and see how it works. I think the idea could also be easily applied to Native SDO, as it does not have too much dependencies and code generation as Native SCA does. A folder ant-core could be created under tuscany/cpp/ folder to place the ant scripts shared by the projects. Also, we could add a build.xml under tuscany/ccp/ that builds all 3 subprojects at once, if the 3 to implement this ant build process. What do you think? Regards, Adriano Crestani On 7/23/07, Brady Johnson [EMAIL PROTECTED] wrote: Correction, it should be like this: target name=compile.core cpp-compile srcdir=${core.abs.dir} objdir=${lib.dir} infiles=${core.cpp.files} custom-cc-elements defineset if=windows define=SCA_EXPORTS/ /custom-cc-elements /cpp-compile /target Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 5:05 PM To: tuscany-dev@ws.apache.org Subject: RE: [SCA Native] preliminary ant build Pete, Good catch. That's an easy fix. I'll submit it with the next patch tomorrow. Basically it involves removing SCA_EXPORTS from the Tuscany-BaseCompiler and adding it to the runtime/core/src targets: compile.core compile.extension compile.model compile.util Like this: target name=compile.core cpp-compile srcdir=${core.abs.dir} objdir=${lib.dir} infiles=${core.cpp.files}/ custom-cc-element defineset if=windows define=SCA_EXPORTS/ /custom-cc-element /target Tomorrow I'll have the python, ruby, rest, and maybe php extensions complete. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:41 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build I think there is a problem in the extension compilations. The SCA_EXPORTS directive should only be set when compiling the runtime/core. When compiling for dlls on windows which use the core dll SCA_EXPORTS must not be set. I guess this means we have to move the setting of this directive from the definition of the Tuscany-BaseCompiler Cheers, On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote: I've applied the patch. How are you creating the patches? I had trouble applying it on Windows using ToirtoiseSVN. I've included the changes in the patch to the tools/TuscanyDriver build. I haven't tested this and I'm not sure if it works with the system.xml etc. Can you do a clean extract as a base for future patches? Cheers, On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote: I'll give this a go. I should be able to run it on Mac as well. Cheers, On 23/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I updated the jira1438 with update 3, which includes the following: https://issues.apache.org/jira/browse/TUSCANY-1438 - added build.xml for the following dirs: runtime/extensions/build.xml runtime/extensions/cpp/build.xml runtime/extensions/sca/build.xml runtime/extensions/ws/build.xml - changed system.xml to check for necessary axis, php, python, rest, and ruby env vars. If they're not set in the env, look for them in platform.properties - changed compile-targets.xml targets cpp-install-headers/ to cpp-install-files/ cpp-install-lib/ to cpp-install-file/ - added compile-targets.xml target: cpp-symlink/ - added library versioning and the platform.tuscanySCA.library.version platform.properties property Can someone submit this for me. The only thing left now is the build.xml for these extensions: php, python, rest, ruby WRT testing on macs, I wont have a mac available until next week. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types
[ https://issues.apache.org/jira/browse/TUSCANY-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1540. - Resolution: Fixed Fixed in revision 566876. I changed the generator to generate a concrete inner subclass for abstract Impl classes: public abstract class AbstractTestImpl extends DataObjectBase implements AbstractTest { public static class ConcreteBase extends AbstractTestImpl { public ConcreteBase() { super(); } } ... } and then added code in FactoryBase$SDOEFactoryImpl.create() to use it if the type is abstract. I've tested it with the following simple program: public static void main(String[] args) throws IOException { HelperContext context = SDOUtil.createHelperContext(); Junk3Factory.INSTANCE.register(context); TypeHelper typeHelper = context.getTypeHelper(); DataFactory factory = context.getDataFactory(); Type abstractType = typeHelper.getType(http://www.example.org/junk/;, AbstractTest); //DataObject testObject = factory.create(abstractType); // should fail // Create an subtype DataObject exampleType = DataFactory.INSTANCE.create(commonj.sdo, Type); exampleType.set(uri, NSURI); exampleType.set(name, Example); exampleType.getList(baseType).add(abstractType); Type type = TypeHelper.INSTANCE.define(exampleType); DataObject testObject2 = factory.create(type); if (testObject2.getClass() == AbstractTestImpl.ConcreteBase.class) System.out.println(SUCCESS); else System.out.println(FAIL); } It would be good to get a proper JUnit for it. Any volunteers? Abstract Static Base Types mixed with Dynamic Extended Types Key: TUSCANY-1540 URL: https://issues.apache.org/jira/browse/TUSCANY-1540 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Reporter: Murtaza Goga Fix For: Java-SDO-Next Setting a property on a static data object with an object of a type extended in a dynamic model results in a ClassCastException. Scenario: Static schema- xsd:complexType name=CustomerType xsd:all xsd:element name=number type=xsd:integer / xsd:element form=unqualified name=info type=InfoType / /xsd:all /xsd:complexType xsd:complexType name=InfoType abstract=true/ Dynamic Schema xsd:complexType name=InfoType xsd:complexContent xsd:extension base=staticNS:InfoType xsd:sequence xsd:element name=zipcode type=xsd:string / /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType The following will fail: DataFactory factory = scope.getDataFactory(); factory.create(CustomerType.class).setDataObject(info, factory.create(dynamicNS, InfoType)); It should be legal to assign a property to an object if they are in the same hierachy. Steps to reproduce within Tuscany: Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 'InfoType' defined in extensible/customer.xsd is marked as abstract. -- 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-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520416 ] Sunny Ip commented on TUSCANY-1541: --- I wasn't sure what the best way of getting all the various classes initialized outside of the SCA environment was, so this is what I did to try to simulate the serialize/deserialize process: /* populate response */ String responseStr = XMLHelper.INSTANCE.save((DataObject)response,http://namespace,ResponseType;); XMLStreamHelperImpl strHelper = new XMLStreamHelperImpl(HelperProvider.getDefaultContext()); XMLDocument doc = XMLHelper.INSTANCE.load(responseStr); XMLStreamReader reader = strHelper.createXMLStreamReader(doc); reader.next(); DataObject obj = strHelper.loadObject(reader); return response; after populating response (which is an SDO generated object) with a collection of child SDO objects in my service impl, which is a component in the SCADomain. This succeeded without any problems, and the resulting DataObject looked fine. However, I return the original response back to the invoking client (through a web service binding) and get the XMLStreamException. If the collection in my response contains less objects, then everything works fine. When I have more than 30 (in this case) objects in the collection, manually calling XMLStreamHelper works but the invoking client fails. XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical Fix For: Java-SDO-Next When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- 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: Tuscany/Geronimo Integration Demo
On 8/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I am not referencing this class directly in my code. Can it be that the published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or not the latest?? I can not think of other possibilities. Vamsi On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT . The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png . The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. After switching to 1.0-incubating-SNAPSHOT, I have run into a NoClassDefFoundError: org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? GERONIMO-3351 has not been integrated into 2.0 release. Part of the problem is addressed in branches\2.0 and trunk. It affects only SNAPSHOT dependencies and there is some discussion on whether the downloaded version (if it is different from SNAPSHOT) should be renamed, by the plugin installer, to SNAPSHOT or the dependency resolution is Geronimo should handle it in a different way. The problem we have run into is in conjunction with another problem that occurs when a trailing / is not present in the maven repo URL. This has been fixed in branches\2.0 and trunk (not in 2.0 release though) and the work around for this is to put that trailing / in the maven repo URLs in geronimo-plugin.xml . These two fixes will (most likely, but not guaranteed) go into 2.0.1 due to be released soon (probably this week). [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a week or so ago when I moved the majority of sca binding into the binding-sca module. I'm thinking that I was a little overzealous when I took this out and that it probably needs to go back in. In the mean time can you create a org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl instead? Regards Simon You may very well be right. Time to push some new snapshots out! Let me find out how to do that. Simon Yes I think that new published snapshots will resolve that issue. In addition, how about adding the Tuscany/Geronimo integration modules to our build? This will help us check that we're not breaking them when we make changes in the rest of the Tuscany code. It will also make it easier for people to try out the integration from their Tuscany workspace / development environment. The simplest is probably to point to these modules in the Geronimo sandbox SVN from our java/sca/modules directory using an SVN externals property... Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok, I've published a new set of snapshots for the SCA modules (I haven't done samples or itests). I tested against the current SDO snapshots. Let us know if this gets you any further forward. Regards Simon
Re: [DAS Native] ant build
Hi Brady, Yes, I was plaining to do that after this weekend. I had no chance to do that so far, cause I was really busy with college's stuffs :( Regards, Adriano Crestani On 8/16/07, Brady Johnson [EMAIL PROTECTED] wrote: Adriano, You might have seen that both SCA and SDO native now have an ant build infrastructure. I briefly looked at doing the same for DAS, but couldn't get it to compile with configure, make, make install at the time, and never got a chance to come back to it. I think it should be very easy to copy the SDO ant stuff over to DAS, what do you think? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: Monday, July 23, 2007 11:21 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build Great idea, soon I will try to apply this idea to Native DAS and see how it works. I think the idea could also be easily applied to Native SDO, as it does not have too much dependencies and code generation as Native SCA does. A folder ant-core could be created under tuscany/cpp/ folder to place the ant scripts shared by the projects. Also, we could add a build.xml under tuscany/ccp/ that builds all 3 subprojects at once, if the 3 to implement this ant build process. What do you think? Regards, Adriano Crestani On 7/23/07, Brady Johnson [EMAIL PROTECTED] wrote: Correction, it should be like this: target name=compile.core cpp-compile srcdir=${core.abs.dir} objdir=${lib.dir} infiles=${core.cpp.files} custom-cc-elements defineset if=windows define=SCA_EXPORTS/ /custom-cc-elements /cpp-compile /target Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 5:05 PM To: tuscany-dev@ws.apache.org Subject: RE: [SCA Native] preliminary ant build Pete, Good catch. That's an easy fix. I'll submit it with the next patch tomorrow. Basically it involves removing SCA_EXPORTS from the Tuscany-BaseCompiler and adding it to the runtime/core/src targets: compile.core compile.extension compile.model compile.util Like this: target name=compile.core cpp-compile srcdir=${core.abs.dir} objdir=${lib.dir} infiles=${core.cpp.files}/ custom-cc-element defineset if=windows define=SCA_EXPORTS/ /custom-cc-element /target Tomorrow I'll have the python, ruby, rest, and maybe php extensions complete. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 2:41 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build I think there is a problem in the extension compilations. The SCA_EXPORTS directive should only be set when compiling the runtime/core. When compiling for dlls on windows which use the core dll SCA_EXPORTS must not be set. I guess this means we have to move the setting of this directive from the definition of the Tuscany-BaseCompiler Cheers, On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote: I've applied the patch. How are you creating the patches? I had trouble applying it on Windows using ToirtoiseSVN. I've included the changes in the patch to the tools/TuscanyDriver build. I haven't tested this and I'm not sure if it works with the system.xml etc. Can you do a clean extract as a base for future patches? Cheers, On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote: I'll give this a go. I should be able to run it on Mac as well. Cheers, On 23/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I updated the jira1438 with update 3, which includes the following: https://issues.apache.org/jira/browse/TUSCANY-1438 - added build.xml for the following dirs: runtime/extensions/build.xml runtime/extensions/cpp/build.xml runtime/extensions/sca/build.xml runtime/extensions/ws/build.xml - changed system.xml to check for necessary axis, php, python, rest, and ruby env vars. If they're not set in the env, look for them in platform.properties - changed compile-targets.xml targets cpp-install-headers/ to cpp-install-files/ cpp-install-lib/ to cpp-install-file/ - added compile-targets.xml target: cpp-symlink/ - added library versioning and the platform.tuscanySCA.library.version platform.properties property
[jira] Updated: (TUSCANY-1542) BPEL extension to link sca component into a business process
[ https://issues.apache.org/jira/browse/TUSCANY-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1542: Component/s: Java SCA BPEL Implementation Extension BPEL extension to link sca component into a business process Key: TUSCANY-1542 URL: https://issues.apache.org/jira/browse/TUSCANY-1542 Project: Tuscany Issue Type: Wish Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-Next Reporter: gengshaoguang Fix For: Java-SCA-Next What I expect next is: extend a bpel engine, make it interact with Tuscany's sca binding. Of course any bpel engine might link wsdl naturaly. But in the latter case, we make no improvement to SOA tech. BPEL-SCA should work in a more direct way and more effect way. I think SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at section 1.4 . I open this issue to arouse collaboration from all of you. Thanks. -- 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-1542) BPEL extension to link sca component into a business process
[ https://issues.apache.org/jira/browse/TUSCANY-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520446 ] Jean-Sebastien Delfino commented on TUSCANY-1542: - The work started under java/sca/modules/implementation-bpel is about implementing what's described in the SCA Client and Implementation Model Spec for WS-BPEL [1]. Could you please explain why you think this work is different from what's described in the spec or not covering what you're looking for? Thanks. [1] http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1 BPEL extension to link sca component into a business process Key: TUSCANY-1542 URL: https://issues.apache.org/jira/browse/TUSCANY-1542 Project: Tuscany Issue Type: Wish Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-Next Reporter: gengshaoguang Fix For: Java-SCA-Next What I expect next is: extend a bpel engine, make it interact with Tuscany's sca binding. Of course any bpel engine might link wsdl naturaly. But in the latter case, we make no improvement to SOA tech. BPEL-SCA should work in a more direct way and more effect way. I think SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at section 1.4 . I open this issue to arouse collaboration from all of you. Thanks. -- 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: Tuscany/Geronimo Integration Demo
Hit a new error. Stack trace given below: java.lang.NoClassDefFoundError: org/apache/tuscany/sca/interfacedef/java/introspect/JavaInterfaceIntrospectorExtensionPoint at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.loadModules( ReallySmallRuntime.java:181) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start( ReallySmallRuntime.java:133) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start( EmbeddedSCADomain.java:74) Vamsi On 8/17/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I am not referencing this class directly in my code. Can it be that the published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or not the latest?? I can not think of other possibilities. Vamsi On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT . The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png . The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. After switching to 1.0-incubating-SNAPSHOT, I have run into a NoClassDefFoundError: org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? GERONIMO-3351 has not been integrated into 2.0 release. Part of the problem is addressed in branches\2.0 and trunk. It affects only SNAPSHOT dependencies and there is some discussion on whether the downloaded version (if it is different from SNAPSHOT) should be renamed, by the plugin installer, to SNAPSHOT or the dependency resolution is Geronimo should handle it in a different way. The problem we have run into is in conjunction with another problem that occurs when a trailing / is not present in the maven repo URL. This has been fixed in branches\2.0 and trunk (not in 2.0 release though) and the work around for this is to put that trailing / in the maven repo URLs in geronimo-plugin.xml . These two fixes will (most likely, but not guaranteed) go into 2.0.1 due to be released soon (probably this week). [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a week or so ago when I moved the majority of sca binding into the binding-sca module. I'm thinking that I was a little overzealous when I took this out and that it probably needs to go back in. In the mean time can you create a org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl instead? Regards Simon You may very well be right. Time to push some new snapshots out! Let me find out how to do that. Simon Yes I think that new published snapshots will resolve that issue. In addition, how about adding the Tuscany/Geronimo integration modules to our build? This will help us check that we're not breaking them when we make changes in the rest of the Tuscany code. It will also