[jira] Assigned: (TUSCANY-1848) Tuscany cannot inject a many value Property into an array
[ https://issues.apache.org/jira/browse/TUSCANY-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan reassigned TUSCANY-1848: Assignee: Venkatakrishnan Tuscany cannot inject a many value Property into an array - Key: TUSCANY-1848 URL: https://issues.apache.org/jira/browse/TUSCANY-1848 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Environment: SVN Head revision #584454 Linux Reporter: Mark Combellack Assignee: Venkatakrishnan Priority: Minor Fix For: Java-SCA-Next Attachments: PropertyInjectionIntoArray.patch, PropertyInjectionIntoArray_iTest.patch Currently, Tuscany cannot inject multi value properties into methods/fields that are defined as an array type. For example, the following injection scenarios do not work: @Property(name = daysOfTheWeek) protected String[] daysOfTheWeek; @Property(name = integerNumbers) protected Integer[] integerNumbers; @Property(name = intNumbers) protected int[] intNumbers; @Property(name = sdoArray) protected DataObject[] sdoArray; There is no sample in the Java Common Annotations and APIs specification that says this should be allowed. However, it does strongly suggest it should be: 1369 If the property is defined as an array or as a java.util.Collection, then the implied component type has a 1370 property with a many attribute set to true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading in Tuscany
Mike, There are two sets of classloading in Tuscany that we need to look at and these can be handled independently of each other. 1) Classloading architecture for SCA contributions 2) Classloading architecture for SCA runtime modules In both cases, there are two ways of improving modularity in Tuscany a) Use separate classloaders per module to provide isolation, using a classloader architecture similar to OSGi, but without actually running in an OSGi runtime. b) Use OSGi bundles to provide module isolation and versioning, where the versioning support would rely on an OSGi runtime. For both 1) and 2), we could support a) and/or b). Tuscany already supports 1b), and the proposed fixes will support 1a). Tuscany does not implement 2a) or 2b), and if done properly, the implementation would required code changes that are pervasive across Tuscany. So the question is - do we really want to run Tuscany modules as separate OSGi bundles (or isolate modules using separate classloaders)? IMHO, it is only worth the hassle, if Tuscany modules are properly versioned and dynamically replaceable - ie, run as bundles in an OSGi runtime (2b). The proposed fixes do not implement 2a) and provide a partial solution for 2b) based on OSGi manifest files to minimize code changes to Tuscany. 1) Classloading architecture for SCA contributions At the moment, OSGi bundle contributions can be used in Tuscany which provide modularity and versioning with the help of an OSGi runtime. Plain Jar contributions or folders use a single classloader at the moment and the proposed fixes will introduce contribution classloaders to isolate contributions. SCA contributions can specify dependencies in terms of import/export statements in the same way as OSGi bundles. If you consider Java contributions, SCA contribution dependencies are a subset of OSGi bundle dependencies, because SCA does not support versioning or any of the other attributes that can be associated with importing packages in OSGi. So SCA contribution classloading will be a simpler version of OSGi bundle classloading. The code for supporting SCA import/export is already in place in Tuscany- it just doesn't get used because the thread context classloader is currently used to resolve classes. 2) Classloading architecture for SCA runtime modules At the moment, Tuscany uses a single classloader for the runtime and its dependencies, and even though Tuscany runtime architecture uses extensible modules with reasonably well defined dependencies, module isolation is not achieved because of the use of a single classloader. Tuscany also has dependencies on many libraries which rely on the thread context classloader. Even though we are looking at running Tuscany in an OSGi runtime to support distributed-OSGi, at the moment we are still assuming that by default Tuscany would be run without an OSGi runtime. Hence the proposed fixes aim to minimize Tuscany changes required to implement 2b). Tuscany's use of thread context classloader will be removed wherever possible, but the requirement on thread context classloader will not be removed altogether since it is used by libraries that Tuscany depends on. There are two issues with modularizing Tuscany runtime using OSGi or OSGi-style classloading. Thread context classloaders and OSGi dont go very well together. And the extension module architecture used by Tuscany where a core module is extended through the use of extension modules ends up in a classloader hierarchy which is the reverse of what is required - the core bundle does not have visibility of the classes from the extension bundles. There is an OSGi RFP which addresses classloading enhancements for OSGi including those required for applications relying on thread context classloaders. Possible solutions to implement 2b) now include the use of DynamicImport-Package, Eclipse buddy policy, Spring-OSGi Extender Model or OSGi services. If we want to implement 2a) and 2b) properly at some point, it might make sense to provide a solution that uses a utility library to implement all classloading (which can then do something different based on whether Tuscany is running inside an OSGi runtime or outside). But the changes required for this will be pervasive across Tuscany code. Thank you... Regards, Rajini On 10/12/07, Mike Edwards [EMAIL PROTECTED] wrote: Rajini, Little though here: - can this be done in a way that moves us closer to the OSGi handling of classloading? - so if ever we wanted an OSGi style runtime, it would be easier to adapt what we have... Yours, Mike. Rajini Sivaram wrote: Thank you, Ant. I will try to split the work into small pieces and submit separate patches. Thank you... Regards, Rajini On 10/12/07, ant elder [EMAIL PROTECTED] wrote: On 10/11/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, Tuscany's use of classloaders doesn't seem to be well-defined, even though the concept of a runtime classLoader
[jira] Resolved: (TUSCANY-1848) Tuscany cannot inject a many value Property into an array
[ https://issues.apache.org/jira/browse/TUSCANY-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan resolved TUSCANY-1848. -- Resolution: Fixed Thanks for the patches. Applied parts of the patch to java-implementation-runtime under r584750. Applied entire patch to itest-properties under r584751 - Venkat Tuscany cannot inject a many value Property into an array - Key: TUSCANY-1848 URL: https://issues.apache.org/jira/browse/TUSCANY-1848 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Environment: SVN Head revision #584454 Linux Reporter: Mark Combellack Assignee: Venkatakrishnan Priority: Minor Fix For: Java-SCA-Next Attachments: PropertyInjectionIntoArray.patch, PropertyInjectionIntoArray_iTest.patch Currently, Tuscany cannot inject multi value properties into methods/fields that are defined as an array type. For example, the following injection scenarios do not work: @Property(name = daysOfTheWeek) protected String[] daysOfTheWeek; @Property(name = integerNumbers) protected Integer[] integerNumbers; @Property(name = intNumbers) protected int[] intNumbers; @Property(name = sdoArray) protected DataObject[] sdoArray; There is no sample in the Java Common Annotations and APIs specification that says this should be allowed. However, it does strongly suggest it should be: 1369 If the property is defined as an array or as a java.util.Collection, then the implied component type has a 1370 property with a many attribute set to true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-1849) Callbacks over Web Service binding don't conform to the WS-Addressing spec
I thought of another alternative for the protocol. We could use Tuscany-specific headers instead of WS-Addressing headers for the additional information. WS-Addressing would only be used for the callback's endpoint. Something like: Request message: tuscany:ReferenceParameters xmlns:wsa=... xmlns:tuscany=... tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID tuscany:CallbackReference wsa:EndpointReference wsa:Address...URI of the service for the callback.../wsa:Address /wsa:EndpointReference /tuscany:CallbackReference /tuscany:ReferenceParameters Callback message: tuscany:ReferenceParameters xmlns:wsa=... xmlns:tuscany=... tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID /tuscany:ReferenceParameters Simon Simon Nash wrote: I have discovered that the protocol that Tuscany 1.0 is using for callbacks over the Web Service binding is not compliant with the WS-Addressing spec. We are using the wsa:To header to pass an EPR with reference parameters. This violates the WS-Addressing spec, which requires the wsa:To value to be a URI and not a wsa:EndpointReference. The proposal to use wsa:To was mine, and I should have checked this more carefully at the time. I think the easiest change to make us compliant is to attach the wsa:ReferenceParameters element (containing the Tuscany parameters CallbackID, ConversationID and CallbackReference) to the wsa:From header instead of attaching it to the wsa:To header. The wsa:EndpointReference within the wsa:From header would be the special anonymous value. I believe we also need to send a wsa:To header containing the destination URI in order to be compliant with the WS-Addressing spec. (If we don't specify wsa:To, the default is anonymous which means the To endpoint is not addressable.) This would produce the following request and callback messages. Request message: wsa:To...URI of the service being invoked.../wsa:To wsa:From wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... wsa:Addresshttp://www.w3.org/2005/08/addressing/anonymous/wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID tuscany:CallbackReference wsa:EndpointReference wsa:Address...URI of the service for the callback.../wsa:Address /wsa:EndpointReference /tuscany:CallbackReference /wsa:ReferenceParameters /wsa:EndpointReference /wsa:From Callback message: wsa:To...URI of the service for the callback.../wsa:To wsa:From wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... wsa:Addresshttp://www.w3.org/2005/08/addressing/anonymous/wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID /wsa:ReferenceParameters /wsa:EndpointReference /wsa:From Now for the nasty part. If we make this change, we will break interoperability between the new fixed code and Tuscany 1.0. We could make the new code also accept the old format without too much difficulty, but there's no way to make the old code accept the new format. There's also no way to identify the old code so that the new code can send it the old format. In a previous life, I worked on a product that handled these situations with a proprietary protocol to exchange partner version information so that newer code could know it was speaking to older code and send it the appropriate back-level protocol. It's ugly and it only works when the same product is at both ends of the communication. I doubt that we would want to use such a scheme in Tuscany. Any thoughts on the above proposed protocol, and/or how we should handle the incompatibility with Tuscany 1.0? Simon Simon Nash (JIRA) wrote: Callbacks over Web Service binding don't conform to the WS-Addressing spec -- Key: TUSCANY-1849 URL: https://issues.apache.org/jira/browse/TUSCANY-1849 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: All Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-1.1 In discussions on the OASIS sca-bindings list about callbacks over the Web Service binding, it has been pointed out that Tuscany's use of the WS-Addressing wsa:To header to pass an EPR with reference parameters violates the WS-Addressing spec, which requires the wsa:To value to be a URI. I'll start a discussion on tuscany-dev about how best to fix this without breaking interoperability with Tuscany 1.0. - To unsubscribe, e-mail: [EMAIL
Re: [VOTE] Graduate Tuscany as a top level project
On 10/13/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Ant, Are there any issues that should be pointed out, such as the (hopefully) mechanical licensing header issue in stdcxx, or community diversity, which at least in part is measuring independence from corporate backing (a popular thread this past month)? It seems that the latter should be well in hand, but I'll not assume. :-) --- Noel Tuscany has no legal or licensing issues that I'm aware of. RAT has been run numerous times over all the releases we've done, and the code scrutinized in lots of release reviews (and from all those release review comments the Tuscany ppmc have a learnt lots about the Apache release requirements). The biggest recent issue was when a dependency on bouncycastle got added but we've removed that for now till the IDEA patent issues are resolved. There were 11 committers when the Tuscany poddling was first created and over the course of incubation 19 new committers have been added giving a diversity of something like 5 or 6 different companies and several independents. Not all of those are currently active, and a couple probably wont ever be again, but others may become active again from time to time depending on their own needs and uses of Tuscany. There does still remain at least the minimum of three legally independent committers, and the with so many new committers being voted in over incubation it shows Tuscany is completely open to accepting new people. ...ant
[jira] Commented: (TUSCANY-1817) Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests
[ https://issues.apache.org/jira/browse/TUSCANY-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534846 ] Kelvin Goodson commented on TUSCANY-1817: - Thanks for your suggestions. One small problem we would have to overcome is that maven does not make test code available from one project to another project that expresses a dependency on it. Moving some part of the test code into the implementation wouldn't be nice from the point of view the run-time artifacts that are distributed. Separating testing out into higher level projects means we wouldn't get the automatic benefits of an immediate notification of the introduction of an issue when building with maven. We could insert an intermediate test-core project, that is not part of the SDO distribution, either between the API project and the lib projects (in dependency terms) or between the lib and the impl projects. The bodies of the tests could then be implemented in the _main_ source folder hierarchy of that project (as opposed to the test code hierarchy). The test bodies would be in abstract classes with template methods as you suggest. The lib, impl and tools-tests projects can then declare a test scope dependency on that new project, and the test programs be implemented in the test code hierarchy of the implementation projects, extending the behaviour of the test programs in the new project. Similarly the tools-test project could declare a dependency on the new project. There would be a deficiency here that I haven't got my head round yet. If we want a single location for the schemas, then they would have to be in the new project. This means I think that we wouldn't be able to rely on maven's generate phase to handle the generation for us in the tools-test project. One possibility would be to use svn's externals property to make the same schema files available to the test resources of both projects, but that may be a trip hazard. Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests --- Key: TUSCANY-1817 URL: https://issues.apache.org/jira/browse/TUSCANY-1817 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Fix For: Java-SDO-Next Currently, static Tuscany SDO is being inadequately tested. Based on TUSCANY-1812, I suspect there are currently numerous dynamic test cases that would fail if they were executed as static test cases. I suggest the testing infrastructure be enhanced to allow tests to be re-used as both dynamic and static tests with minimal effort. The build should automatically execute these shared tests in both dynamic and static contexts. -- 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]
SCA/SDO briefings in India and North America
Friends, we've finalized the schedule for SCA/SDO briefings in India and North America for the rest of the year. These are vendor-neutral events in which we talk about the joys of SCA and SDO, using Tuscany for the demos. Here are the events: November 6 - Chennai, Taj Coromandel Hotel, 1315-1715 November 7 - Kolkata, Taj Bengal Hotel, 1315-1715 November 13 - Bangalore, Taj West End Hotel, 1315-1715 November 14 - Delhi, Taj Ambassador Hotel, 1315-1715 November 27 - Toronto, IBM Innovation Center, 0900-1300 November 29 - Boston, IBM Cambridge, 0900-1300 December 4 - San Francisco, IBM Market Street, 0900-1300 The registration page for these events is at http://www.ibm.com/developerworks/offers/techbriefings/details/scasdo.html?S_TACT=105AGX01S_CMP=HP. The more the merrier; if you'd like to bring your expertise, your friends, your mom, whatever, that would be great. To our friends in India: The gap between the Kolkata and Bangalore dates is for Diwali. I don't know how long the part lasts (it's my first Diwali), but if anybody's interested in talking about SCA (system integrators, particularly), let me know. Cheers, -Doug senior software engineer emerging technology evangelism, ibm swg strategy http://www.ibm.com/developerWorks/
[AXIS2] Leverage axis2-metadata to handle JSR181/JAXWS annoations and Java2WSDL mapping?
Hi, I'm looking for some capabilities in Axis2 to support JSR181/JAXWS as follows: 1) Introspect a service implementation class and/or service endpoint interface (SEI) to handle JSR181/JAXWS annotations. Provide the default values if customization is not present. 2) A utility method to generate a WSDL4J Defintion following the rules defined by JAX-WS 2.0 Chapter 3 Java to WSDL 1.1 mapping rules. I had a brief look of the axis2-metadata module. The closest method I can find is: org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(Class) But it only accepts service implementation class and is not happy with SEI. I cannot construct the EndpointInterfaceDescription directly as all the XXXDescriptionImpl classes are not public. Would it be possible to have some methods on org.apache.axis2.jaxws.description.DescriptionFactory? // Create the endpoint interface description from the SEI public static EndpointInterfaceDescription createEndpointInterfaceDescription(Class sei); // Generate WSDL defintion from the endpoint interface description public static Defintion createWSDLDefinition(EndpointInterfaceDescription description); // Generate WSDL defintion from the service description public static Defintion createWSDLDefinition(ServiceDescription description); Any help will be greatly appreciated. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading in Tuscany
Hi, Rajini. Thank you for the detailed writeup. I copied your note into the following wiki page so we can capture the design points. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java I found it a bit difficult to reply in long e-mails so I decide to attack the problem from a slightly different angle. A) What's the purpose of classloading scheme? I think it's used to provide sharing and isolation of java classes. B) What are the players? 1. SCA/Tuscany APIs (and potentially other APIs such as SDO) 2. Tuscany runtime code 3. Tuscany extension code 4. 3rd party code that Tuscany runtime/extension depends on 5. Application code from SCA contributions 3) What's desired visibility? 5 -- imported java classes by the owning contribution -- 1 2 -- 1 -- 4 3 -- 2 (SPI portion) -- 1 -- 4 -- potentially other extensions I created a graph at http://cwiki.apache.org/confluence/download/attachments/68801/classloader-dependencies.png as the starting point. Once we have the relationship flushed out, we could then apply techniques such as OSGi or multi-parent classloaders, or a combination to enforce the loading scheme. Raymond - Original Message - From: Rajini Sivaram [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 15, 2007 12:52 AM Subject: Re: Classloading in Tuscany Mike, There are two sets of classloading in Tuscany that we need to look at and these can be handled independently of each other. 1) Classloading architecture for SCA contributions 2) Classloading architecture for SCA runtime modules In both cases, there are two ways of improving modularity in Tuscany a) Use separate classloaders per module to provide isolation, using a classloader architecture similar to OSGi, but without actually running in an OSGi runtime. b) Use OSGi bundles to provide module isolation and versioning, where the versioning support would rely on an OSGi runtime. For both 1) and 2), we could support a) and/or b). Tuscany already supports 1b), and the proposed fixes will support 1a). Tuscany does not implement 2a) or 2b), and if done properly, the implementation would required code changes that are pervasive across Tuscany. So the question is - do we really want to run Tuscany modules as separate OSGi bundles (or isolate modules using separate classloaders)? IMHO, it is only worth the hassle, if Tuscany modules are properly versioned and dynamically replaceable - ie, run as bundles in an OSGi runtime (2b). The proposed fixes do not implement 2a) and provide a partial solution for 2b) based on OSGi manifest files to minimize code changes to Tuscany. 1) Classloading architecture for SCA contributions At the moment, OSGi bundle contributions can be used in Tuscany which provide modularity and versioning with the help of an OSGi runtime. Plain Jar contributions or folders use a single classloader at the moment and the proposed fixes will introduce contribution classloaders to isolate contributions. SCA contributions can specify dependencies in terms of import/export statements in the same way as OSGi bundles. If you consider Java contributions, SCA contribution dependencies are a subset of OSGi bundle dependencies, because SCA does not support versioning or any of the other attributes that can be associated with importing packages in OSGi. So SCA contribution classloading will be a simpler version of OSGi bundle classloading. The code for supporting SCA import/export is already in place in Tuscany- it just doesn't get used because the thread context classloader is currently used to resolve classes. 2) Classloading architecture for SCA runtime modules At the moment, Tuscany uses a single classloader for the runtime and its dependencies, and even though Tuscany runtime architecture uses extensible modules with reasonably well defined dependencies, module isolation is not achieved because of the use of a single classloader. Tuscany also has dependencies on many libraries which rely on the thread context classloader. Even though we are looking at running Tuscany in an OSGi runtime to support distributed-OSGi, at the moment we are still assuming that by default Tuscany would be run without an OSGi runtime. Hence the proposed fixes aim to minimize Tuscany changes required to implement 2b). Tuscany's use of thread context classloader will be removed wherever possible, but the requirement on thread context classloader will not be removed altogether since it is used by libraries that Tuscany depends on. There are two issues with modularizing Tuscany runtime using OSGi or OSGi-style classloading. Thread context classloaders and OSGi dont go very well together. And the extension module architecture used by Tuscany where a core module is extended through the use of extension modules ends up in a classloader hierarchy which is the reverse of what is required - the core bundle does not have visibility of the classes from
Re: DAS C++ Status
-DAS is now supporing all CRUD operations. -Optimistic Concurrency Control is now implemented on DAS -testcases are now being tested using postgres rdbms and not firebird anymore, once its odbc driver is more stable Adriano Crestani On 10/1/07, Adriano Crestani [EMAIL PROTECTED] wrote: Native DAS provides now a new build infrastructure using ant that is also being used by Native SCA and SDO. Adriano Crestani On 7/21/07, Adriano Crestani [EMAIL PROTECTED] wrote: DAS C++ has now its own exceptions, such as DASInvalidTypeNameException, DASInvalidPropertyNameException, DASNullPointerException, DASColumnNotFoundException, DASInvalidColumnNameException, DASInvalidRelationshipNameException, DASInvalidSQLTypeException and DASInvalidTableNameException. Adriano Crestani On 7/21/07, Adriano Crestani [EMAIL PROTECTED] wrote: DAS C++ is now non-case sensitive, once most dbms are non-case sensitive, DAS C++ will be so, at least for now. Maybe on future, there can be added an option on config file that set DAS as case sensitive. All type and property names are converted to lower case when the SDO graph is created. Regards, Adriano Crestani On 6/26/07, Luciano Resende [EMAIL PROTECTED] wrote: Hey, very good, once this is available under the wiki, you probably should also send an e-mail to the user list. On 6/25/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added DAS C++ GettingStarted.html document and the first DAS C++ sample under revision 550697. Adriano Crestani On 6/6/07, Adriano Crestani [EMAIL PROTECTED] wrote: DAS is no longer needing the config.xsd to read xml configuration files since revision 544749. Adriano Crestani On 5/30/07, Adriano Crestani [EMAIL PROTECTED] wrote: Since revision 542742, DAS C++ is only working with SDO on trunk, and not with SDO C++ M3. Adriano Crestani On 5/29/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added support to one to many relationship under revision 542742 Adriano Crestani On 5/28/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added support to set up the framework via config xml under revision 542124. Adriano Crestani On 5/22/07, haleh mahbod [EMAIL PROTECTED] wrote: Thank you for the explanation. On 5/21/07, Adriano Crestani [EMAIL PROTECTED] wrote: Yes, it's intergrated with Tuscany SDO C++. Next step is to implement a sample for it. I intend to add some info on wiki before the first release. Regards, Adriano Crestani On 5/21/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Adriano, Is this integrated with SDO C++? Is there a sample for it? Can more information be added to the home page and user guide[1]? [1] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=46512 Haleh On 5/20/07, Adriano Crestani [EMAIL PROTECTED] wrote: Actually is being developed the Tuscany DAS C++. So far, the framework can perform the following: - Convetion Over Configuration(COC): - DAS assumes that a column named xxx_id is a FK to the column named id on table xxx. - If no PK column is found on the ResultSet, it sets the column named id as PK, if exists. - The COCs defined above are, actually, case sensitive and, for example, a column named ID will not be set as PK - The das is using the ResultSet metadata(column name, column data type and column table) to generate the sdo graph and popule it. The DAS guarantees the table object uniqueness on graph basing on the table PK, so the first table retrieved by the ResultSet will be taken, and any other table containing the same PK ignored: - A table may contain a simple PK or a composite one. - If no PK is defined for the table, the DAS tries to find one using COC. - If the table has a composite PK and not all the columns that
Re: Daily Tuscany SCA build working again!
I have updated the nightly download links for SCA, SDO and DAS : http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html On 10/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Great news Sebastien. I have updated the notification to send e-mail to dev-list when the build ends in failure, error or warning. This was done for all three sub-projects (SCA, SDO and DAS) On 10/13/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: The daily Tuscany SCA build is working again. Today's build is available there: http://vmbuild1.apache.org/continuum/component/buildResult.action?projecGroupId=19buildId=13044projectId=277projectGroupId=19 I had to comment modules/implementation-bpel, samples/helloworld-bpel and itest/component-type out of the poms for now. I opened JIRAs http://issues.apache.org/jira/browse/TUSCANY-1846 and http://issues.apache.org/jira/browse/TUSCANY-1847 with priority=Blocker to report the issues with these 3 modules. Could people working on them please help investigate? Putting the build back together was a little painful as we had let it fail for a while, so now that it's working again could everybody please pay attention to daily build issues and help fix them when they happen? Would it be possible to reactivate build notifications to the tuscany-dev list? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1844) Add persisted RDB Catalog to Store sample using JDBC
[ https://issues.apache.org/jira/browse/TUSCANY-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Douglas Siqueira Leite updated TUSCANY-1844: Attachment: tuscany1844_douglas_2007_10_15.patch Add persisted RDB Catalog to Store sample using JDBC Key: TUSCANY-1844 URL: https://issues.apache.org/jira/browse/TUSCANY-1844 Project: Tuscany Issue Type: Improvement Components: Java SCA Samples Reporter: Douglas Siqueira Leite Assignee: Luciano Resende Attachments: derbydb_2007_10_12.zip, tuscany1844_douglas_2007_10_12.patch, tuscany1844_douglas_2007_10_15.patch -Add RDB Catalog using JDBC. -Add a property currency rate in CurrencyConverter. -- 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-1844) Add persisted RDB Catalog to Store sample using JDBC
[ https://issues.apache.org/jira/browse/TUSCANY-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Douglas Siqueira Leite updated TUSCANY-1844: Attachment: tuscany1844_douglas_2007_10_15.patch Add persisted RDB Catalog to Store sample using JDBC Key: TUSCANY-1844 URL: https://issues.apache.org/jira/browse/TUSCANY-1844 Project: Tuscany Issue Type: Improvement Components: Java SCA Samples Reporter: Douglas Siqueira Leite Assignee: Luciano Resende Attachments: derbydb_2007_10_12.zip, tuscany1844_douglas_2007_10_12.patch, tuscany1844_douglas_2007_10_15.patch, tuscany1844_douglas_2007_10_15.patch -Add RDB Catalog using JDBC. -Add a property currency rate in CurrencyConverter. -- 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-1844) Add persisted RDB Catalog to Store sample using JDBC
[ https://issues.apache.org/jira/browse/TUSCANY-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Douglas Siqueira Leite updated TUSCANY-1844: Attachment: (was: tuscany1844_douglas_2007_10_15.patch) Add persisted RDB Catalog to Store sample using JDBC Key: TUSCANY-1844 URL: https://issues.apache.org/jira/browse/TUSCANY-1844 Project: Tuscany Issue Type: Improvement Components: Java SCA Samples Reporter: Douglas Siqueira Leite Assignee: Luciano Resende Attachments: derbydb_2007_10_12.zip, tuscany1844_douglas_2007_10_12.patch, tuscany1844_douglas_2007_10_15.patch -Add RDB Catalog using JDBC. -Add a property currency rate in CurrencyConverter. -- 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]
