Re: SDO Java 1.1-incubating release candidate 2
Hi, I will remove sample-sdo module from the staging repo. Regards, Amita On Fri, Feb 29, 2008 at 12:44 PM, ant elder [EMAIL PROTECTED] wrote: This looks good to me, ready to call a vote i think. The only issue i noticed is that the sample-sdo module is in the maven staging repo and it doesn't include a DISCLAIMER file. The sample-sdo wasn't include in the maven repo for the SDO 1.0 release so maybe it could be deleted from the staging area, or else a DISCLAIMER file could just be manually added to the jar to avoid having to rebuild anything. ...ant On Wed, Feb 27, 2008 at 5:49 AM, Amita Vadhavkar [EMAIL PROTECTED] wrote: I've posted a RC2 of SDO Java 1.1-incubating at [1] Maven artifacts for the release candidate are available at [2] I cut a branch for this release at [3] The rat report is at - [4], [5] Please take a look at this release candidate. Also please feed back on the install, build and samples. [1] http://people.apache.org/~amita/tuscany/1.1-RC2http://people.apache.org/%7Eamita/tuscany/1.1-RC2 http://people.apache.org/%7Eamita/tuscany/1.1-RC2 [2] http://people.apache.org/~amita/tuscany/1.1-RC2/mavenhttp://people.apache.org/%7Eamita/tuscany/1.1-RC2/maven http://people.apache.org/%7Eamita/tuscany/1.1-RC2/maven [3] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-1.1-incubating/ [4] http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txthttp://people.apache.org/%7Eamita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt http://people.apache.org/%7Eamita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt [5] http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txthttp://people.apache.org/%7Eamita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txt http://people.apache.org/%7Eamita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txt Note: for the comments/review of RC1 please refer to http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02539.html Regards, Amita
SDO Java 1.1-incubating release candidate 2
I've posted a RC2 of SDO Java 1.1-incubating at [1] Maven artifacts for the release candidate are available at [2] I cut a branch for this release at [3] The rat report is at - [4], [5] Please take a look at this release candidate. Also please feed back on the install, build and samples. [1] http://people.apache.org/~amita/tuscany/1.1-RC2 [2] http://people.apache.org/~amita/tuscany/1.1-RC2/maven [3] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-1.1-incubating/ [4] http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2.txt [5] http://people.apache.org/~amita/tuscany/1.1-RC2/rat-SDO-1.1-incubating-RC2-Exceptions.txt Note: for the comments/review of RC1 please refer to http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02539.html Regards, Amita
Re: [DAS] Running tomcat samples
The problem is version of derby jar in the samples/testing/tomcat/build.xml - it is asking for 10.1.2.1 Whereas the derby jar asked for in the rdb/pom.xml is 10.2.20. So when the user attempts to run the sample the required version is not found and no derby jar is deployed in tomcat lib and so no databases (required by samples) are created and all tests fail. Solution:- 1) Quick - change above mentioned build.xml to use derby jar 10.2.2.0 2) Even better - some way parameterize the derby jar version to be used throughout RDB DAS and use the same param to be consistent with the version. or see if the wild cards are accepted like 10.*.*.* Regards, Amita On Mon, Feb 25, 2008 at 5:48 PM, kelvin goodson [EMAIL PROTECTED] wrote: In following the instructions for running the tomcat samples from the DAS beta2 source distro [1] I hit a problem with finding derby drivers that causes the test run to fail as appended below. The relevant contents of the log are shown below that. Can someone tell me what I'm doing wrong please? Kelvin. 1] tuscany-das-1.0-incubating-beta2-src/samples/testing/tomcat/readme.htm = BUILD FAILURE === --- T E S T S --- Running org.apache.tuscany.test.das.DasTestCase log4j:WARN No appenders could be found for logger ( com.gargoylesoftware.htmlunit.WebClient). log4j:WARN Please initialize the log4j system properly. Running:HomePage Running:AllCompaniesRunning:AllCompaniesDepartments Running:AddDepartmentToFirstCompany Running:ChangeCompanyDepartmentNames Running:DeleteCompanyOneDepartments Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 5.638 sec FAILURE! testHomepage(org.apache.tuscany.test.das.DasTestCase) Time elapsed: 4.597sec ERROR! com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 500 Internal Server Error for http://localhost:8080/sample -company-webapp/ http://localhost:8080/sample-company-webapp/ at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :338) at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :389) at org.apache.tuscany.test.das.DasTestCase.testHomepage( DasTestCase.java:50) testAllCompanies(org.apache.tuscany.test.das.DasTestCase) Time elapsed: 0.13 sec ERROR! com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 500 Internal Server Error for http://localhost:8080/sample -company-webapp/ http://localhost:8080/sample-company-webapp/ at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :338) at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :389) at org.apache.tuscany.test.das.DasTestCase.testAllCompanies( DasTestCase.java:87) testAllCompaniesDepartments(org.apache.tuscany.test.das.DasTestCase) Time elapsed: 0.18 sec ERROR! com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 500 Internal Server Error for http://localhost:8080/sample -company-webapp/ http://localhost:8080/sample-company-webapp/ at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :338) at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :389) at org.apache.tuscany.test.das.DasTestCase.testAllCompaniesDepartments( DasTestCase.java:118) testAddDepartmentToFirstCompany(org.apache.tuscany.test.das.DasTestCase) Time elapsed: 0.181 sec ERROR! com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 500 Internal Server Error for http://localhost:8080/sample -company-webapp/ http://localhost:8080/sample-company-webapp/ at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :338) at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :389) at org.apache.tuscany.test.das.DasTestCase.testAddDepartmentToFirstCompany( DasTestCase.java:159) testChangeCompanyDepartmentNames(org.apache.tuscany.test.das.DasTestCase) Time elapsed: 0.12 sec ERROR! com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 500 Internal Server Error for http://localhost:8080/sample -company-webapp/ http://localhost:8080/sample-company-webapp/ at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :338) at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :389) at org.apache.tuscany.test.das.DasTestCase.testChangeCompanyDepartmentNames( DasTestCase.java:182) testDeleteCompanyOneDepartments(org.apache.tuscany.test.das.DasTestCase) Time elapsed: 0.33 sec ERROR! com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 500 Internal Server Error for http://localhost:8080/sample -company-webapp/ http://localhost:8080/sample-company-webapp/ at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java :338) at
Re: SDO Java 1.1-incubating release candidate 1
Below are the things pending before I can form RC2, please see if anybody have any inputs. All others comments are acted on. Pending: 1) The src distro includes the impl/.felix folder - is that really required or could it be excluded? 2) The sdo-api pom.xml is using the 0.8.0-SNAPSHOT version of the felix maven-osgi-plugin, could that use a non-snapshot release? 3) Mention of backport util source location in bin/Notice file - confirmation Regards, Amita On Fri, Feb 22, 2008 at 10:18 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 22/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks for all the review comments - working on those. I am just checking a few things below where I am not clear - NOTICE file -- TO CHECK = where is backport developed Assuming http://backport-jsr166.sourceforge.net/, please confirm I'm 95% sure you are right, but opening up the jar to look for info on origin doesn't prove fruitful. I also downloaded the javadoc from http://repo1.maven.org/maven2/backport-util-concurrent/backport-util-concurrent/3.1/to see if that helped, but no. Potential ISSUE - I'm not sure if the samples should now have the felix librairs and backport libray listed as dependencies in the samples javadoc -?Are the samples using these? or it is because the libs used by the samples use these libs? If this is required, it will go in the same place in index.html where we are listing all the other dependencies, right? I wrote this in the context of a failing runsamples script, but having got it working it's clear that the samples are not dependent on having these new libraries on the classpath. So I don't believe any changes is needed to the javadoc for this. Am still not able to remove the target dir appearing in the sample project of bin distribution. Trying... good luck, I can't help right now, but might get some time later if you haven't already solved it Regards, Amita On Thu, Feb 21, 2008 at 8:44 PM, kelvin goodson [EMAIL PROTECTED] wrote: the problems with the runsamples.bat file are that 1) it is missing the tuscany prefix from the sdo api jar and 2) the woodstox library is at 3.2.0rather than 3.2.1 Also I can see that the runsamples.sh file is at the 1.0-incubatinglevel and has the woodstox version issue. Kelvin. On 21/02/2008, kelvin goodson [EMAIL PROTECTED] wrote: Amita, thanks for this, here are some comments Binary zip file on Windows == MD5 is fine I couldn't find your public pgp signing key -- it needs adding to the KEYS file at http://svn.apache.org/viewvc/incubator/tuscany/KEYS and registering on a key server (you may have done that, I haven't spent a lot of time remembering how to search for it yet) LICENSE is correct for all 3rd party jars in the lib file and jar versions are correct NOTICE file -- TO CHECK = where is backport developed README seems fine Samples javadoc -- Potential ISSUE - I'm not sure if the samples should now have the felix librairs and backport libray listed as dependencies in the samples javadoc ISSUE running runsamples.bat in the samples dir results in ... SDO Sample Programs. Running with BINARY_BASE set to .. If this script fails with ClassDefNotFound errors you probably need to edit the BINARY_BASE variable in the script to point to the location where you unpacked the Tuscany SDO binary distribution Exception in thread main java.lang.NoClassDefFoundError: commonj/sdo/DataObject at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.tuscany.samples.sdo.internal.SampleInfrastructure.class$( SampleInfrastructure.java:58) at org.apache.tuscany.samples.sdo.internal.SampleInfrastructure .clinit(SampleInfrastructure.java:57) I guess the bat and sh scrips need the classpath changing to reflect the updated jar versions C:\Release\sdo- 1.1-inc\RC1\bin\apache-tuscany-sdo-1.1-incubating\tuscany-sdo-1.1-incubating\samples ISSUE - there is an extra target directory in the samples directory of the binary distribution Release notes ... ISSUE -- following is not so Apache Tuscany's SDO Java Release 1.1-incubating is the first such release with full coverage of the SDO 2.1 specification. In addition to adding the few remaining SDO 2.1 features not included in the 1.0-incubating release and fixing a number of bugs (see below for detail) there are a number of new features relating to XML serialization, and new support for handling dynamic derivation from static classes. and there's more in that file that is specific to the 1.0
Re: SDO Java 1.1-incubating release candidate 1
file in the sdo-impl and api jars are for 1.0-incubating, date July 2007 -- I guess this is the same for all Testing a build against the staging repo: Altering the repository url for apache.incubator in the top level pom of the source distro to http://people.apache.org/~amita/tuscany/1.1-RC1/mavenhttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/maven http://people.apache.org/%7Eamita/tuscany/1.1-RC1/maven and building the sample project in that distro, with no sdo artifacts in my local repo, successfully causes download of the SDO artifacts from your staging repo, and the sample project build is successful On 21/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: I've posted a RC1 of SDO Java 1.1-incubating at [1] Maven artifacts for the release candidate are available at [2] I cut a branch for this release at [3] The rat report is at - [4], [5] Please take a look at this release candidate. Also please feed back on the install, build and samples. Please give an early feedback, so as to help in quickly revising the required changes and forming RC2. [1] http://people.apache.org/~amita/tuscany/1.1-RC1http://people.apache.org/%7Eamita/tuscany/1.1-RC1 http://people.apache.org/%7Eamita/tuscany/1.1-RC1 http://people.apache.org/%7Eamita/tuscany/1.1-RC1 [2] http://people.apache.org/~amita/tuscany/1.1-RC1/mavenhttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/maven http://people.apache.org/%7Eamita/tuscany/1.1-RC1/maven http://people.apache.org/%7Eamita/tuscany/1.1-RC1/maven [3] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-1.1-incubating/ [4] http://people.apache.org/~amita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1.txthttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1.txt http://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1.txt http://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1.txt [5] http://people.apache.org/~amita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1-Exceptions.txthttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1-Exceptions.txt http://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1-Exceptions.txt http://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1-Exceptions.txt Note: please do reply (not reply all), so as to let the discussion happen in user ML. Best Regards, Amita
SDO Java 1.1-incubating release candidate 1
I've posted a RC1 of SDO Java 1.1-incubating at [1] Maven artifacts for the release candidate are available at [2] I cut a branch for this release at [3] The rat report is at - [4], [5] Please take a look at this release candidate. Also please feed back on the install, build and samples. Please give an early feedback, so as to help in quickly revising the required changes and forming RC2. [1] http://people.apache.org/~amita/tuscany/1.1-RC1http://people.apache.org/%7Eamita/tuscany/1.1-RC1 [2] http://people.apache.org/~amita/tuscany/1.1-RC1/mavenhttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/maven [3] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-1.1-incubating/ [4] http://people.apache.org/~amita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1.txthttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1.txt [5] http://people.apache.org/~amita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1-Exceptions.txthttp://people.apache.org/%7Eamita/tuscany/1.1-RC1/rat-SDO-1.1-incubating-RC1-Exceptions.txt Note: please do reply (not reply all), so as to let the discussion happen in user ML. Best Regards, Amita
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
please see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project for latest JIRA status and the final outcome of IRC discussions for SDO 1.1incubating release Also, appreciate a helping hand in Linux testing for the release. Regards, Amita On Tue, Feb 12, 2008 at 3:58 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita, re helper provider copyright. The header has been through two changes, one before i started on the project (see below), and one from Apache copyright to Apache license (me). I think the commit log comment below suggests we are right to leave it with the Apache license. Kelvin. commit 375756 jboynes 07/02/2006 22:37:37 version of HelperProvider that uses JAR service lookup to find the implementation changed copyright on HelperProvider.java as this is a new implementation On 12/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: In Rev. 620740 please find the changed license files and sdo-api/HelperProviderTestCase.java. The question remains is - what shall be the copyright (and thus license) for HelperProvider.java from sdo-api. It is there in the SDO_2.1.0_Java_source_FINAL.zip obtained from OSOA, but so far it was having ASF license. Need to understand the reason behind that and what is the correct action for this release. Regards, Amita On Feb 4, 2008 10:41 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, thanks for the summary, and for working so late to kick this chat off. As we also discussed in the chat I fear our numbers may have been diminished by a) the early time on the West Coast of the US and b) we could have perhaps started a top level thread on the ML to advertise it. So as we discussed, if you and I continue to do a pass on this during your working day tomorrow on IRC (say 9am approx GMT?), I will offer a follow up IRC chat late this week that's at a convenient time for the west coast to offer an opportunity for people to step up to the things we label nice to have -- and of course any other points of the plan we come up with. Kelvin. On 04/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: There was an IRC chat where me and Kelvin participated on Feb 4th, 7.30 a.m. PST for SDO Java 1.1-incubating release. Below is the summary. 1) license files under distribution and sdo-api need to be reviewed/corrected as well as copyright text fro sources/resources under sdo-api need to be reviewed/corrected based on latest from OSOA and based on when the source/resource files are changed. 2) SDO Java will follow the same strategy of providing LICENSE files under src\main\resources\META-INF as before 3) http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project is the place to find all unresolved JIRAs list marked for Java-SDO-next, there are a few documentation/website update JIRAs fixed from this list (1026, 1531), all others marked as unresolved are still at same status. 4) Went through the list one by one and covered first 6 JIRAs as below- must have 1293 - important, patch is available, need to review and apply the patch nice to have 1862-workaround available in 1842 and no user issues on it so far 1838-Amita will check the existing solution against the last comment in ASF JIRA comments next release 1725-the scope is big and better justice can be given in next release I will make the same update as above to the table in http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project and will have 2 additional columns in it - analysis, release scope(must/nice/next) which can be a handy reference for somebody trying to pitch in and work on this release for some JIRA. Appreciate all help in getting all important JIRAs in this release Regards, Amita On Feb 4, 2008 8:41 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 04/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Apologies for a lengthy mail,but trying not to keep any ambiguities. Please see all **Question: Findings for license text and copyright text - http://www.mail-archive.com/[EMAIL PROTECTED]/msg15317.html - http://www.mail-archive.com/[EMAIL PROTECTED]/msg16199.html - http://www.osoa.org/sdo/2.1/schemas/license.txt So looks like the license text for all except sdo-api will be as is in svn trunk like below - i.e. for sdo-impl, tools, sdo-lib, sdo-sample, sdo-plugin correct, it's just the java files that are provided as part of the specification that are at issue here **Question: why tools-test does not contain a license file? The rule is that any downloadable
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
In Rev. 620740 please find the changed license files and sdo-api/HelperProviderTestCase.java. The question remains is - what shall be the copyright (and thus license) for HelperProvider.java from sdo-api. It is there in the SDO_2.1.0_Java_source_FINAL.zip obtained from OSOA, but so far it was having ASF license. Need to understand the reason behind that and what is the correct action for this release. Regards, Amita On Feb 4, 2008 10:41 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, thanks for the summary, and for working so late to kick this chat off. As we also discussed in the chat I fear our numbers may have been diminished by a) the early time on the West Coast of the US and b) we could have perhaps started a top level thread on the ML to advertise it. So as we discussed, if you and I continue to do a pass on this during your working day tomorrow on IRC (say 9am approx GMT?), I will offer a follow up IRC chat late this week that's at a convenient time for the west coast to offer an opportunity for people to step up to the things we label nice to have -- and of course any other points of the plan we come up with. Kelvin. On 04/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: There was an IRC chat where me and Kelvin participated on Feb 4th, 7.30 a.m. PST for SDO Java 1.1-incubating release. Below is the summary. 1) license files under distribution and sdo-api need to be reviewed/corrected as well as copyright text fro sources/resources under sdo-api need to be reviewed/corrected based on latest from OSOA and based on when the source/resource files are changed. 2) SDO Java will follow the same strategy of providing LICENSE files under src\main\resources\META-INF as before 3) http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project is the place to find all unresolved JIRAs list marked for Java-SDO-next, there are a few documentation/website update JIRAs fixed from this list (1026, 1531), all others marked as unresolved are still at same status. 4) Went through the list one by one and covered first 6 JIRAs as below- must have 1293 - important, patch is available, need to review and apply the patch nice to have 1862-workaround available in 1842 and no user issues on it so far 1838-Amita will check the existing solution against the last comment in ASF JIRA comments next release 1725-the scope is big and better justice can be given in next release I will make the same update as above to the table in http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project and will have 2 additional columns in it - analysis, release scope(must/nice/next) which can be a handy reference for somebody trying to pitch in and work on this release for some JIRA. Appreciate all help in getting all important JIRAs in this release Regards, Amita On Feb 4, 2008 8:41 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 04/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Apologies for a lengthy mail,but trying not to keep any ambiguities. Please see all **Question: Findings for license text and copyright text - http://www.mail-archive.com/[EMAIL PROTECTED]/msg15317.html - http://www.mail-archive.com/[EMAIL PROTECTED]/msg16199.html - http://www.osoa.org/sdo/2.1/schemas/license.txt So looks like the license text for all except sdo-api will be as is in svn trunk like below - i.e. for sdo-impl, tools, sdo-lib, sdo-sample, sdo-plugin correct, it's just the java files that are provided as part of the specification that are at issue here **Question: why tools-test does not contain a license file? The rule is that any downloadable archive needs a license file. tools-test does not result in a maven artifact, so the only time a user will get anything to do with tool-test in an archive will be in the source distribution, which will be covered by the license file at the top of the source distro. **Question: tuscany sca Java provides DISCLAIMER, LICENSE, NOTICE directly under the module e.g. modules\binding-sca why tuscany SDO Java provides these files under module\src\main\resources\META-INF? I'm not sure of the SCA build structure, but we arrange for the license artifacts for the jars that are downloadable from maven to be in the archives meta-inf folder in this way. There are at least two options for doing this, and I'm not sure if we have a hybrid approach even within SDO, I seem to recall we might. If I recall correctly there is a maven plugin that does this sort of thing, but the example you give is an approach whereby the layout of the META-INF folder is specified by creating the hierarchy manually. I'm finding it a bit hard to work out where one point ends and the next begins here, so I hope
[SDO Java] Pluggable SDOPackageRegistryDelegator and Tuscany-1459
Please refer to https://issues.apache.org/jira/browse/TUSCANY-1831 and https://issues.apache.org/jira/browse/TUSCANY-1459 and share your thoughts about what can be done for Tuscany-1831 Regards, Amita
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Hi, When confirming for correctness of 3rd party license text, I checked the below thread - 1]http://www.mail-archive.com/[EMAIL PROTECTED]/msg05115.html and got in summary the below guidelines - Treatment of Third-Party Works 1. The term third-party work refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. 2. Do not modify or remove any copyright notices or licenses within third-party works. 3. Do ensure that every third-party work includes its associated license, even if that requires adding a copy of the license from the third-party download site into the distribution. 4. Do not add the standard Apache License header to the top of third-party source files. 5. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the rest of the third-party source for convenience. 6. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. But still have a few questions about 3rd party license headers in the context of below mail thread and findings - ML thread:- 2]http://www.mail-archive.com/[EMAIL PROTECTED]/msg03314.html Findings:- in tuscany-sdo-api-r2.1 1 HelperProvider and NoHelperProviderException have ASF license and in test in same project - 2HelperProviderTestCase has (looks like some old IBM+ASF license), DefaultHelperProvider, TCCL1HelperProvider have ASF licenses, These findings are a bit confusing against mail thread 2]. Also when checked Luciano's work on DAS in JIRA-620 for license headers it is all for ASF licenses as DAS does not contain any 3rd party code. So, will you please see if there are some changes required in 1 and 2? Regards, Amita On Jan 31, 2008 5:52 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I am going through all the samples to see if there are any areas of improvement, If anybody has spotted some areas or have some suggestions, please explain the details. Regards, Amita On Jan 30, 2008 3:35 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: How about having an IRC on 4th Feb ,Monday, 7.30 a.m. PST? Please feel free to suggest another time if this is not convenient. Regards, Amita On Jan 29, 2008 4:55 PM, kelvin goodson [EMAIL PROTECTED] wrote: I was hoping to have done a full pass through the JIRAs to be sure we cover the most important ones. Maybe it would be good to schedule an IRC chat to get community input on what is important. We could go through each of the open JIRAs and see how people rate the importance and who would step up to fixing things. That way we'd get a better picture of what's wanted. When would be a good time to do this? Kelvin. On 25/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: I have worked on the comments for RAT report and added the results at the end of - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report. So shall I go ahead and correct the 9 files mentioned there to include Apache header in them? Also, what is the best way to ensure that the Ex:3rd do contain the correct license text? Any old mail ref. or any other documentation? Regards, Amita On Jan 18, 2008 5:14 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, Anything unmarked needs checking to see if it fits one of these categories. I only did the ones I marked up from memory. Ex:IFF files must me ignored, but it must be clear from the rat report submitted in the release vote that thess files have been left as they are for this reason. You can see this kind of thing in Tuscany-1171, and in previous release vote threads, where the RAT report is manually marked up. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: What is the action for Ex.IFF - ignore? Also what TBD for the xml files under sdo-tools-test which do not contain headers - i.e. the last section from RAT Report - Unresolved. Regards, Amita On Jan 18, 2008 4:35 PM, kelvin goodson [EMAIL PROTECTED] wrote: I've marked up the Unresolved section. There's a job to do to be sure that each of the instances marked with Ex:TCR is actually such. We also need to work out what to do to take account of the clarification to the OSOA license that happened recently, that the files marked Ex:3rd may need to be changed to be in line with. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks Kelvin, will look at all these points. Also, I used rat-5.0.jar and got the report at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
And also src/distro and bin/distro license will be addition of the 2 license texts (Apache and OSOA) On Feb 4, 2008 7:40 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Apologies for a lengthy mail,but trying not to keep any ambiguities. Please see all **Question: Findings for license text and copyright text - http://www.mail-archive.com/[EMAIL PROTECTED]/msg15317.html - http://www.mail-archive.com/[EMAIL PROTECTED]/msg16199.html - http://www.osoa.org/sdo/2.1/schemas/license.txt So looks like the license text for all except sdo-api will be as is in svn trunk like below - i.e. for sdo-impl, tools, sdo-lib, sdo-sample, sdo-plugin **Question: why tools-test does not contain a license file? **Question: tuscany sca Java provides DISCLAIMER, LICENSE, NOTICE directly under the module e.g. modules\binding-sca why tuscany SDO Java provides these files under module\src\main\resources\META-INF? _ Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. License shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. Licensor shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. Legal Entity shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, control means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. You (or Your) shall mean an individual or Legal Entity exercising permissions granted by this License. Source form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. Object form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. Work shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). Derivative Works shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. Contribution shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, submitted means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as Not a Contribution. Contributor shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
There was an IRC chat where me and Kelvin participated on Feb 4th, 7.30 a.m. PST for SDO Java 1.1-incubating release. Below is the summary. 1) license files under distribution and sdo-api need to be reviewed/corrected as well as copyright text fro sources/resources under sdo-api need to be reviewed/corrected based on latest from OSOA and based on when the source/resource files are changed. 2) SDO Java will follow the same strategy of providing LICENSE files under src\main\resources\META-INF as before 3) http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project is the place to find all unresolved JIRAs list marked for Java-SDO-next, there are a few documentation/website update JIRAs fixed from this list (1026, 1531), all others marked as unresolved are still at same status. 4) Went through the list one by one and covered first 6 JIRAs as below- must have 1293 - important, patch is available, need to review and apply the patch nice to have 1862-workaround available in 1842 and no user issues on it so far 1838-Amita will check the existing solution against the last comment in ASF JIRA comments next release 1725-the scope is big and better justice can be given in next release I will make the same update as above to the table in http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project and will have 2 additional columns in it - analysis, release scope(must/nice/next) which can be a handy reference for somebody trying to pitch in and work on this release for some JIRA. Appreciate all help in getting all important JIRAs in this release Regards, Amita On Feb 4, 2008 8:41 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 04/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Apologies for a lengthy mail,but trying not to keep any ambiguities. Please see all **Question: Findings for license text and copyright text - http://www.mail-archive.com/[EMAIL PROTECTED]/msg15317.html - http://www.mail-archive.com/[EMAIL PROTECTED]/msg16199.html - http://www.osoa.org/sdo/2.1/schemas/license.txt So looks like the license text for all except sdo-api will be as is in svn trunk like below - i.e. for sdo-impl, tools, sdo-lib, sdo-sample, sdo-plugin correct, it's just the java files that are provided as part of the specification that are at issue here **Question: why tools-test does not contain a license file? The rule is that any downloadable archive needs a license file. tools-test does not result in a maven artifact, so the only time a user will get anything to do with tool-test in an archive will be in the source distribution, which will be covered by the license file at the top of the source distro. **Question: tuscany sca Java provides DISCLAIMER, LICENSE, NOTICE directly under the module e.g. modules\binding-sca why tuscany SDO Java provides these files under module\src\main\resources\META-INF? I'm not sure of the SCA build structure, but we arrange for the license artifacts for the jars that are downloadable from maven to be in the archives meta-inf folder in this way. There are at least two options for doing this, and I'm not sure if we have a hybrid approach even within SDO, I seem to recall we might. If I recall correctly there is a maven plugin that does this sort of thing, but the example you give is an approach whereby the layout of the META-INF folder is specified by creating the hierarchy manually. I'm finding it a bit hard to work out where one point ends and the next begins here, so I hope I am addressing your issues appropriately. _ Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. License shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. Licensor shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. Legal Entity shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, control means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. You (or Your) shall mean an individual or Legal Entity exercising permissions granted by this License. Source form shall mean the preferred form for making modifications, including but not limited
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG., Siemens AG., Software AG., Sun Microsystems, Sybase Inc., TIBCO Software Inc., Xcalia S.A., Zend Technologies Ltd, 2006, 2007. All rights reserved. __ Question: Still just curious to know the reason why in tuscany-sdo-api-r2.1so far, the files HelperProvider, NoHelperProviderException had ASF license and in test in same project -HelperProviderTestCase had (looks like some old IBM+ASF license), DefaultHelperProvider, TCCL1HelperProvider had ASF licenses. Was there any specific reason for that? --- All source and resource files other than the ones under sdo-api in the svn trunk have correct copyright text as below- _ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. _ regards, amita On Feb 4, 2008 5:33 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, apologies, on further detailed inspection I see that whilst the thread I directed you to was relevant, the resolution of the license text was documented at [1] Kelvin. [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg15317.html On 04/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, When confirming for correctness of 3rd party license text, I checked the below thread - 1]http://www.mail-archive.com/[EMAIL PROTECTED]/msg05115.html and got in summary the below guidelines - Treatment of Third-Party Works 1. The term third-party work refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. 2. Do not modify or remove any copyright notices or licenses within third-party works. 3. Do ensure that every third-party work includes its associated license, even if that requires adding a copy of the license from the third-party download site into the distribution. 4. Do not add the standard Apache License header to the top of third-party source files. 5. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the rest of the third-party source for convenience. 6. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. But still have a few questions about 3rd party license headers in the context of below mail thread and findings - ML thread:- 2]http://www.mail-archive.com/[EMAIL PROTECTED]/msg03314.html Findings:- in tuscany-sdo-api-r2.1 1 HelperProvider and NoHelperProviderException have ASF license and in test in same project - 2HelperProviderTestCase has (looks like some old IBM+ASF license), DefaultHelperProvider, TCCL1HelperProvider have ASF licenses, These findings are a bit confusing against mail thread 2]. Also when checked Luciano's work on DAS in JIRA-620 for license headers it is all for ASF licenses as DAS does not contain any 3rd party code. So, will you please see if there are some changes required in 1 and 2? Regards, Amita On Jan 31, 2008 5:52 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I am going through all the samples to see if there are any areas of improvement, If anybody has spotted some areas or have some suggestions, please explain the details. Regards, Amita On Jan 30, 2008 3:35 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: How about having an IRC on 4th Feb ,Monday, 7.30 a.m. PST? Please feel free to suggest another time if this is not convenient. Regards, Amita On Jan 29, 2008 4:55 PM, kelvin goodson [EMAIL PROTECTED] wrote: I was hoping to have done a full pass
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Hi, I am going through all the samples to see if there are any areas of improvement, If anybody has spotted some areas or have some suggestions, please explain the details. Regards, Amita On Jan 30, 2008 3:35 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: How about having an IRC on 4th Feb ,Monday, 7.30 a.m. PST? Please feel free to suggest another time if this is not convenient. Regards, Amita On Jan 29, 2008 4:55 PM, kelvin goodson [EMAIL PROTECTED] wrote: I was hoping to have done a full pass through the JIRAs to be sure we cover the most important ones. Maybe it would be good to schedule an IRC chat to get community input on what is important. We could go through each of the open JIRAs and see how people rate the importance and who would step up to fixing things. That way we'd get a better picture of what's wanted. When would be a good time to do this? Kelvin. On 25/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: I have worked on the comments for RAT report and added the results at the end of - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report. So shall I go ahead and correct the 9 files mentioned there to include Apache header in them? Also, what is the best way to ensure that the Ex:3rd do contain the correct license text? Any old mail ref. or any other documentation? Regards, Amita On Jan 18, 2008 5:14 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, Anything unmarked needs checking to see if it fits one of these categories. I only did the ones I marked up from memory. Ex:IFF files must me ignored, but it must be clear from the rat report submitted in the release vote that thess files have been left as they are for this reason. You can see this kind of thing in Tuscany-1171, and in previous release vote threads, where the RAT report is manually marked up. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: What is the action for Ex.IFF - ignore? Also what TBD for the xml files under sdo-tools-test which do not contain headers - i.e. the last section from RAT Report - Unresolved. Regards, Amita On Jan 18, 2008 4:35 PM, kelvin goodson [EMAIL PROTECTED] wrote: I've marked up the Unresolved section. There's a job to do to be sure that each of the instances marked with Ex:TCR is actually such. We also need to work out what to do to take account of the clarification to the OSOA license that happened recently, that the files marked Ex:3rd may need to be changed to be in line with. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks Kelvin, will look at all these points. Also, I used rat-5.0.jar and got the report at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report Please see Unresolved section in it and give comments about what is appropriate to fix there. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubatingand keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
How about having an IRC on 4th Feb ,Monday, 7.30 a.m. PST? Please feel free to suggest another time if this is not convenient. Regards, Amita On Jan 29, 2008 4:55 PM, kelvin goodson [EMAIL PROTECTED] wrote: I was hoping to have done a full pass through the JIRAs to be sure we cover the most important ones. Maybe it would be good to schedule an IRC chat to get community input on what is important. We could go through each of the open JIRAs and see how people rate the importance and who would step up to fixing things. That way we'd get a better picture of what's wanted. When would be a good time to do this? Kelvin. On 25/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: I have worked on the comments for RAT report and added the results at the end of - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report. So shall I go ahead and correct the 9 files mentioned there to include Apache header in them? Also, what is the best way to ensure that the Ex:3rd do contain the correct license text? Any old mail ref. or any other documentation? Regards, Amita On Jan 18, 2008 5:14 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, Anything unmarked needs checking to see if it fits one of these categories. I only did the ones I marked up from memory. Ex:IFF files must me ignored, but it must be clear from the rat report submitted in the release vote that thess files have been left as they are for this reason. You can see this kind of thing in Tuscany-1171, and in previous release vote threads, where the RAT report is manually marked up. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: What is the action for Ex.IFF - ignore? Also what TBD for the xml files under sdo-tools-test which do not contain headers - i.e. the last section from RAT Report - Unresolved. Regards, Amita On Jan 18, 2008 4:35 PM, kelvin goodson [EMAIL PROTECTED] wrote: I've marked up the Unresolved section. There's a job to do to be sure that each of the instances marked with Ex:TCR is actually such. We also need to work out what to do to take account of the clarification to the OSOA license that happened recently, that the files marked Ex:3rd may need to be changed to be in line with. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks Kelvin, will look at all these points. Also, I used rat-5.0.jar and got the report at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report Please see Unresolved section in it and give comments about what is appropriate to fix there. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubatingand keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128
[Java SDO] getEncoding() during load() - issues + TUSCANY-1545
I am making this a separate thread and referring it in
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02447.html
as this can be my local setup issue and so don't want to mix with the
release thread.
0] I checked that the EMF version in my classpath is 2.2.3.
1]Eclipse 3.2.1
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html
getEncoding
public java.lang.String getEncoding()
Get the XML encoding for this resource. The default is ASCII.
2]SDO Spec says default is UTF-8.
3]To adhere to SDO Spec, the rootmost place for change can be
XMLDocumentImpl class itself as this is
where SDO Impl implements commonj XMLDocument and contain EMF's XMLResource.
So if inside protected XMLDocumentImpl(ExtendedMetaData extendedMetaData,
Object options)
we do resource.setEncoding(UTF-8); after the Resource is obtained from
EMF's ResourceSet we are all set for save as well as load.
4]If we look at the current 1545 patch, it was doing setEncoding() in
XMLHelperImp.createDocument(). This gets called during save() but not during
load().
In this same class if we look at load(InputStream inputStream, String
locationURI, Object options) and load(Reader inputReader, String
locationURI, Object options)
, here we create *new instances* of XMLDocumentImpl which do not have UTF-8
set as from EMF's viewpoint, the default is ASCII. So, during load operation
the getEncoding() resulted in ASCII even if the document is saved using
'UTF-8'.
5]But still 3] as well as 1545.patch is not correct , for 2 reasons -
1 what will be the way for end user to use *any other encoding* other
than UTF-8 during save and get the same encoding back during load?
2 Also a logical assumption - when we save a resource with a particular
encoding, load should return the resource with same encoding - how to make
this
happen? Because 4]*new instance* of XMLDocument will always default to
ASCII(1]).
For 1, one way can be - user can pass XMLResource.OPTION_ENCODING during
save and
inside SDO Impl, we need to make sure this option is passed to EMF. And when
such option is passed in during save() it should be honored and
default UTF-8 should not be used.
Ref:
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/XMLResource.html
OPTION_ENCODING
public static final java.lang.String OPTION_ENCODING
Specify the XML encoding to be used *during save*.
But for 2 i.e. get the same encoding back during load without any special
option passing and without setEncoding() - what is the solution?
Also found below - so the correct behavior should be available in EMF
2.2.3and further.
http://www.eclipse.org/modeling/emf/news/relnotes.php?project=emfversion=2.2.x
* 2.2.2
* 2.2.2RC2 (2 bugs fixed)
o 173815 Bad link exist on EMF/SDO/XSD Developer Guide
o 173681 encoding is ignored during XMLResource#load
*
surefire-reports
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.172 sec
FAILURE!
testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase) Time elapsed:
3.125 sec FAILURE!
junit.framework.AssertionFailedError: Encoding ('ASCII' is not correct.
UTF-8 is the expected encoding.
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding (
XMLHelperTestCase.java:313)
at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding(
XMLHelperTestCase.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest (TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run( TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(
JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet (
AbstractDirectoryTestSuite.java:138)
at
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
I have spawned another thread http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02449.html for the testEncoding() issue I am facing. Will you please take a look at findings there and comment there? I will update the final resolution for it here when we get one. Regards, Amita On Jan 24, 2008 4:29 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Yes, its maven build that is giving this failure, am checking more on it. Regards, Amita On Jan 24, 2008 4:25 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hmmm, I also just wiped (moved aside) my whole repo, and got a clean build again. I can't think what the issue could be. I was thinking it might be something to do with running the tests in Eclipse, but I am assuming you are not doing that because of the discussions we have had about wiping the maven repo; so just to be clear, can I check that it is the maven build that is giving you these errors, yes? Kelvin On 24/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Kelvin, What I did was - renamed C:\Documents and Settings\Administrator\.m2\repository - C:\Documents and Settings\Administrator\.m2\repository_bkp so that I don't have any maven repo and did a fresh svn checkout of SDO Java and tried to build - with this I get testEncoding() failure. Am also seeing below in tools-tests - Failed tests: testSimpleTypeExtension( org.apache.tuscany.sdo.test.SubstitutionWithExtensionV aluesTestCase) Tests in error: testComplexTypeWithSimpleContentExtensionMetaData( org.apache.tuscany.sdo.test. SubstitutionWithExtensionValuesTestCase) testComplexTypeWithSimpleContentExtensionChangeSummary( org.apache.tuscany.sdo. test.SubstitutionWithExtensionValuesTestCase ) testChangeSummaryOnDataGraphWithIntAndFloat( org.apache.tuscany.sdo.test.Change SummaryGenTestCase) Tests run: 23, Failures: 1, Errors: 3, Skipped: 0 Also, is there any known reason why suite.addTestSuite(DataObjectGetListTestCase.class); suite.addTestSuite(ListWithDefaultTestCase.class); suite.addTestSuite( SubstitutionWithExtensionValuesTestCase.class); the above ones are not in AllTests in tools-test? I am investigating more. Regards, Amita On Jan 24, 2008 4:01 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita, do you still see this? I wiped all eclipse artifacts from my local repo and did a clean build. All ran fine. If you are still seeing it, perhaps you can give some more detail on the errors. Maybe you could paste some relevant error report sections from the files in target/surefire-reports Kelvin. On 21/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: After building a fresh checkout and using initially empty maven repo, all except testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase) failed. Is this a known issue? This is due to encoding mismatch between the one coming from org.eclipse.emf.ecore.xmi.XMLResource is ASCII and the expected one is UTF-8 Regards, Amita On Jan 21, 2008 4:45 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita So I guess I can open a JIRA and fix variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above and it will do the trick. Does this sound OK? sounds good, thanks Kelvin.
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Due to the testEncoding() failure I mentioned on a previous response, the sdo-impl jar was not getting created and so the further failures in tools-test, after proper generation of sdo-impl jar these issues got solved. Also I have made AllTests to include all the existing tests from tools-test. Regards, Amita On Jan 24, 2008 4:14 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Kelvin, What I did was - renamed C:\Documents and Settings\Administrator\.m2\repository - C:\Documents and Settings\Administrator\.m2\repository_bkp so that I don't have any maven repo and did a fresh svn checkout of SDO Java and tried to build - with this I get testEncoding() failure. Am also seeing below in tools-tests - Failed tests: testSimpleTypeExtension( org.apache.tuscany.sdo.test.SubstitutionWithExtensionV aluesTestCase) Tests in error: testComplexTypeWithSimpleContentExtensionMetaData( org.apache.tuscany.sdo.test. SubstitutionWithExtensionValuesTestCase) testComplexTypeWithSimpleContentExtensionChangeSummary( org.apache.tuscany.sdo. test.SubstitutionWithExtensionValuesTestCase) testChangeSummaryOnDataGraphWithIntAndFloat( org.apache.tuscany.sdo.test.Change SummaryGenTestCase) Tests run: 23, Failures: 1, Errors: 3, Skipped: 0 Also, is there any known reason why suite.addTestSuite(DataObjectGetListTestCase.class ); suite.addTestSuite(ListWithDefaultTestCase.class); suite.addTestSuite(SubstitutionWithExtensionValuesTestCase.class); the above ones are not in AllTests in tools-test? I am investigating more. Regards, Amita On Jan 24, 2008 4:01 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita, do you still see this? I wiped all eclipse artifacts from my local repo and did a clean build. All ran fine. If you are still seeing it, perhaps you can give some more detail on the errors. Maybe you could paste some relevant error report sections from the files in target/surefire-reports Kelvin. On 21/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: After building a fresh checkout and using initially empty maven repo, all except testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase) failed. Is this a known issue? This is due to encoding mismatch between the one coming from org.eclipse.emf.ecore.xmi.XMLResource is ASCII and the expected one is UTF-8 Regards, Amita On Jan 21, 2008 4:45 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita So I guess I can open a JIRA and fix variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above and it will do the trick. Does this sound OK? sounds good, thanks Kelvin.
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
I have worked on the comments for RAT report and added the results at the end of - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report. So shall I go ahead and correct the 9 files mentioned there to include Apache header in them? Also, what is the best way to ensure that the Ex:3rd do contain the correct license text? Any old mail ref. or any other documentation? Regards, Amita On Jan 18, 2008 5:14 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, Anything unmarked needs checking to see if it fits one of these categories. I only did the ones I marked up from memory. Ex:IFF files must me ignored, but it must be clear from the rat report submitted in the release vote that thess files have been left as they are for this reason. You can see this kind of thing in Tuscany-1171, and in previous release vote threads, where the RAT report is manually marked up. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: What is the action for Ex.IFF - ignore? Also what TBD for the xml files under sdo-tools-test which do not contain headers - i.e. the last section from RAT Report - Unresolved. Regards, Amita On Jan 18, 2008 4:35 PM, kelvin goodson [EMAIL PROTECTED] wrote: I've marked up the Unresolved section. There's a job to do to be sure that each of the instances marked with Ex:TCR is actually such. We also need to work out what to do to take account of the clarification to the OSOA license that happened recently, that the files marked Ex:3rd may need to be changed to be in line with. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks Kelvin, will look at all these points. Also, I used rat-5.0.jar and got the report at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report Please see Unresolved section in it and give comments about what is appropriate to fix there. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubatingand keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128 - Support attribute and element with same name TUSCANY-1359 - New SDOUtil: Upper and lower bound on properties where 'isMany' is true CTS TUSCANY-1230 - Improvements to TypeConversionTest Something I meant to mention in regards to your other posting is that the CTS is not part of an SDO Java release. We haven't ever released the CTS, since it's never yet seemed to make sense to do so. SDO implementers who want to use the CTS can download the source. I think what we want to do here is a respin of the kind of release we have done before, for the SDO Java runtime. Is there anything else from http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project that can be added to it? Also do the above mentioned JIRAs useful as part of FAQ, or mention in Release Notes will be sufficient? I see now. Yes, release notes
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Hi Kelvin, What I did was - renamed C:\Documents and Settings\Administrator\.m2\repository - C:\Documents and Settings\Administrator\.m2\repository_bkp so that I don't have any maven repo and did a fresh svn checkout of SDO Java and tried to build - with this I get testEncoding() failure. Am also seeing below in tools-tests - Failed tests: testSimpleTypeExtension( org.apache.tuscany.sdo.test.SubstitutionWithExtensionV aluesTestCase) Tests in error: testComplexTypeWithSimpleContentExtensionMetaData( org.apache.tuscany.sdo.test. SubstitutionWithExtensionValuesTestCase) testComplexTypeWithSimpleContentExtensionChangeSummary( org.apache.tuscany.sdo. test.SubstitutionWithExtensionValuesTestCase) testChangeSummaryOnDataGraphWithIntAndFloat( org.apache.tuscany.sdo.test.Change SummaryGenTestCase) Tests run: 23, Failures: 1, Errors: 3, Skipped: 0 Also, is there any known reason why suite.addTestSuite(DataObjectGetListTestCase.class); suite.addTestSuite(ListWithDefaultTestCase.class); suite.addTestSuite(SubstitutionWithExtensionValuesTestCase.class); the above ones are not in AllTests in tools-test? I am investigating more. Regards, Amita On Jan 24, 2008 4:01 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita, do you still see this? I wiped all eclipse artifacts from my local repo and did a clean build. All ran fine. If you are still seeing it, perhaps you can give some more detail on the errors. Maybe you could paste some relevant error report sections from the files in target/surefire-reports Kelvin. On 21/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: After building a fresh checkout and using initially empty maven repo, all except testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase) failed. Is this a known issue? This is due to encoding mismatch between the one coming from org.eclipse.emf.ecore.xmi.XMLResource is ASCII and the expected one is UTF-8 Regards, Amita On Jan 21, 2008 4:45 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita So I guess I can open a JIRA and fix variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above and it will do the trick. Does this sound OK? sounds good, thanks Kelvin.
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Thanks a lot Kelvin. With this , I have added the .pngs to the page and also refreshed dev guide with more information. We may be able to close TUSCANY-1531 after reviewing the changes. Regards, Amita On Jan 22, 2008 5:15 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita, I think the answer for finding some of these old resources is probably from the tuscany commits mailing list archive. E.g. I noticed that do_uml.png was deleted in commit http://svn.apache.org/viewvc?view=revrevision=543562 So could be retrieved by for example using tortoise svn repository explorer with a repository index of 543561. This is relevant for the time when the master data for the website was a set of files in svn. Since we moved over to using the confluence wiki as the master data for the website the tuscany commits mailing list archive contains the changes made to the website, so again we can at least track back changes using that archive as an audit trail. We may then be able to retrieve things using the confluence page history, but I'm not sure on that. As the sca dev guide doesn't use includes I think we're going to have to do some cut and paste work. I think 1026 is out of date. The last commit to java_sdo_overview.xml was http://svn.apache.org/viewvc/incubator/tuscany/site/site-author/java_sdo_overview.xml?view=logpathrev=537953 , and the page indicates the file doesnt exisst after r*evision 543536.* The work you are doing supercedes this. I close it. Kelvin. On 21/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Some more questions about website content changes - Please refer to 1)..9) from http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02417.html *Q*1) Could not find any other page with SDO Java specific get involved *Q*4) sdo-project-code-structure.html - menu and new project structure added Question: Any clue where to find the the below png files , being referenced in this page? do_uml.png meta.png meta2.png *Q*6) SCA Java Development Guide - SDO Java Development Guide SCA Dev Guide has not used include directive, so not able to re-use the content, any better way other than duplicating the content here *Q*8) What is required for JIRA-1026? - is this JIRA based on some old documentation? Regards, Amita On Jan 21, 2008 6:17 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: After building a fresh checkout and using initially empty maven repo, all except testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase) failed. Is this a known issue? This is due to encoding mismatch between the one coming from org.eclipse.emf.ecore.xmi.XMLResource is ASCII and the expected one is UTF-8 Regards, Amita On Jan 21, 2008 4:45 PM, kelvin goodson [EMAIL PROTECTED] wrote: Amita So I guess I can open a JIRA and fix variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above and it will do the trick. Does this sound OK? sounds good, thanks Kelvin.
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Thanks Kelvin, will look at all these points. Also, I used rat-5.0.jar and got the report at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report Please see Unresolved section in it and give comments about what is appropriate to fix there. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubating and keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128 - Support attribute and element with same name TUSCANY-1359 - New SDOUtil: Upper and lower bound on properties where 'isMany' is true CTS TUSCANY-1230 - Improvements to TypeConversionTest Something I meant to mention in regards to your other posting is that the CTS is not part of an SDO Java release. We haven't ever released the CTS, since it's never yet seemed to make sense to do so. SDO implementers who want to use the CTS can download the source. I think what we want to do here is a respin of the kind of release we have done before, for the SDO Java runtime. Is there anything else from http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project that can be added to it? Also do the above mentioned JIRAs useful as part of FAQ, or mention in Release Notes will be sufficient? I see now. Yes, release notes are definitely the place for this. 3) http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html page does not have menu Good point 4) http://incubator.apache.org/tuscany/sdo-project-code-structure.html no menu , old structure you are right, we need to add a section for the lib project and the tools-test project 5) http://incubator.apache.org/tuscany/getting-source.html no menu and old structure again, yes, this doesn't reflect the move of the api project into the main sdo trunk 6) developer guide - should we refer to http://incubator.apache.org/tuscany/sca-java-development-guide.html and make SDO Dev Guide more complete? I think ideally we would incorporate some of the new content from the sca guide into an sdo guide. If the SCA guide is built up by wiki include directives, there may be scope for including generic chunks into out own guide. 7) http://incubator.apache.org/tuscany/sdo-java-user-guide.html again no menu can refer to http://incubator.apache.org/tuscany/sca-java-user-guide.html 8) TUSCANY-1026 Also, why https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html opens the html page without browser rendering it as html? (like shows all html tags etc.) I think this is a firefox issue. It's fine in IE. Not sure why it's wrong in firefox though. Can we provide this link in http://incubator.apache.org/tuscany/sdo-java-user-guide.html This looks like a useful rework of some of the content that I think is already in the site. It certainly was at one time. 9) TUSCANY-1531 From this - comment #1 - Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http://incubator.apache.org/tuscany/sdo-java-documentation-menu.html as it's one of the pages with more contents on it. looks like is fixed. great And with 7) we can fix comment #2 - User guide has wrong styles : http
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Sorry, please see point 1 ) i.e. old page for sdo get involved and not 2). On Jan 18, 2008 5:27 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, Regarding website updates, will you please help in 2) where there is a chance that there will be pre-existing page - I gave it an attempt but could not locate. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubating and keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html . I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128 - Support attribute and element with same name TUSCANY-1359 - New SDOUtil: Upper and lower bound on properties where 'isMany' is true CTS TUSCANY-1230 - Improvements to TypeConversionTest Something I meant to mention in regards to your other posting is that the CTS is not part of an SDO Java release. We haven't ever released the CTS, since it's never yet seemed to make sense to do so. SDO implementers who want to use the CTS can download the source. I think what we want to do here is a respin of the kind of release we have done before, for the SDO Java runtime. Is there anything else from http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project that can be added to it? Also do the above mentioned JIRAs useful as part of FAQ, or mention in Release Notes will be sufficient? I see now. Yes, release notes are definitely the place for this. 3) http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html page does not have menu Good point 4) http://incubator.apache.org/tuscany/sdo-project-code-structure.htmlno menu , old structure you are right, we need to add a section for the lib project and the tools-test project 5) http://incubator.apache.org/tuscany/getting-source.html no menu and old structure again, yes, this doesn't reflect the move of the api project into the main sdo trunk 6) developer guide - should we refer to http://incubator.apache.org/tuscany/sca-java-development-guide.htmland make SDO Dev Guide more complete? I think ideally we would incorporate some of the new content from the sca guide into an sdo guide. If the SCA guide is built up by wiki include directives, there may be scope for including generic chunks into out own guide. 7) http://incubator.apache.org/tuscany/sdo-java-user-guide.html again no menu can refer to http://incubator.apache.org/tuscany/sca-java-user-guide.html 8) TUSCANY-1026 Also, why https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html opens the html page without browser rendering it as html? (like shows all html tags etc.) I think this is a firefox issue. It's fine in IE. Not sure why it's wrong in firefox though. Can we provide this link in http://incubator.apache.org/tuscany/sdo-java-user-guide.html This looks like a useful rework of some of the content that I think is already in the site. It certainly was at one time. 9) TUSCANY-1531 From this - comment #1 - Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
What is the action for Ex.IFF - ignore? Also what TBD for the xml files under sdo-tools-test which do not contain headers - i.e. the last section from RAT Report - Unresolved. Regards, Amita On Jan 18, 2008 4:35 PM, kelvin goodson [EMAIL PROTECTED] wrote: I've marked up the Unresolved section. There's a job to do to be sure that each of the instances marked with Ex:TCR is actually such. We also need to work out what to do to take account of the clarification to the OSOA license that happened recently, that the files marked Ex:3rd may need to be changed to be in line with. Kelvin. On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks Kelvin, will look at all these points. Also, I used rat-5.0.jar and got the report at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/RAT+Report Please see Unresolved section in it and give comments about what is appropriate to fix there. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubating and keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128 - Support attribute and element with same name TUSCANY-1359 - New SDOUtil: Upper and lower bound on properties where 'isMany' is true CTS TUSCANY-1230 - Improvements to TypeConversionTest Something I meant to mention in regards to your other posting is that the CTS is not part of an SDO Java release. We haven't ever released the CTS, since it's never yet seemed to make sense to do so. SDO implementers who want to use the CTS can download the source. I think what we want to do here is a respin of the kind of release we have done before, for the SDO Java runtime. Is there anything else from http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project that can be added to it? Also do the above mentioned JIRAs useful as part of FAQ, or mention in Release Notes will be sufficient? I see now. Yes, release notes are definitely the place for this. 3) http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html page does not have menu Good point 4) http://incubator.apache.org/tuscany/sdo-project-code-structure.htmlno menu , old structure you are right, we need to add a section for the lib project and the tools-test project 5) http://incubator.apache.org/tuscany/getting-source.html no menu and old structure again, yes, this doesn't reflect the move of the api project into the main sdo trunk 6) developer guide - should we refer to http://incubator.apache.org/tuscany/sca-java-development-guide.htmland make SDO Dev Guide more complete? I think ideally we would incorporate some of the new content from the sca guide into an sdo guide. If the SCA guide is built up by wiki include directives, there may be scope for including generic chunks into out own guide. 7) http://incubator.apache.org/tuscany/sdo-java-user-guide.html again no menu can refer to http://incubator.apache.org/tuscany/sca-java-user-guide.html 8) TUSCANY-1026 Also, why https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubating and keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128 - Support attribute and element with same name TUSCANY-1359 - New SDOUtil: Upper and lower bound on properties where 'isMany' is true CTS TUSCANY-1230 - Improvements to TypeConversionTest Something I meant to mention in regards to your other posting is that the CTS is not part of an SDO Java release. We haven't ever released the CTS, since it's never yet seemed to make sense to do so. SDO implementers who want to use the CTS can download the source. I think what we want to do here is a respin of the kind of release we have done before, for the SDO Java runtime. Is there anything else from http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project that can be added to it? Also do the above mentioned JIRAs useful as part of FAQ, or mention in Release Notes will be sufficient? I see now. Yes, release notes are definitely the place for this. 3) http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html page does not have menu Good point 4) http://incubator.apache.org/tuscany/sdo-project-code-structure.html no menu , old structure you are right, we need to add a section for the lib project and the tools-test project 5) http://incubator.apache.org/tuscany/getting-source.html no menu and old structure again, yes, this doesn't reflect the move of the api project into the main sdo trunk 6) developer guide - should we refer to http://incubator.apache.org/tuscany/sca-java-development-guide.html and make SDO Dev Guide more complete? I think ideally we would incorporate some of the new content from the sca guide into an sdo guide. If the SCA guide is built up by wiki include directives, there may be scope for including generic chunks into out own guide. 7) http://incubator.apache.org/tuscany/sdo-java-user-guide.html again no menu can refer to http://incubator.apache.org/tuscany/sca-java-user-guide.html 8) TUSCANY-1026 Also, why https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html opens the html page without browser rendering it as html? (like shows all html tags etc.) I think this is a firefox issue. It's fine in IE. Not sure why it's wrong in firefox though. When I manually added below line to the https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html it worked fine on firefox. !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; So I guess I can open a JIRA and fix variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above and it will do the trick. Does this sound OK? Can we provide this link in http://incubator.apache.org/tuscany/sdo-java-user-guide.html This looks like a useful rework of some of the content that I think is already in the site. It certainly was at one time. 9) TUSCANY-1531 From this - comment #1 - Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http://incubator.apache.org/tuscany/sdo-java-documentation
Re: [Java SDO] Tuscany SDO Java 1.1-incubating
Hi, Regarding website updates, will you please help in 2) where there is a chance that there will be pre-existing page - I gave it an attempt but could not locate. Regards, Amita On Jan 18, 2008 3:56 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 18/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Assuming name of the release as Tuscany SDO Java 1.1-incubating and keeping ref. to the old mail thread - http://www.mail-archive.com/[EMAIL PROTECTED]/msg27168.html. I am starting a new thread now. Web Site documentation:- I could gather a few places where small updates can be done. Please give your comments if these seem fine or need something more/something else. 1) why on http://incubator.apache.org/tuscany/sdo-java-get-involved.htmlwe have - Open CSA (SCA Standards) This is confusing and needs investigating. I think you are talking about the transition from ... http://incubator.apache.org/tuscany/sdo-java.html to http://incubator.apache.org/tuscany/sdo-java-get-involved.html In which case the Get Involved is a link from the general menu and therefore is general to Tuscany. However, the page is entitled SDO Java Get Involved, yet seems identical to the Get Involved page from the Tuscany Home page's Community menu apart from the fact that this page is entitled Getting Involved: Apache Tuscany. I'm sure we used to have our own SDO Java getting involved page, and I think it has accidentally been overwritten at some stage. I guess we need to look at the wiki change history and see if we can recover it. 2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor new features, improvements I'm a bit confused here. I think maybe you have two separate ideas that have been merged perhaps. I don't think we want to detail new features on the FAQ page. TUSCANY-1468 - Use HelperContext for scope in Tuscany API TUSCANY-1128 - Support attribute and element with same name TUSCANY-1359 - New SDOUtil: Upper and lower bound on properties where 'isMany' is true CTS TUSCANY-1230 - Improvements to TypeConversionTest Something I meant to mention in regards to your other posting is that the CTS is not part of an SDO Java release. We haven't ever released the CTS, since it's never yet seemed to make sense to do so. SDO implementers who want to use the CTS can download the source. I think what we want to do here is a respin of the kind of release we have done before, for the SDO Java runtime. Is there anything else from http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project that can be added to it? Also do the above mentioned JIRAs useful as part of FAQ, or mention in Release Notes will be sufficient? I see now. Yes, release notes are definitely the place for this. 3) http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html page does not have menu Good point 4) http://incubator.apache.org/tuscany/sdo-project-code-structure.html no menu , old structure you are right, we need to add a section for the lib project and the tools-test project 5) http://incubator.apache.org/tuscany/getting-source.html no menu and old structure again, yes, this doesn't reflect the move of the api project into the main sdo trunk 6) developer guide - should we refer to http://incubator.apache.org/tuscany/sca-java-development-guide.html and make SDO Dev Guide more complete? I think ideally we would incorporate some of the new content from the sca guide into an sdo guide. If the SCA guide is built up by wiki include directives, there may be scope for including generic chunks into out own guide. 7) http://incubator.apache.org/tuscany/sdo-java-user-guide.html again no menu can refer to http://incubator.apache.org/tuscany/sca-java-user-guide.html 8) TUSCANY-1026 Also, why https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html opens the html page without browser rendering it as html? (like shows all html tags etc.) I think this is a firefox issue. It's fine in IE. Not sure why it's wrong in firefox though. Can we provide this link in http://incubator.apache.org/tuscany/sdo-java-user-guide.html This looks like a useful rework of some of the content that I think is already in the site. It certainly was at one time. 9) TUSCANY-1531 From this - comment #1 - Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http://incubator.apache.org/tuscany/sdo-java-documentation-menu.html as it's one of the pages with more contents on it. looks like is fixed. great And with 7) we can fix comment #2 - User guide has wrong styles : http://incubator.apache.org/tuscany/sdo-java-user-guide.html fine Thanks Amita for this useful review
Re: [Java SDO] What should we be attacking?
Hi, I would like to do Release Management activities for this SDO release. It will be a good learning for me. Appreciate your help. Regards, Amita On Jan 15, 2008 6:42 PM, kelvin goodson [EMAIL PROTECTED] wrote: It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: What should we be concentrating our efforts on in SDO Java. I posted a while back to suggest we think about the content of a next release. We've had a few fixes go in recently, but I'd like to see more consideration of release content before we crank the handle. It would be great to see a balance of new features and bug fixes. For my part I want to get back to ... TUSCANY-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot mapping framework to convert DataObjects to and from Java objects as soon as I can. And I believe that at least 1527 can move beyond proof of concept in my sandbox, and become part of the trunk. I've been taking a pass through the SDO java JIRA backlog, and seeing from my perspective what's simple / tricky / big / high priority etc, etc. Of course simplicity is in the eye of the beholder, for example, I don't view the OSGi topic as simple as I don't have experience there, but someone out there may find it so; if so please speak up. The same goes for priority, etc. As you might imagine, in my estimation there are no simple high priority JIRAs left, but there are a few simple medium priority ones, or simple low priority ones that would be good to just get out of the way. These are Simple Starters === TUSCANY-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static SDO generator: problem with elements named internal* which would be simple For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests This isn't a full list, and I may post more soon. Please feel free to disagree with my assessment and speak up with your own priorities. Better still step forward to help fix something. I'd be only too pleased to help you understand what's required. Kelvin.
Re: An update collision occurred when update the primary key property !
UpdateGenerator forms update statement with where clause like this - iterate over all PKs and include them in where clause. Then iterate over all changed fields and include them in where clause with values set to old values from change summary. In case the PK itself is being changed, this results in something like below - update tableX set idX=? where idX=? and idX=oldValueOfidX Later in ChangeOperation.execute(), when the changed fields in DObj are scanned referring to propertyNames,for idX, the new value is found and set for both idX params above with ?, this is because the first where clause idX is not marked as Collision param. This results in - update tableX set idX=newValueOfIdx where idX=newValueOfIdx and idX=oldValueOfidX This results in 0 rows update in DB and seen by DAS as OCC Exception. A simple fix will be - when changedFields includes a PK, avoid first inclusion in where clause in UpdateGenerator. For other cases (i.e. changedFields do not include PK), keep the logic as is. There can be cases where the PK needs to be modified in the tables - like data migration, system upgrades etc. So the above simple fix will be useful in supporting update of PK. Old discussion ref - http://www.mail-archive.com/[EMAIL PROTECTED]/msg16310.html Minor change on the top of the above discussion is making update efficient by avoiding duplicate inclusion of same column in where clause. New test case - AliasTests.testModifyPK() Submitting patch soon for this. Regards, Amita On Dec 31, 2007 8:48 AM, [EMAIL PROTECTED] wrote: Hi All , I write a sample to test the DAS work with the DB , when execute a update operation on primary key , an update collision occurred , how to deal with it if I need update the primary key value ? Best Regards Leo
Re: What's mean of the managed column in DAS config ?
Hi, If your question is about managed=true setting in a Table's Column, please see http://incubator.apache.org/tuscany/das-java-faq.html#DASJava-FAQ-OptimisticConcurrencyControl for more explanation about managed and collision attributes at Column level and how these can control the Optimistic Concurrency Control feature. Regards, Amita On Dec 31, 2007 7:17 PM, Luciano Resende [EMAIL PROTECTED] wrote: You should set managed = true when running DAS in a managed environment.Some more information can be obtained in this wiki page [1] [1] http://incubator.apache.org/tuscany/rdb-das-transaction-control.html On Dec 30, 2007 7:14 PM, [EMAIL PROTECTED] wrote: Hi All , What's mean of the managed column in DAS config ? I don't know how to use it . please explain it . Best Regards , Leo -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] DAS as web service
There is an old thread - http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01951.html I am just trying to continue the discussion here to come up with requirement, use cases and a basic implementation. Standalone DAS can be used by client by having the required jar in classpath. By exposing DAS as WebService it will be able to - have remote multiple clients using same DAS Web Service. As first attempt - can try to have a basic cycle - ...1) initDAS (), 2) create Command, 3) exec Command(), 4) let client modify DO, 5) applyChange with having the DAS web service tied to one database access. Later based on use cases, requirements, can make things more flexible. It may be needed to have session/conversation management - as the above steps make meaning in the same session For this implementation.das type component can have a wsdl binding. das config.xsd as well as other static model xsds (like company.xsd..) can be refed in the wsdl. 1 initDAS - based on impl.das component's ConnectionInfo can help in getting the DB Connection to DAS runtime. Also, static model xsds can be made known to DAS at this time. 2 as Command structure is known in config.xsd - it can be used as return type of response of createCommand() 3 command.executeQuery() in DAS returns a DO. It may need to be a particular DO Type array like Company[]. 4 There can be problems in Dynamic DAS approach(i.e. DAS without model xsds), as the model is not know before runtime, wsdl can not know the complex type to expect as return of executeCommand(). There can be workarounds like form model based on DB SChema beforehand and use it. But what is the usability of this? i.e. Dynamic DAS as Web Service? 5 like in executeQuery() return type is a known type DO, in applyChanges(DO) a known type can be passed to DAS for persisting in DB. All the above will need some wrapping around the existing APIs to support specific model types passing back and forth. Please share your thoughts. Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another DAS problem/question
DAS is supporting data transfer between SDO and DB. In this, the uniqueness of a DataObject(DO) is ensured by having a PK in it. If this is not done, it will not be possible to get correct query results and also to do CUD on DB based on changes in DO. Due to this the DAS query mandates that the SELECT clause should include a PK. For the same reason support for SQL aggregate functions like count(), sum(), disctinct() etc. is not completely implemented in DAS. In other words, a query like SELECT COUNT(ID) is meant for giving a sum and will not have a PK in it and so will not work well in DAS Query like below will work - (verified in Derby) Command name=countBook SQL=select BOOK_ID, COUNT(*) from BOOK GROUP BY BOOK_ID kind=Select ResultDescriptor columnName=BOOK_ID tableName=BOOK columnType=commonj.sdo.IntObject/ ResultDescriptor columnName=COUNT(*) tableName=BOOK columnType=commonj.sdo.IntObject/ /Command But this does not have any true meaning of count(*) as the result will be something like - ?xml version=1.0 encoding=ASCII? root:root xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:das=http:///org.apache.tuscany.das.rdb/das; xmlns:root=root xsi:type=das:DataGraphRoot BOOK BOOK_ID1/BOOK_ID COUNT(*)1/COUNT(*) /BOOK BOOK BOOK_ID2/BOOK_ID COUNT(*)1/COUNT(*) /BOOK /root:root So apart from MQ SQL Driver related issue, DAS is not supporting aggregate functions as these can not be tied to Table Row PK per ResultSet row. Workaround will be get all records using SELECT BOOK_ID FROM BOOK as DAS Command and then do aggregate operations using Java API instead of native SQL function inside SQL Query. If your requirement is far more complex than SELECT count(*), you can try the stored procedure support provided in DAS. e.g. check StoredProcs.testGetNamedCustomers() test case to see how the count(*) is returned through OUT param and the DataGraph of DOs is returned as return value. Regards, Amita On Nov 7, 2007 4:50 AM, Jason Clark [EMAIL PROTECTED] wrote: As I've stated before, I'm not getting the metadata returned to me for a query. As such, I'm having to provide result descriptors, including an ID. I want to do the following Command name=count SQL=select COUNT(ID) from CONTACTS kind=Select /Command Without metadata being returned, it's again asking me for result descriptors. But, if I just add ResultDescriptor columnName=COUNT tableName=CONTACTS columnType=commonj.sdo.Int/ I get told no ID. But, obviously, there can't be ResultDescriptor columnName=ID tableName=CONTACTS columnType=commonj.sdo.Int/ because that query returns a resultset with 1 column. Has anyone else had experience with SQL Server 2005 not returning MetaData? Their docs says they do and I have their latest drivers, but I'm getting very little for metadata. A simple test of the metadata results returns Column Table Name: Schema name: Column Type: 12 Column Name: BUSINESS_CELL As you can see, I'm missing Table Name and Schema Name. I'm doing a simple Select query on this, so. I'm at a loss here. Any more ideas? -Jason Clark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] need to correct condition check in UpdateGenerator
Link to JIRA - https://issues.apache.org/jira/browse/TUSCANY-1895
RDB DAS - UpdateGenerator performs incorrect check when passing
property values from parent DO to child DO. It tries to find
the FK property in Parent DO and gives exception. code
.UdateGenerator.getChangedFields() - if (!ref.isMany()) {.
This might have remained undetected as there are no test cases with
1-1 relationship with keyRestricted=false
Could form one test case showing the failure. Please see if this is
the error you are getting and also explain for what setup you got the
exception.
CONFIG - 1-1 relationship with keyRestricted=false as below
Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;
Command name=get named employee with company
SQL=select * from EMPLOYEE left outer join COMPANY on EMPLOYEE.ID
= COMPANY.EOTMID where EMPLOYEE.NAME= ? kind = Select/
Table tableName=COMPANY
Column columnName=ID primaryKey=true/
/Table
Table tableName=EMPLOYEE
Column columnName=ID primaryKey=true/
/Table
Relationship name=company primaryKeyTable=EMPLOYEE
foreignKeyTable=COMPANY many=false keyRestricted=false
KeyPair primaryKeyColumn=ID foreignKeyColumn=EOTMID /
/Relationship
/Config
TEST CASE
--
public void testNonRestrictedOneToOneRelationshipUpdate() throws Exception {
DAS das =
DAS.FACTORY.createDAS(getConfig(OneToOneRestrictedConfig.xml),
getConnection());
Command read = das.getCommand(get named employee with company);
read.setParameter(1, Mary Smith);
DataObject root = read.executeQuery();
DataObject mary = root.getDataObject(EMPLOYEE[1]);
//update parent and create child
mary.setString(NAME, maryNew);
DataObject comp = root.createDataObject(COMPANY);
comp.setInt(ID, 100);
comp.setString(NAME, comp100);
mary.setDataObject(company, comp);
try {
das.applyChanges(root);
} catch (RuntimeException ex) {
ex.printStackTrace();
}
//refresh to see the db data
read.setParameter(1, maryNew);
root = read.executeQuery();
mary = root.getDataObject(EMPLOYEE[1]);
comp = mary.getDataObject(company);
assertEquals(2, comp.getInt(EOTMID));
}
Result:
---
Invalid foreign key column: EOTMID
at
org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.getChangedFields(UpdateGenerator.java:232)
Reason:
---
When doing update for EMPLOYEE, UpdateGenerator tries to find property
EOTMID in DO EMPLOYEE and fails to find it.
Solution:
Check similar to InsertGenerator.hasState(), this fixes the issue.
Note:
-
Trying other combinations of relationships like 1-n, 1-1 with
keyRestricted etc. as well as autogenerated PK effect for all the
cases.
Regards,
Amita
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Different DB Drivers pulling information differently?
What is the column type in database for LAST_NAME? If it is varchar, what is the length if any specified? Regards, Amita On 11/3/07, Jason Clark [EMAIL PROTECTED] wrote: My Config. ConnectionInfo ConnectionProperties driverClass=net.sourceforge.jtds.jdbc.Driver databaseURL=jdbc:jtds:sqlserver:///cr userName=* password=*** loginTimeout=600/ /ConnectionInfo Command name=all contacts SQL=select ID,LAST_NAME from CONTACTS kind=Select ResultDescriptor columnName=ID tableName=CONTACTS columnType=commonj.sdo.Int/ ResultDescriptor columnName=LAST_NAME tableName=CONTACTS columnType=commonj.sdo.String/ /Command Table tableName=CONTACTS Column columnName=ID primaryKey=true generated=true/ /Table With the JTDS driver, I get the following exception. Exception in thread main java.lang.ClassCastException: The value of type 'class net.sourceforge.jtds.jdbc.ClobImpl' must be of type 'class java.lang.String' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSin gleDataUnsettableStatic.validate(EStructuralFeatureImpl.java:2195) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSin gleDataUnsettable.dynamicSet(EStructuralFeatureImpl.java:2116) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet( BasicEObjectImpl.jav a:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (DynamicDataObj ectImpl.java:160) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java :1459) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java :654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142) at org.apache.tuscany.das.rdb.graphbuilder.impl.DataObjectMaker.createAndAddDat aObject(DataObjectMaker.java:90) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.addRowToGrap h(ResultSetProcessor.java:127) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processResul tSet(ResultSetProcessor.java:91) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processResul ts(ResultSetProcessor.java:77) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.buildGraph( ReadCommandImpl.j ava:309) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery (ReadCommandImpl .java:277) at com.p21csi.cr.service.contact.ContactDASTest.getContacts( ContactDASTest.java :22) at com.p21csi.cr.service.contact.ContactDASTest.printContacts( ContactDASTest.ja va:28) at com.p21csi.cr.service.contact.ContactDASTest.main(ContactDASTest.java :41) But, with the MS Driver, I get no exception and it executes correctly? I'm not sure if this has anything to do with Tuscany and DAS directly, but I was just wondering if anyone had any idea why this is happening? -Jason Clark
Re: Different DB Drivers pulling information differently?
If the requirement is not for MAX size, will you please try to reduce it to some appropriate one? I am not very sure as I do not have the setup ready for these 2 drivers, but looks like JTDS is treating big length varchars like CLOB and the other driver (MS) is treating same as varchar. DAS does not do any type conversion when sdo type is said to be String , but when the data from database is tried to be set in SDO, due to JTDS, a clob is tried to be set in SDO property of Type String which is incompatible. If you indeed need a MAX size varchar please refer to - LOBTests.testReadWriteClob() to see how it works and ResultDescriptor will need commonj.sdo.Object setting. Please let me know if that works for you. Regards, Amita On 11/6/07, Jason Clark [EMAIL PROTECTED] wrote: The column type is varchar and I believe it is set to MAX size at the moment. Could that be causing the problem? I honestly don't know that much about databases but my project doesn't have enough money to hire someone who does. -Jason -Original Message- From: Amita Vadhavkar [mailto:[EMAIL PROTECTED] Sent: Sunday, November 04, 2007 11:15 PM To: tuscany-user@ws.apache.org Subject: Re: Different DB Drivers pulling information differently? What is the column type in database for LAST_NAME? If it is varchar, what is the length if any specified? Regards, Amita On 11/3/07, Jason Clark [EMAIL PROTECTED] wrote: My Config. ConnectionInfo ConnectionProperties driverClass=net.sourceforge.jtds.jdbc.Driver databaseURL=jdbc:jtds:sqlserver:///cr userName=* password=*** loginTimeout=600/ /ConnectionInfo Command name=all contacts SQL=select ID,LAST_NAME from CONTACTS kind=Select ResultDescriptor columnName=ID tableName=CONTACTS columnType=commonj.sdo.Int/ ResultDescriptor columnName=LAST_NAME tableName=CONTACTS columnType=commonj.sdo.String/ /Command Table tableName=CONTACTS Column columnName=ID primaryKey=true generated=true/ /Table With the JTDS driver, I get the following exception. Exception in thread main java.lang.ClassCastException: The value of type 'class net.sourceforge.jtds.jdbc.ClobImpl' must be of type 'class java.lang.String' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateS in gleDataUnsettableStatic.validate(EStructuralFeatureImpl.java:2195) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateS in gleDataUnsettable.dynamicSet(EStructuralFeatureImpl.java:2116) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet( BasicEObjectImpl.jav a:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (DynamicDataObj ectImpl.java:160) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java :1459) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java :654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142) at org.apache.tuscany.das.rdb.graphbuilder.impl.DataObjectMaker.createAndAddD at aObject(DataObjectMaker.java:90) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.addRowToGr ap h(ResultSetProcessor.java:127) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processRes ul tSet(ResultSetProcessor.java:91) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processRes ul ts(ResultSetProcessor.java:77) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.buildGraph( ReadCommandImpl.j ava:309) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery (ReadCommandImpl .java:277) at com.p21csi.cr.service.contact.ContactDASTest.getContacts( ContactDASTest.java :22) at com.p21csi.cr.service.contact.ContactDASTest.printContacts( ContactDASTest.ja va:28) at com.p21csi.cr.service.contact.ContactDASTest.main( ContactDASTest.java :41) But, with the MS Driver, I get no exception and it executes correctly? I'm not sure if this has anything to do with Tuscany and DAS directly, but I was just wondering if anyone had any idea why this is happening? -Jason Clark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS configuration must specify ResultDescriptors
It will mostly be limitation of the driver - which one are you using? See
some below
links to get the driver from microsoft and the library details the use of
result set metadata.
*
http://www.microsoft.com/downloads/details.aspx?FamilyID=D09C1D60-A13C-4479-9B91-9E8B9D835CDCdisplaylang=en-
download site
*http://msdn2.microsoft.com/hi-in/sql/Aa336346.aspx - SP2
*http://msdn2.microsoft.com/en-us/library/ms378760.aspx - driver class
supporting all
reqd methods
Regards,
Amita
On 11/2/07, Jason Clark [EMAIL PROTECTED] wrote:
I updated my test to output all the information from the methods you
listed
below that required support.
For my PK column, a simple id ID, it did not list information for the
Column
Table Name or the schema name. For all other columns, only the Schema name
was not listed.
Is this information I can correct in the database, or is it inherent to
the
database the JDBC driver is simply not supporting it?
-Jason
This e-mail and any files transmitted with it are intended solely for the
use of the individual or entity to whom they are addressed. If you have
received this e-mail in error please notify the sender immediately and
delete this e-mail from you system. This message may contain company
proprietary, sensitive information and is intended only for the individual
named. Its contents may be covered under the Trade Secret Act of various
jurisdictions. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. If you are not the intended
recipient you are notified that disclosing, copying, distributing or
taking
any action in reliance on the contents of this information is strictly
prohibited.
-Original Message-
From: Amita Vadhavkar [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 31, 2007 8:34 PM
To: tuscany-user@ws.apache.org
Subject: Re: DAS configuration must specify ResultDescriptors
TUSCANY-1465 is the JIRA which added index to the ResultDescriptor
With that the physical order can be anything for ResultDescriptor
as long as index is used properly. This JIRA helps in specifying
result descriptor programmatically (i.e. not thru config file).
See DynamicResultDescriptorTests.java and
http://incubator.apache.org/tuscany/explicit-resultset-shape-
definition.html
.
This feature is part of latest DAS release - beta2.
Prior to this fix, there was no index and as you say order is what
matters
and not name in ResultDescriptor.
As there is a column named ID in table CONTACTs, DAS following
conventions uses it as PK, now if it is really not unique in the
database,
it can cause problems in DB-DataObject xfer. e.g. if you have 2 rows
having ID=1, and do select * from contact, then, the data graph obtained
by DAS will not be able to show both rows in its data objects.
For using SQL Server 2005 express edition provided db metadata -
came across this url -
http://forum.java.sun.com/thread.jspa?threadID=704004tstart=150
So looks like there are some problems in the support when it comes to
supporting resultsetmetadata.
What needs to be working is
- getTableName(idx), getSchemaName(idx), getColumnCount(),
getColumnType(idx),
getColumnName(idx). If all these are working, then DAS will be able to
use
the db metadata and will not need extra specification of
ResultDescriptor
in
config file. So, you can check if some driver for SQL Server is
supporting
all
these APIs and if you can use it. In that case, the ResultDecriptor
can
go
away.
Please let me know if this helps.
Regards,
Amita
On 11/1/07, Jason Clark [EMAIL PROTECTED] wrote:
As a follow up, I wrote a simple class to test this.
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
String conUrl = jdbc:sqlserver://
Connection con = DriverManager.getConnection (conUrl);
try {
Statement st = con.createStatement();
ResultSet rs = st.executeQuery(SELECT * FROM CONTACTS);
ResultSetMetaData md = rs.getMetaData();
int col = md.getColumnCount();
System.out.println(Number of Column : + col);
System.out.println(Columns Name: );
for (int i = 1; i = col; i++) {
String col_name = md.getColumnName(i);
System.out.println(col_name);
}
}
This successfully returned metadata about my table.
If I do this...
Command name=all contacts SQL=select * from CONTACTS
kind=Select
ResultDescriptor columnName=ID tableName=CONTACTS
columnType=commonj.sdo.Int/
ResultDescriptor columnName=FIRST_NAME tableName=CONTACTS
columnType=commonj.sdo.String/
ResultDescriptor columnName=LAST_NAME tableName=CONTACTS
columnType=commonj.sdo.String/
ResultDescriptor columnName=MIDDLE_NAME tableName=CONTACTS
columnType=commonj.sdo.String/
/Command
I can then grab those columns
Re: DAS configuration must specify ResultDescriptors
TUSCANY-1465 is the JIRA which added index to the ResultDescriptor
With that the physical order can be anything for ResultDescriptor
as long as index is used properly. This JIRA helps in specifying
result descriptor programmatically (i.e. not thru config file).
See DynamicResultDescriptorTests.java and
http://incubator.apache.org/tuscany/explicit-resultset-shape-definition.html
.
This feature is part of latest DAS release - beta2.
Prior to this fix, there was no index and as you say order is what matters
and not name in ResultDescriptor.
As there is a column named ID in table CONTACTs, DAS following
conventions uses it as PK, now if it is really not unique in the database,
it can cause problems in DB-DataObject xfer. e.g. if you have 2 rows
having ID=1, and do select * from contact, then, the data graph obtained
by DAS will not be able to show both rows in its data objects.
For using SQL Server 2005 express edition provided db metadata -
came across this url -
http://forum.java.sun.com/thread.jspa?threadID=704004tstart=150
So looks like there are some problems in the support when it comes to
supporting resultsetmetadata.
What needs to be working is
- getTableName(idx), getSchemaName(idx), getColumnCount(),
getColumnType(idx),
getColumnName(idx). If all these are working, then DAS will be able to use
the db metadata and will not need extra specification of ResultDescriptor in
config file. So, you can check if some driver for SQL Server is supporting
all
these APIs and if you can use it. In that case, the ResultDecriptor can go
away.
Please let me know if this helps.
Regards,
Amita
On 11/1/07, Jason Clark [EMAIL PROTECTED] wrote:
As a follow up, I wrote a simple class to test this.
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
String conUrl = jdbc:sqlserver://
Connection con = DriverManager.getConnection (conUrl);
try {
Statement st = con.createStatement();
ResultSet rs = st.executeQuery(SELECT * FROM CONTACTS);
ResultSetMetaData md = rs.getMetaData();
int col = md.getColumnCount();
System.out.println(Number of Column : + col);
System.out.println(Columns Name: );
for (int i = 1; i = col; i++) {
String col_name = md.getColumnName(i);
System.out.println(col_name);
}
}
This successfully returned metadata about my table.
If I do this...
Command name=all contacts SQL=select * from CONTACTS kind=Select
ResultDescriptor columnName=ID tableName=CONTACTS
columnType=commonj.sdo.Int/
ResultDescriptor columnName=FIRST_NAME tableName=CONTACTS
columnType=commonj.sdo.String/
ResultDescriptor columnName=LAST_NAME tableName=CONTACTS
columnType=commonj.sdo.String/
ResultDescriptor columnName=MIDDLE_NAME tableName=CONTACTS
columnType=commonj.sdo.String/
/Command
I can then grab those columns, but I did notice the order is important and
the column name has nothing to do with the actual column name, it just
says
that the name you query the data object with is the word FIRST_NAME. It
could be monkey, it doesn't matter. Not a problem though, but I can't
figure
out why I need result descriptors if I ResultSet.getMetaData () in fact
returns the correct information.
Any ideas?
Thanks.
-Jason
-Original Message-
From: Luciano Resende [mailto:[EMAIL PROTECTED] ]
Sent: Tuesday, October 30, 2007 6:39 PM
To: tuscany-user@ws.apache.org
Subject: Re: DAS configuration must specify ResultDescriptors
There are some databases that does not return metadata information,
and DAS need that to build the result SDO Graph.More info on
ResultDescriptor here [1].
What database are you using ?
[1] http://incubator.apache.org/tuscany/explicit-resultset-shape-
definition.html
On 10/30/07, Jason Clark [EMAIL PROTECTED] wrote:
I'm getting the following exception when trying to implement simple
DAS
CRUD
operations.
Exception in thread main java.lang.RuntimeException: Unable to
obtain
table information from JDBC. DAS configuration must specify
ResultDescriptors
at
org.apache.tuscany.das.rdb.graphbuilder.impl.ResultMetadata.init(ResultM
et
adata.java:81)
at
org.apache.tuscany.das.rdb.graphbuilder.impl.GraphBuilderMetadata
.init(G
ra
phBuilderMetadata.java :69)
at
org.apache.tuscany.das.rdb.impl.ReadCommandImpl.buildGraph
(ReadCommandImpl
.j
ava:295)
at
org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery(ReadCommandIm
pl
.java:277)
at ContactDASTest.getContacts(ContactDASTest.java:22)
at ContactDASTest.printContacts(ContactDASTest.java:28)
at ContactDASTest.main(ContactDASTest.java:41)
Given the following config. I tried following the Company example and
their
config.
I'm unsure what a ResultDescriptor is and why I would need one, but
the
Company example does
Re: generated fields in Static SDO's not getting populated
valid problem. patch is provided for review in TUSCANY-1807. Detailed analysis in same place. Regards, Amita On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If I attach a static SDO to a data graph, that has a generated id field, after applyChanges, that field on the static SDO does not get updated. If I update the config xml to not have a dataModel attribute, and do not associate the table or columns in my config.xml with a type, and just use a dynamic data object to apply changes, then the id field does get updated correctly after insert to the database. I have confirmed this in the latest DAS release, and the latest DAS SNAPSHOT as well. I can provide full examples of my code if that is needed. Thanks. -Nick - This communication from United Guaranty Corporation or its subsidiary is directed to and is for the use of the individual or entity to which it is addressed. It may contain information that is confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any distribution, dissemination, or copy of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately, and then delete or destroy the material in its entirety. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Das beta2 MySQL Customer Example
Please see with the below steps, if it works for you, I am also modifying the beta2 sample readme to include the same instructions for use with other dbs like MySQL, DB2 etc. On 9/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I took the following steps to get the customer sample working with MySQL Used bin distro 0) expand sample-customer.jar to get access to CustomersConfig.xml 1) change CustomersConfig.xml to comment derby connection info and uncomment mysql connection info (check for correct id, pwd, url, driver class etc.) 2) change build.xml to replace pathelement location from derby jar to mysql jar (e.g.mysql-connector-java-5.0.4.jar) 3) create sample-customer.jar to use the changed CustomersConfig.xml(remove the one that comes from bin destro) and put the new sample-customer.jar under directory customer/ 4) place required mysql jar (e.g. mysql-connector-java-5.0.4.jar) under directory customer/ 5) with these changes - ant will locate mysql jar and new config xml 6) now do ant from customer/ With this I could verify that mysql data is getting used in the sample. run: [java] * Initializing database * [java] ** DB type : mysql [java] ** Database : jdbc:mysql://localhost/dastest [java] ** User : root [java] ** Password : mypwd [java] [java] Setting up for mysql run! [java] Dropping tables [java] Dropping procedures [java] Creating tables [java] Creating procedures [java] Inserting data in tables [java] Database setup complete! [java] [java] Result:select all customers [java]ID:1 LASTNAME:John ADDRESS:USA [java]ID:2 LASTNAME:Amita ADDRESS:INDIA [java]ID:3 LASTNAME:Patrick ADDRESS:UK [java]ID:4 LASTNAME:Jane ADDRESS:UN [java] [java] Result:insert new customer [java]ID:1 LASTNAME:John ADDRESS:USA [java]ID:2 LASTNAME:Amita ADDRESS:INDIA [java]ID:3 LASTNAME:Patrick ADDRESS:UK [java]ID:4 LASTNAME:Jane ADDRESS:UN [java]ID:5 LASTNAME:Jenny ADDRESS:USA [java] [java] Result:update first customer [java]ID:1 LASTNAME:BlueBerry ADDRESS:USA [java]ID:2 LASTNAME:Amita ADDRESS:INDIA [java]ID:3 LASTNAME:Patrick ADDRESS:UK [java]ID:4 LASTNAME:Jane ADDRESS:UN [java]ID:5 LASTNAME:Jenny ADDRESS:USA [java] [java] Result:delete last customer [java] Deleting customer named: Jenny [java]ID:1 LASTNAME:BlueBerry ADDRESS:USA [java]ID:2 LASTNAME:Amita ADDRESS:INDIA [java]ID:3 LASTNAME:Patrick ADDRESS:UK [java]ID:4 LASTNAME:Jane ADDRESS:UN Regards, Amita On 9/14/07, Eborn, Eric D [EMAIL PROTECTED] wrote: It seems there is a new problem with Beta2, it follows the path of execution for a MySQL data base but then decides to connect to a derby db... Seems strange to me, likely a bug. BUILD SUCCESSFUL Total time: 1 second D:\data\eeborn\Desktop\tuscany-das-1.0-incubating-beta2\samples\customer ant Buildfile: build.xml run: [java] * Initializing database * [java] ** DB type : mysql [java] ** Database : jdbc:mysql://localhost/dastest [java] ** User : dastest [java] ** Password : dastest [java] [java] Exception in thread main java.lang.NoSuchMethodError: org.apache.derby.jdbc.InternalDriver.embeddedDriverAcceptsURL(Ljava/lang /String;)Z [java] at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source) [java] at java.sql.DriverManager.getConnection(DriverManager.java:582) [java] at java.sql.DriverManager.getConnection(DriverManager.java:154) [java] at org.apache.tuscany.samples.das.databaseSetup.DatabaseSetup.initConnectio n(DatabaseSetup.java:108) [java] at org.apache.tuscany.samples.das.databaseSetup.DatabaseSetup.init(Databa seSetup.java:66) [java] at org.apache.tuscany.samples.das.databaseSetup.MySQLSetup.init(MySQLSetu p.java:26) [java] at org.apache.tuscany.samples.das.customer.CustomerDatabaseInitializer.Init ialize(CustomerDatabaseInitializer.java:75) [java] at org.apache.tuscany.samples.das.customer.CustomerClient.main(CustomerClie nt.java:165) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 0 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RDB DAS read, then write XML file for data export
Please see our nightly build if you can download from there - (last
successful is on Sep 5th)
http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
http://vmbuild.apache.org:8080/continuum/workingCopy.action?projectId=36projectName=Apache+Tuscany+DAS+Implementation+projectuserDirectory=distribution/binary/target
For having all customer records in one xml file -
you are using the same stream in a loop to write each serialized data
object. But I guess you will need to a bit of file manipulation to remove
repeated headers like below,
?xml version=1.0 encoding=ASCII?
cust1:cust1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cust1=cust1
xmlns:this=http:///org.apache.tuscany.das.rdb.test/customer.xsd;
xsi:type=this:Customer
Or you can loop through all DO records as of now, but instead of directly
serializing each DO
in XML, do getInt(ID), getString(LASTNAME), in a file - OR
if you are using static SDO approach (i.e. have say customer.xsd and use
static SDO APIS)
CUSTOMET.getId(), CUSTOMER.getLastName()...
But I am not sure about any simpler alternative right now.
Regards,
Amita
On 9/7/07, Eborn, Eric D [EMAIL PROTECTED] wrote:
I am using beta1. However, the proxy I connect through disallows
external SVN servers. Is there an HTTP download of the trunk binary?
That xml output looks good, except, is it possible to have it display
all 4 customer records in the single XML file?
-Original Message-
From: Amita Vadhavkar [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 06, 2007 11:25 PM
To: tuscany-user@ws.apache.org
Subject: Re: RDB DAS read, then write XML file for data export
Hi ,
Will you please try the example with latest SDO and DAS code from svn
trunk,
There are some differences in DAS-beta1 (older releases) and the
current
one
from
https://svn.apache.org/repos/asf/incubator/tuscany/java/. These
differences
are due to some
changes in SDO. With the latest one, I am getting something like
below-
for
System.out.println(XMLHelper.INSTANCE.save(((DataObject)customers.iterat
or
().next()),
cust1, cust1));
Result -
?xml version=1.0 encoding=ASCII?
cust1:cust1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cust1=cust1
xmlns:this=http:///org.apache.tuscany.das.rdb.test/customer.xsd;
xsi:type=this:Customer
ID1/ID
lastNameWilliams/lastName
address1212 foobar lane/address
/cust1:cust1
Are you using DAS-beta1?
Regards,
Amita
On 9/6/07, Eborn, Eric D [EMAIL PROTECTED] wrote:
I came across this excellent article about how to do basics with SDO
including writing out a datagraph to an XML document.
http://www.ibm.com/developerworks/xml/library/ws-sdoxmlschema/index.html
What I wish to do is similar, I wish to read data from a MySQL
database
using RDB DAS and then store that information into an XML file using
XMLHelper (I suppose this is the preferred way). This XML data will
eventually be destined for a JMS message for export to its
destination.
I'm building off of the sample Customers for now until I get a
working
model...
So far I've added this code to my Customer sample code:
private void outputXML() throws Exception {
Command readAll = das.getCommand(AllCustomers);
CUSTOMER = readAll.executeQuery();
DataObject resultSet =
DataFactory.INSTANCE.create(RES_NAMESPACE, resultSetType);
OutputStream stream = new FileOutputStream(RES_XML);
List allCustomers = CUSTOMER.getList(CUSTOMER);
int i = 1;
for(i=0; iallCustomers.size(); i++)
{
XMLHelper.INSTANCE.save((DataObject)allCustomers.get(i),
RES_NAMESPACE,
CUSTOMER, stream);
stream.write(13);
//writes
a carraige return to the XML file.
stream.write(10);
}
}
This does generate an XML file, but its contents are all wrong... I
want it to follow the XSD:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.example.com/RESULTSET;
targetNamespace=http://www.example.com/RESRESULTSET;
xsd:element name=CUSTOMER type=resultSetType/
xsd:complexType name=resultSetType
xsd:sequence
xsd:element name=LASTNAME type=xsd:string/
xsd:element name=ADDRESS type=xsd:string/
xsd:element name=ID type=xsd:positiveInteger/
/xsd:sequence
/xsd:complexType
/xsd:schema
But my program outputs:
?xml version=1.0 encoding=ASCII?
resSS:CUSTOMER
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:resSS=http://www.example.com/resSS;
xsi:type=das:CUSTOMER
ID=1 LASTNAME=John ADDRESS=USA/
?xml version=1.0
Re: RDB DAS read, then write XML file for data export
Hi ,
Will you please try the example with latest SDO and DAS code from svn trunk,
There are some differences in DAS-beta1 (older releases) and the current one
from
https://svn.apache.org/repos/asf/incubator/tuscany/java/. These differences
are due to some
changes in SDO. With the latest one, I am getting something like below-
for
System.out.println(XMLHelper.INSTANCE.save(((DataObject)customers.iterator().next()),
cust1, cust1));
Result -
?xml version=1.0 encoding=ASCII?
cust1:cust1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cust1=cust1
xmlns:this=http:///org.apache.tuscany.das.rdb.test/customer.xsd;
xsi:type=this:Customer
ID1/ID
lastNameWilliams/lastName
address1212 foobar lane/address
/cust1:cust1
Are you using DAS-beta1?
Regards,
Amita
On 9/6/07, Eborn, Eric D [EMAIL PROTECTED] wrote:
I came across this excellent article about how to do basics with SDO
including writing out a datagraph to an XML document.
http://www.ibm.com/developerworks/xml/library/ws-sdoxmlschema/index.html
What I wish to do is similar, I wish to read data from a MySQL database
using RDB DAS and then store that information into an XML file using
XMLHelper (I suppose this is the preferred way). This XML data will
eventually be destined for a JMS message for export to its destination.
I'm building off of the sample Customers for now until I get a working
model...
So far I've added this code to my Customer sample code:
private void outputXML() throws Exception {
Command readAll = das.getCommand(AllCustomers);
CUSTOMER = readAll.executeQuery();
DataObject resultSet =
DataFactory.INSTANCE.create(RES_NAMESPACE, resultSetType);
OutputStream stream = new FileOutputStream(RES_XML);
List allCustomers = CUSTOMER.getList(CUSTOMER);
int i = 1;
for(i=0; iallCustomers.size(); i++)
{
XMLHelper.INSTANCE.save((DataObject)allCustomers.get(i), RES_NAMESPACE,
CUSTOMER, stream);
stream.write(13); //writes
a carraige return to the XML file.
stream.write(10);
}
}
This does generate an XML file, but its contents are all wrong... I
want it to follow the XSD:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.example.com/RESULTSET;
targetNamespace=http://www.example.com/RESRESULTSET;
xsd:element name=CUSTOMER type=resultSetType/
xsd:complexType name=resultSetType
xsd:sequence
xsd:element name=LASTNAME type=xsd:string/
xsd:element name=ADDRESS type=xsd:string/
xsd:element name=ID type=xsd:positiveInteger/
/xsd:sequence
/xsd:complexType
/xsd:schema
But my program outputs:
?xml version=1.0 encoding=ASCII?
resSS:CUSTOMER xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:resSS=http://www.example.com/resSS; xsi:type=das:CUSTOMER
ID=1 LASTNAME=John ADDRESS=USA/
?xml version=1.0 encoding=ASCII?
resSS:CUSTOMER xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:resSS=http://www.example.com/resSS; xsi:type=das:CUSTOMER
ID=2 LASTNAME=BlueBerry ADDRESS=INDIA/
?xml version=1.0 encoding=ASCII?
resSS:CUSTOMER xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:resSS=http://www.example.com/resSS; xsi:type=das:CUSTOMER
ID=3 LASTNAME=Patrick ADDRESS=UK/
?xml version=1.0 encoding=ASCII?
resSS:CUSTOMER xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:resSS=http://www.example.com/resSS; xsi:type=das:CUSTOMER
ID=4 LASTNAME=Jane ADDRESS=UN/
?xml version=1.0 encoding=ASCII?
resSS:CUSTOMER xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:resSS=http://www.example.com/resSS; xsi:type=das:CUSTOMER
ID=5 LASTNAME=Jenny ADDRESS=USA/
I'm hoping that someone has done something similar and could point me in
the right direction because at the moment im generating content for 5
different xml files into one file, when I'd like to have all the rows of
data contained in one xml file in the format:
XML
CUSTOMER
ID1/ID
LASTNAMEJohn/LASTNAME
ADDRESSUSA/ADDRESS
/CUSTOMER
CUSTOMER
ID2/ID
LASTNAMEBlueberry/LASTNAME
ADDRESSIndia/ADDRESS
/CUSTOMER
Etc...
Thanks
Eric
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] What's next for Tuscany DAS ?
sounds good to me. On 9/6/07, Luciano Resende [EMAIL PROTECTED] wrote: Good, looks like we have most (if not all) the updates necessary to support SDO 2.1 specification and to be compatible with SDO 1.0 release. I'd like to start to work on a new release in the next couple days, and if we make it on time, we could still have a chance to include DAS in the SCA 1.0 release (planned for middle of September). As for naming, I was thinking to make this a beta2 release. Thoughts ? On 8/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: I have attached patch for TUSCANY-961+ TUSCANY-986 combined in TUSCANY-961. One observation here - Generated code shows usage of deprecated method FactoryBase.getProperty (Type, int) and needs to be replaced by getLocalProperty(), any changes needed in xsdtojava generator in SDO? Any suggestions? Regards, Amita On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- 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] -- 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: Where could I found the source in the package of org.apache.tuscany.das.rdb.config
Hi, When you extract the src and do mvn build, all these files will get generated. There is a sdo-plugin used (see pom.xml) which does xsd2java generation. So in the src zip, the xsds will be there but not the java files. If you take the bin zip , you will get the class files for these. Regards, Amita On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi , When I downlaod the tuscany-das-1.0-incubating-beta1-src.zip , the zip file doesn't include the source file such as org.apache.tuscany.das.rdb.config.Parameter , org.apache.tuscany.das.rdb.config.Command . Why these source file couldn't included the source zip ? Leo
Re: How to deal with the DateTime field in DAS ?
Hi, java.sql.Types.DATE, TIME and TIMESTAMP maps to commonj.sdo.Date. Also see, KennelTests.testSimple5() for an example of using Timestamp - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/ Regards, Amita On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All , How to deal with the DateTime field , Which is the best way to deal between the java.util.Date and SDO DateTime property ? Leo
Re: Having problem with null values in my DAS
Great to see that the code is working now. DAS uses Convention over configuration. Please see [1]http://incubator.apache.org/tuscany/conventionoverconfiguration.html for some details. DAS creates / uses DataObjects which rely on uniqueness based on the Primary Key. So all tables involved need to have PK. Now to make DAS know about the PKs, if the column names are following the convention - i.e. if name is ID for a PK column, user does not need to define Table in config. Please see, from DAS svn codebase - [2]https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/ - [2]CrudWithChangeHistory.testReadModifyApply4() - uses CustomerConfig.xml - which does not have Table defined. But in case the convention is not followed, i.e. PK column name is something else but not ID, user needs to define Table in config. [2]Please see, AliasTests with config BooksConfigWithAlias.xml. Also, it is not needed to specify all Columns in Table, but at lease the Column with PK should be specified with attribute primaryKey=true . Also, in [1], there is convention described for relationships when parent and child table have columns ID and xxx_ID, and parent table name is xxx, then 1-n relationship is assumed and it need not be specified in config. If this column naming convention is not followed, then user will need to define explicit relationship in config. [2]RelationshipTests - shows many examples of explicit relationships. [2]ImpliedRelationshipTests - shows examples of implicit relationships. Hope that you find these and other examples useful. Regards, Amita On 8/30/07, Chu, Wing (Exchange) [EMAIL PROTECTED] wrote: Amita, Thanks very much! I did not define a table definition in the configuration file. Once I define it, the problem goes away. What's the guideline for including a table and relationship definition in the configuration file? Since I was only doing queries and is returning data (when all column is not null), I thought the ResultDescriptor in the command definition is sufficient. Regards, Wing -Original Message- From: Amita Vadhavkar [mailto:[EMAIL PROTECTED] Sent: Thursday, August 30, 2007 1:58 AM To: tuscany-user@ws.apache.org Subject: Re: Having problem with null values in my DAS Will you please share the config file and the data/table info here, so I can simulate the condition. When tried with a simple sample, it seems that - when any other column other that the one mentioned in DAS as PK has null value, DAS is producing correct result. So, your details will help. Also, will you please see if the query is including PK in the SELECT clause. Regards, Amita On 8/30/07, Chu, Wing (Exchange) [EMAIL PROTECTED] wrote: I am wondering if anyone came across this. I have a simple select A,B,C from TABLE1 where A=? I have no problem get the DataObject back when all the values are not null. However, if any one of the value is null. I would get an object but the values and the list is null. This seems not right to me. Is there a configuration that I miss? I am working with Oracle 10g Thanks, Wing *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
Hi, I have tried to use JOTM and Tomcat and would like to create a sample web app in DAS showing how external transaction manager can control DAS transactions. I am creating another mail thread for any discussion for this sample + JOTM issues. We can demonstrate through this and accompanying wiki - how Txn support in DAS for externally managed txns should do. Regards, Amita On 8/17/07, Luciano Resende [EMAIL PROTECTED] wrote: By doing a quick debug on Amita's testcase from JIRA-1543, looks like we might have some bugs in our current code, that might be causing this whole confusion. Let me spend couple hours on this over the weekend, and send some feedback after that. I'll also write a wiki page with what I think the Transaction support should do/work. On 8/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07
[DAS] DAS Web Sample with Tomcat and JOTM as Transaction Manager
I am using jotm-2.0.10 and Tomcat 5.5.23. The HowTo from JOTM site has a few problems and the below info worked for me - [1]http://www.nabble.com/UserTransaction,- JOTM-and-Tomcat-5.5.x-t1073172.html [2]http://static.raibledesigns.com/downloads/howto-tomcat-jotm.html Also, as mentioned in [1] for hsql, for Derby too , I checked that ut.rollback does not work (used the sample from .jotm-2.0.10\examples\tomcat - tailored for Derby). So, MySQL may need to be used for this. With its InnoDB feature ON. (Ref - [3]http://www.onjava.com/pub/a/onjava/2003/07/30/jotm_transactions.html?page=2 ) Please see the attached screenshot and comment if something like this will be useful as the sample? Or some different use case/example will suite better. Also, I am finding it quite easy to re-use the sample-ajax-das framework to deploy this new sample. Please advise, if it should stand separate and not part of that sample. The ease in re-use lies in the generic -servlet, js, menu jsp and service processor etc. We can rename sample-ajax-das to ''Advanced DAS Web Sample, any better name? Please comment on all of the above, so I will proceed with creating the required sample using your feedback. Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RDB DAS] Consistent use of Parameters in Config
Thanks Kevin, for correcting the example, I actually meant what you have
assumed :)
Also, another question in JDK5 context, the code will be very precise and
type checking/assumptions about types can be avoided in many places in DAS
using JDK5 generics. Other features from JDK5 can be used too. So, I am just
curious to know the different
pros and cons about using JDK1.4 vs. using JDK5.
Regards,
Amita
On 8/30/07, Kevin Williams [EMAIL PROTECTED] wrote:
This sounds good to me since programming model consistency is so very
important. I agree that partial index specification should *not* be
supported. I was concerned by your example:
Parameters
Parameter name=ID index=1/ -- rest of the attributes optional
Parameter name=LASTNAME / -- rest of the attributes optional
Parameter name=ADDRESS / -- rest of the attributes optional
/Parameters
But, i assume you meant
Parameters
Parameter name=ID index=1/ -- rest of the attributes optional
Parameter name=LASTNAME index=2/ -- rest of the
attributes optional
Parameter name=ADDRESS index=3/ -- rest of the attributes
optional
/Parameters
--Kevin
On 8/29/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is one of the use cases where user will get some benefit:-
USE CASE:
bigtable{col1, col2,col50}
SIMPLEST CLIENT CODE: WITH NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand(insert into bigtable values (?,
?,
?...50 times));
insertAdhoc.setParameter(ID, new Integer(6));
insertAdhoc.setParameter(LASTNAME, MyLastName);
insertAdhoc.setParameter(ADDRESS, MyLastAddress);
...
insertAdhoc.setParameter(Param50, Value50);
COMPARE WITH EXISTING WAY: WITHOUT NAMED PARAM SUPPORT
Command insertAdhoc = das.createCommand(insert into bigtable values (?,
?,
?...50 times));
insertAdhoc.setParameter(1, new Integer(6));
insertAdhoc.setParameter(2, MyLastName);
insertAdhoc.setParameter(3, MyLastAddress);
...
insertAdhoc.setParameter(50, Value50);
Summary of previous discussion and main intention of this JIRA is to
support
the below features:-
1) Add attribute Name to parameter for user convenience/readability
2) Support command.setParameter(name, value) for user
convenience/readability
3) Preserve existing ways of using parameters - e.g.
A
Continue supporting -
Table tableName=CUSTOMER
create sql=insert into customer values (?, ?, ?)
Parameters List=ID LASTNAME ADDRESS /Parameters
/create
/Table
But also support -
Table tableName=CUSTOMER
create sql=insert into customer values (?, ?, ?)
Parameters
Parameter name=ID index=1/ -- rest of the attributes
optional
Parameter name=LASTNAME / -- rest of the attributes optional
Parameter name=ADDRESS / -- rest of the attributes optional
/Parameters
/create
/Table
Note: if +ve index is specified in Parameter, it is used, else
auto-increment similar to A is used. As List is an ordered collection,
the
sequence appearing in the cofig file will be maintained. Partially
specifying indexes is not supported (i.e. give index for 2 out of 3
params
and leave one without it, is not supported)
B
Continue supporting -
cmd.setParameter(1, new Integer(1)); cmd.getParameter(1);
But also support -
cmd.setParameter(BOOKS.BOOK_ID, new Integer(1));
cmd.getParameter(BOOKS.BOOK_ID);
C
Continue supporting -
Command...
Parameter/
Parameter/
/Command
And
Command..No Params in Config, but directly
setParameter(idx/name,
value) in program
/Command
But also support
Command insertAdhoc = das.createCommand(insert into CUSTOMER values (?,
?,
?));
insertAdhoc.setParameter(ID, new Integer(6));
insertAdhoc.setParameter(LASTNAME, MyLastName);
insertAdhoc.setParameter(ADDRESS, MyLastAddress);
Note: Convention over config is followed, if Parameters are not defined
in
config, the sequence
should match the table columns [convention],else user should specify
params
on command in config and specify index attributes in them [config]
4) This JIRA code will benefit a lot by use of JDK5 generics, but as DAS
is
still at JDK1.4 level current code does not use generics.
5) Changes in config -
xsd:complexType name=Create
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name=Parameters
type=config:Parameters/
/xsd:sequence
xsd:attribute name=sql type=xsd:string/
/xsd:complexType
Similar for Update and Delete.
xsd:complexType name=Parameter
xsd:attribute name=name type=xsd:string/
xsd:attribute name=columnType type=xsd:string/
xsd:attribute name=direction type=xsd:string default=IN/
xsd:attribute name=index type=xsd:int/
/xsd:complexType
Re: [RDB DAS] Consistent use of Parameters in Config
for these case : ( Regards, Adriano Crestani [1]xsd:complexType name=Create xsd:attribute name=sql type=xsd:string/ xsd:attribute name=parameters type=xsd:string/ /xsd:complexType [2]xsd:complexType name=Create xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Parameter type=config:Parameter/ /xsd:sequence xsd:attribute name=sql type=xsd:string/ /xsd:complexType On 8/2/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: JPQL, Hibernate ,... have support for named parameters. Why is RDB DAS going in the other way? If there is a reason for switching off named parameters, please elaborate, else is it OK to go for JIRA-1462? Regards, Amita On 7/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: I went through [1] and [2], it talks about removing name attribute from Parameter and about generatedKeys. Also saw JIRA-528 on the way. But I could not get the exact rational behind removing Name from Parameter (It is definitely not required by JDBC for sure, but can have some aid in usage clarity) 1)One place in RDB DAS (here Name is not removed and can not be removed) BasicCustomerMappingWithCUD.xml ( CRUDWithChangeHistory.testDeleteAndCreate ()) Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd; Table tableName=CUSTOMER create sql=insert into customer values (?, ?, ?) parameters=ID LASTNAME ADDRESS/ update sql=update customer set lastname = ?, address = ? where ID = ? parameters=LASTNAME ADDRESS ID/ delete sql=delete from customer where ID = ? parameters=ID/ /Table /Config This is informative because we have create sql=insert into customer values (?, ?, ?) parameters=ID LASTNAME ADDRESS/ In the client code we will typically have DataObject customer = root.createDataObject(CUSTOMER); customer.setInt(ID, 720); customer.set(LASTNAME, foobar); customer.set(ADDRESS, asdfasdf); das.applyChanges(root); Here client has a chance to understand that he needs to set ID, LASTNAME, ADDRESS because the config states - parameters=ID LASTNAME ADDRESS and internally we will map names to idx when doing PreparedStatement.setParameter. For the matter of whether it is required to have parameters=ID LASTNAME ADDRESS , it is required. We can no say parameters=1 2 3 or X Y Z because during SDO to Parameter mapping (in ChangeOperation) we need the Name of parameter, so Name and Idx both are required. 2)Another place in RDB DAS (this is where Name is removed in JIRA-658) Command name=InsertCustomers SQL=insert into CUSTOMER values (?,?,?) kind=Insert Parameter direction=IN index=1 columnType= commonj.sdo.IntObject / Parameter direction=IN index=2 columnType= commonj.sdo.String/ Parameter direction=IN index=3 columnType= commonj.sdo.String/ /Command A typical client code will be, Command insert = das.getCommand(InsertCustomers); insert.setParameter(1, 1000); insert.setParameter(2, MYNAME); insert.setParameter(3, MYADDR); insert.execute(); In this example, nowhere the client has a way to know what 1000, MYNAME or MYADDRESS means. If this is a table with many columns and such many tables, how the client is going to set values using setParameter() with any comfort level, unless otherwise the he has a direct access to database and can know the names and order or columns in database table or if the insert syntax is used like insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) but in tables having large number of rows, it is likely that client will try to have short (insert) statements without column names. And this is what I felt was the issue of the user in http://www.mail-archive.com/[EMAIL PROTECTED]/msg19339.html, as he admitted that even though JDBC does not need Names, he needs it for the sake of clarity. So, as such, first thig I am just curious to know is, what were the advantages of JIRA-658? Also, not quite clear about Also, have you thought about multiple queries retrieving the same column,you would have to configure the parameter in multiple places. If there are 10 different Select Commands with 10 different Where clauses, we anyway need to set Parameters in 10 different places. I guess I am completely intepreting something wrong here, please help. Regards, Amita On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote: The named parameter support was removed from earlier versions of DAS, here is some previous discussion around the subject [1] See also tuscany-658. We might need to do further cleanup on the impl, if I understood correctly
Re: Having problem with null values in my DAS
Will you please share the config file and the data/table info here, so I can simulate the condition. When tried with a simple sample, it seems that - when any other column other that the one mentioned in DAS as PK has null value, DAS is producing correct result. So, your details will help. Also, will you please see if the query is including PK in the SELECT clause. Regards, Amita On 8/30/07, Chu, Wing (Exchange) [EMAIL PROTECTED] wrote: I am wondering if anyone came across this. I have a simple select A,B,C from TABLE1 where A=? I have no problem get the DataObject back when all the values are not null. However, if any one of the value is null. I would get an object but the values and the list is null. This seems not right to me. Is there a configuration that I miss? I am working with Oracle 10g Thanks, Wing *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] What's next for Tuscany DAS ?
I have attached patch for TUSCANY-961+ TUSCANY-986 combined in TUSCANY-961. One observation here - Generated code shows usage of deprecated method FactoryBase.getProperty(Type, int) and needs to be replaced by getLocalProperty(), any changes needed in xsdtojava generator in SDO? Any suggestions? Regards, Amita On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- 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: [DAS] Transaction support
Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: 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
Re: [DAS] Transaction support
less , but account2 is not $200+. So he lost $200 in network crash. This viloates data integrity. Note: To simulate network failure cuasing SQLException, in DAS code, when update command is issued for account2 a hardcoded SQLException is thrown. This code change is done just for testing purpose and will be reverted back. Regards, Amita On 8/15/07, haleh mahbod [EMAIL PROTECTED] wrote: Amita, Maybe I am not getting this. What is the user case scenario that you are trying to cover with your suggestion (I understand what you are suggesting to do, but not sure of use case)? In what case client needs what you are mentioning, beyond what is provided today? Thanks for the clarification. Haleh On 8/14/07, Adriano Crestani [EMAIL PROTECTED] wrote: ---if DAS exposes connection thru getConnection() ONLY when managedtx=false, it need to control cases when managedtx=true. So 2. will be needed. If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx loses its meaning and DAS can not control any transaction as client always have the control. I agree with you Amita, however the user will always have the control when it passes the a Connection to DAS on its creation no matter if the managedtx is true or not, because he will have a reference to the Connection he created. So, if the managedtx=true and the user passed the Connection to DAS, it will make no sense not to expose the Connection to the user, since he already has its reference. Regards, Adriano Crestani On 8/14/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: On 8/14/07, Adriano Crestani [EMAIL PROTECTED] wrote: Here is my opinion: 1- There are 2 ways for user to provide a Connection to DAS, create one and pass it to DAS on its creation or on ConnectionInfo. The first case is already giving the access to the Connection to the user. On the second, I think it's useful to provide access to it with getConnection(), since the user wouldn't be able to manage the transacions if he defines the managedtx=false. ---if DAS exposes connection thru getConnection() ONLY when managedtx=false, it need to control cases when managedtx=true. So 2. will be needed. If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx loses its meaning and DAS can not control any transaction as client always have the control. 2- Now, about start/endTransaction() methods, I agree with Luciano, it will look like DAS was specially designed for RDB when you define it on DAS class, maybe it could probably be added to rdb.DASImpl class and the user would have to cast it to rdb.DASImpl when creating a DAS instance using the factory. Anyway, I don't agree with adding these methods, once if being exposed the Connection with getConnection the user can commit or rollback whenever he wants, and control how many commands will be grouped as atomic change on rdb or not. 3- As we are already talking about DAS being heterogeneus and independent of implementations, as a interface should be, the classes on das package shouldn't be depedent of das.rdb package classes. But on patch from JIRA-1465 were added the methods add/remove/get/ResultDescriptor on Command class, however these methods are, as far as I know, only intended to be used with RDB DAS. So I think they are misplaced, maybe they should be placed on a Command implementation under das.rdb package. What do you 2 think? This can be a good start for DAS API-Impl separation work. We can discuss what all changes that need to happen in current DAS (Luciano already has some work in sandbox) to make a clean separation between API and Impl. e.g . DAS interface does not have an API for connecting to non-DBMS data stores, but it accepts java.sql.Connection indicating DAS from Interface level itself is tied to Database. Can we open another thread and list/discuss all the changes around this separation work? Regards, Adriano Crestani On 8/14/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just looked more at the code and found something more interesting - :) When there is no connectionInfo in DAS Config, managedtx defaults to true, so when connection is passed by user (as in TransactionTests), managedtx is true. So, with the current code case 4) can not occur (which is actually useful) 4)false from caller DAS does not issue commit/rollback, external caller manages TransactionTests - if you look closely, there is just one DAS.applyChanges(root) command which has 2 INSERT statements using same PK. So, 2nd INSERT gives JDBC Exception and DAS uses
Re: Example to define the ResultSet shape Definition for a join in DAS
Hi, DAS Config file does support ResultDescriptor and [2] test case mentioned by Luciano is quite descriptive. This functionality is there in the latest stable release. Recently there is JIRA-1465 fixed with which, Dynamically created Commands (the ones that are not in DAS Config file) also can make use of ResultDescriptor. This is fixed in the svn trunk but not part of release. Also, in order to get correct query results from DAS, it may be good to include the column Primary Keys of all tables involved in the Select clause. This is just a suggestion by looking at the query you have mentioned. Regards, Amita On 8/15/07, Chu, Wing (Exchange) [EMAIL PROTECTED] wrote: Would like an example if my query is a join between two tables? For example, Select a.dept_name, b.employee_name from dept a, emp b where a.id = b.dept_id (+) How do I define an Explicit ResultSet shape definition for the resultset from a join I'm working in Oracle. Thanks, Wing *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Relationship info using DBMS Metadata getCrossReference() - pros and cons?
(Prev mail thread:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg20770.html) More on this... Looks like, single table registry approach was taken to dump all rows fetcted from database without linking DataObjects, as there is no relationship information in DAS Config. So, from the above mail thread, as join between singer and song returns 3 rows, there were 3 singer DOs and 3 song DOs and it is user's responsibility to see that out of 3 singer DOs 2 are actually identical. So question here is...can DAS use DatabaseMetadata.getCrossReference() JDBC API to form relationship information when it is missing in DAS Config. To keep matter simple, DAS can take approach of using DAS Config relationship info as first priority and DatabaseMetadata.getCrossReference() as next priority. In case queries involve tables where for some relationship is defined in DAS Config and for some it is not, DAS can just stick to DAS Config. i.e. avoid mixing DAS Config provided relationship info and DBMS provided relationship info. Whatever is the approach (we can take mixed approach too, for that matter), it just needs to be documented clearly. DAS - from the basic usage so far, promotes less config and thus uses DBMS Metadata info for tables and columns when one is not available in DAS Config. So same can be extended for Relationships too. Are there any known issues around usage of DatabaseMetadata.getCrossReference()? Checked for Derby, MySQL so far and found no issues. Also, if some vendor do not have implementation for this method, we can detect exception/null/empty ResultSet returns and continue the way we are at present using SingleTableRegistry. Comments? Regards, Amita
Re: [DAS] Transaction support
-When connection is provider by caller(say container), there is no meaning of managedtx attribute, and it is better to let the caller handle the transactionality of the operations. So, when DAS is instantiated using external connection - mandate managedtx = false. Also, expose getConnection() from DAS to give a ref. of the connection (User already owns it, DAS is just providing ref.). DAS will not issue any commit/rollback -When connection is created internally, managedtx has a meaning. 1When false, DAS.getConnection() should be exposed and user should be allowed to handle transactions. DAS should not issue any commits/rollbacks 2When true, do not expose DAS.getConnection(). If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit /rollback per command). If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to manager group of commands as a sigle transaction).Here, DAS at the simplest can use a static FLAG set/unset using methods - void DAS.startTransaction(), //mark FLAG to set - void DAS.endTransaction(commit/rollback). //mark FLAG to reset endTransaction() will issue commit/rollback based on arg passed to it. For any exception condition DAS will issue rollback() on transaction and will reset the FLAG. Client needs to call start/endTransaction() for group of Commands. Also, here for timeout impelmentation, Java Timer can be used. Regards, Amita On 8/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, I think it can be useful to bunch commands, but I didn't get how you are planning to do it : ( What would be the parameter of method getTransaction? Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response
[DAS] Column Converter - why not to associate with ResultDescriptor?
With JIRA-1465, ResultDescriptor can be set dynamically for DAS Commands which are created with DAS.createCommand(). Further on this, will it be helpful to associate ColumnConverter with ResultDescriptor? So, when there is no Config File, user will have a choice to use ColumnConveter on-the-fly /Command basic from inside the dynamic ResultDescriptor. The scope of this converter will be per Command. Whereas, the ColumnConverter we define in Config File inTableColumn, has a scope of Table. When column conveter is available for a Command, it will be used and in its absence, the one available at Table/Column scope will be use and in its absence it will be Default/No converter as usual. This will have a benefit for clients, which need frequent use of column converter and have changing needs (based on say, Locale, TimeZone,). Suggestions? Regards, Amita
Re: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417)
JIRA-1353 provided the fix and JIRA-1417 may not be needed On 7/25/07, Ron Gavlin [EMAIL PROTECTED] wrote: Amita, Yes, I agree with this approach to solving the problem. Since Derby is a first-class DAS citizen, I confirm that it makes sense for it to have special code to ensure it works out-of-the-box with no special Config attribute. Thanks for persevering with this issue. Also, thanks in advance for your patch. Regards, - Ron --- Amita Vadhavkar [EMAIL PROTECTED] wrote: True, with the approach, DAS can use Metadata API and treat Derby specially (as Derby Embedded Driver API returns FALSE, set it to TRUE) 1) If provided in Config - it will be used, no Metadata API check 2) If not provided in Config - Metadata API check - In this for Derby ALWAYS SET TO TRUE, and for anything else, set based on API return value. In case of exception set to FALSE. 3) Also for existing test cases - default TRUE will be assumed as they run using Derby and will not fail 4) For PostgreSQL - this approach will work as Metadata API returns FALSE for JDBC 3 compliant driver 5) In case there is any driver used which is not JDBC 3 compliant and the API is absent, then it will again be caught as exception and value set to FALSE. Please see if there are any further places for modification in the above. Regards, Amita On 7/24/07, Ron Gavlin [EMAIL PROTECTED] wrote: Hi Amita, Since DAS has JDK 1.4 as a requirement and the JDBC 3.0 APIs are built into JDK 1.4, isn't it sufficient to interpret a JDBC 2.0 driver throwing a exception from supportsGetGeneratedKeys() as a false. Also, since the DAS is currently a pre-1.0 release, I don't think our solution needs to be driven by backwards-compatibility or whether test cases get broken or not. From my perspective, the default case (the absence of the attribute) should be driven by the JDBC driver's DatabaseMetadata.supportsGetGeneratedKeys() value. The useGetGeneratedKeys attribute could be explicitly set to true for cases like Derby where the driver's partial support for this feature is sufficient for the needs of the DAS. In the case of Oracle, they just started supporting getGeneratedKeys() in Oracle 10g R2. It is not supported in earlier versions of the database or drivers. So, using the DatabaseMetadata-driven approach, the DAS should be able to support all Oracle versions out of the box with no special config attribute. In the future, hopefully Derby will implement full getGeneratedKeys() support and thus would not require special configuration within the DAS. My two cents... - Ron - Original Message From: Amita Vadhavkar [EMAIL PROTECTED] To: tuscany-user@ws.apache.org; [EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 8:56:36 AM Subject: Re: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417) Hi, Below are some details about the solution for JIRA-1353. Please review the patch. http://issues.apache.org/jira/browse/DERBY-242 - indicates that for 10.1.1.0, DatabaseMetadata.supportsGetGeneratedKeys() returns false. Also, checked that for the current Maven Repo's Derby version (10.1.2.1) same is happening. DatabaseMetadata.supportsGetGeneratedKeys() is not available in JDBC 2.0. (We can catch exception if it is thrown in the supports...() , but we can not detect cases like above - Derby) So, using DatabaseMetadata.supportsGetGeneratedKeys() (when config attribute is not set) may not be reliable in all cases. To keep the fix simple and also not to break existing test cases (which assume default TRUE), the following is changed in patch 1) New Config attribute xsd:attribute name=useGetGeneratedKeys type=xsd:boolean default=true/ 2) Default to TRUE - so old test cases and old configs continue to work 3) Remove vendor name hardcoding logic to set flag useGetGeneratedKeys So, in effect, with this patch (JIRA-1353) user will get an option to pass FALSE, when it is sure that the dbms driver in use does not support this feature. Thus, instead of hardcoding vendor names (without driver versions), the responsibility is given to user to pass FALSE when needed. Have tested this fix on Derby, DB2, MySQL and PostgreSQL. Also, new testcases (6) added - CheckSupportGeneratedKeys example Config XML using the above attribute (say for PostgreSQL), the XML will look as below Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;; useGetGeneratedKeys=false /Config -- User
Re: [RDB DAS] Need to allow passing ResultDescriptor for dynamic Commands (Ref.JIRA-1355)
Hi Adriano, Just to get it clear, at present, result descriptor defn is xsd:complexType name=ResultDescriptor xsd:attribute name=columnName type=xsd:string/ xsd:attribute name=tableName type=xsd:string/ xsd:attribute name=schemaName type=xsd:string/ xsd:attribute name=columnType type=xsd:string/ /xsd:complexType So, you are suggesting to add a new attribute, xsd:attribute name=columnIdx type=xsd:int/ to this? Regards, Amita On 7/12/07, Adriano Crestani [EMAIL PROTECTED] wrote: Yes, Amita, I agree with you there must be a way to define the ResultDescriptor when the user create the command using createCommand method. But instead of define it in a sequence, it could be defined relating the ResultDescriptor with a column index. However, the problem the user came up on JIRA-1355 has nothing to do with the way the sql query is created, but with the non previously knowledge of what the query may return. For example, can you tell me what the follow sql return? select * from company I see two cases where the user cannot foreseen the company attributes retrieved on this query: 1 - the company attributes may change on future. 2 - defining the company attributes is not on his charge. On the first case, the user can manually redefine the company attributes on ResultDescriptor every time it changes. But on the second one, the user might not be able to know when it changes. The only way to overcome this problem is to leave it with JDBC metadata. Unfortunately, Oracle JDBC Driver does not provide all necessary metadata that DAS needs : ( Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, Recently there came up a requirement from user (ref. JIRA-1355), when the user was attempting DAS.createCommand(sql) in Oracle. As of today, in RDB DAS, user can specify ResultDescriptor using external Config File containing Commands. But there is no provision for user to pass ResultDescriptor for a Command, when it is created as above (dynamic - without Config File). As, for Oracle and some other databases, when database meta data is not sufficient, DAS requires user to supply ResultDescriptor as a substitute. For taking care of such situations, DAS needs to expose Command.set/getResultDescriptors(List ResultDescriptor). One rule to be adhered when using this API will be sequencing of ResultDescriptors in the input List.The sequence in the List ResultDescriptor has to be in sync with the sequence of parameters in sql. With this, I guess it will be a really useful and handy functionality, that RDB DAS needs to consider. Thoughts? Regards, Amita
Re: [VOTE] Release Tuscany Java DAS beta1 (RC3)
Downloaded src and bin destro and tried tests, samples, checked javadoc, readmes. Looks fine to me. +1 (non-binding) Regards, Amita On 7/30/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in RC1 and RC2 should now be fixed. The Release Candidate RC3 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/ Seems OK to me, here is my +1 -- 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: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417)
True, with the approach, DAS can use Metadata API and treat Derby specially (as Derby Embedded Driver API returns FALSE, set it to TRUE) 1) If provided in Config - it will be used, no Metadata API check 2) If not provided in Config - Metadata API check - In this for Derby ALWAYS SET TO TRUE, and for anything else, set based on API return value. In case of exception set to FALSE. 3) Also for existing test cases - default TRUE will be assumed as they run using Derby and will not fail 4) For PostgreSQL - this approach will work as Metadata API returns FALSE for JDBC 3 compliant driver 5) In case there is any driver used which is not JDBC 3 compliant and the API is absent, then it will again be caught as exception and value set to FALSE. Please see if there are any further places for modification in the above. Regards, Amita On 7/24/07, Ron Gavlin [EMAIL PROTECTED] wrote: Hi Amita, Since DAS has JDK 1.4 as a requirement and the JDBC 3.0 APIs are built into JDK 1.4, isn't it sufficient to interpret a JDBC 2.0 driver throwing a exception from supportsGetGeneratedKeys() as a false. Also, since the DAS is currently a pre-1.0 release, I don't think our solution needs to be driven by backwards-compatibility or whether test cases get broken or not. From my perspective, the default case (the absence of the attribute) should be driven by the JDBC driver's DatabaseMetadata.supportsGetGeneratedKeys() value. The useGetGeneratedKeys attribute could be explicitly set to true for cases like Derby where the driver's partial support for this feature is sufficient for the needs of the DAS. In the case of Oracle, they just started supporting getGeneratedKeys() in Oracle 10g R2. It is not supported in earlier versions of the database or drivers. So, using the DatabaseMetadata-driven approach, the DAS should be able to support all Oracle versions out of the box with no special config attribute. In the future, hopefully Derby will implement full getGeneratedKeys() support and thus would not require special configuration within the DAS. My two cents... - Ron - Original Message From: Amita Vadhavkar [EMAIL PROTECTED] To: tuscany-user@ws.apache.org; [EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 8:56:36 AM Subject: Re: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417) Hi, Below are some details about the solution for JIRA-1353. Please review the patch. http://issues.apache.org/jira/browse/DERBY-242 - indicates that for 10.1.1.0, DatabaseMetadata.supportsGetGeneratedKeys() returns false. Also, checked that for the current Maven Repo's Derby version (10.1.2.1) same is happening. DatabaseMetadata.supportsGetGeneratedKeys() is not available in JDBC 2.0. (We can catch exception if it is thrown in the supports...() , but we can not detect cases like above - Derby) So, using DatabaseMetadata.supportsGetGeneratedKeys() (when config attribute is not set) may not be reliable in all cases. To keep the fix simple and also not to break existing test cases (which assume default TRUE), the following is changed in patch 1) New Config attribute xsd:attribute name=useGetGeneratedKeys type=xsd:boolean default=true/ 2) Default to TRUE - so old test cases and old configs continue to work 3) Remove vendor name hardcoding logic to set flag useGetGeneratedKeys So, in effect, with this patch (JIRA-1353) user will get an option to pass FALSE, when it is sure that the dbms driver in use does not support this feature. Thus, instead of hardcoding vendor names (without driver versions), the responsibility is given to user to pass FALSE when needed. Have tested this fix on Derby, DB2, MySQL and PostgreSQL. Also, new testcases (6) added - CheckSupportGeneratedKeys example Config XML using the above attribute (say for PostgreSQL), the XML will look as below Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;; useGetGeneratedKeys=false /Config -- User will need to pass the Config during creation of DAS instance. DAS.FACTORY.createDAS(config, getConnection()) or DAS.FACTORY.createDAS(config) or DAS.FACTORY.createDAS(InputStream configStream) The value of the attrib can be true/false. And Driver may/may not support GeneratedKeys. Based on this, following situations can arrive- A Driver supports GeneratedKeys 1]Table is created with one column having GENERATED ALWAYS AS IDENTITY clause, Irrespective of value of useGetGeneratedKeys flag, insert command will succeed true flag value - insert.getGeneratedKey() will return key value false flag value - insert.getGeneratedKey() will throw RuntimeException - Could not obtain generated key! 2]Table is created with no column having GENERATED ALWAYS AS IDENTITY clause, Irrespective of value of useGetGeneratedKeys flag, insert command
Re: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field
Hi Folks, JIRA-1453 opened for this issue is perfectly fixing Blob and ByteArray. Clob and Array, seem to be the only remaining types where TypeHelper.getType(commonj.sdo,...) returns null. Same approach as JIRA-1453 can work the Clob , but for Array? Any hints? Can the same JIRA be used or new JIRA be opened, so this issue does not remain half complete? Regards, Amita On 7/19/07, Kevin Williams [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Kevin Williams [EMAIL PROTECTED] Date: Jul 18, 2007 1:33 PM Subject: Re: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field To: tuscany-user@ws.apache.org, [EMAIL PROTECTED] Hello Li Taojian, You have uncovered a bug and also found a good fix. It would be very helpful if you could open a JIRA for this bug and also submit your fix as a patch. You can find instruction for doing this here: http://incubator.apache.org/tuscany/issue-tracking.html It would be even better if you could submit an addition to the DAS testuite to verify your fix. Thanks for your interest in the DAS. --Kevin On 7/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All , I modified the ByteArry and BLOB to Bytes in the ResultSetTypeMap.java , and then I could run a sample of reading the BLOB field , I test the sample on Mysql 5.0 , It could run correctly . Maybe this is a bug . ResultSetTypeMap.java case Types.BINARY: case Types.VARBINARY: case Types.LONGVARBINARY: return helper.getType(commonj.sdo, Bytes); // before is return helper.getType(commonj.sdo, ByteArray); case Types.BLOB: return helper.getType(commonj.sdo, Bytes); // before is return helper.getType(commonj.sdo, Blob); -邮件原件- 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 发送时间: 2007年7月18日 16:54 收件人: tuscany-user@ws.apache.org 主题: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field Hi All , I need the DAS to support reading and write the BLOB field , but TypeHelper.getType(commonj.sdo, Blob) is return null , Could you give me some tips to implement the function or fix out the bugs ? Or How could I implement the function immediately ? Li Taojian . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] XQuery-DAS
Hi, Yes, Saxon was suggested by Ant also before and it has saxon-b as freeware. Anybody please any comment on any licensing restrictions? Also I was just giving a try to DB2 Express XQuery support. There are a couple of others listed in June 15 mail, in this same thread. Saxon will be a good choice from XQJ compliance point too. (I will be able to upload a patch in 1-2 days time on the top of what is there in https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/ with some documentation to continue design discussion) Regards, Amita On 7/13/07, Doug Tidwell [EMAIL PROTECTED] wrote: Gang, how is XPath support implemented today? I've looked at the code briefly in the past, but couldn't make sense of it. I was hoping that XPath support came from the Xalan jar files. If that were true, it would be a SMOP to replace the Xalan XPath libraries with the Saxon libraries. Saxon supports XSLT 2.0, XPath 2.0 and XQuery. That's a straightforward approach to leveraging someone else's excellent work, although I don't know if Saxon's license would be compatible. Anyway, if somebody knows how XPath is implemented now, that would be a start towards figuring out how to plug in an XQuery engine. Cheers, -Doug
Re: Does DAS could support the blob field read and write ?
Hi All,
In an attempt to see how to ensure support from DAS to Blob, Clob etc. I
tried
a MySQL table with Blob column having some rows and tried to access it using
DAS. It could not go through and on the way of debugging - I finally wrote
the below
code (part from
org.apache.tuscany.das.rdb.graphbuilder.schema.ResultSetTypeMap),
to see what is supported and what is not.
---
public class TestSupportedTypes {
//picked from
org.apache.tuscany.das.rdb.graphbuilder.schema.ResultSetTypeMap
public static void main(String[] args){
TypeHelper helper = TypeHelper.INSTANCE;
SDOPackage.eINSTANCE.eClass();//what is this for
if(helper.getType(commonj.sdo, String) == null){
System.out.println(String Not supported!);
}
if(helper.getType(commonj.sdo, Decimal) == null){
System.out.println(Decimal Not supported!);
}
if(helper.getType(commonj.sdo, Boolean) == null){
System.out.println(Boolean Not supported!);
}
if(helper.getType(commonj.sdo, boolean) == null){
System.out.println(boolean Not supported!);
}
if(helper.getType(commonj.sdo, IntObject) == null){
System.out.println(IntObject Not supported!);
}
if(helper.getType(commonj.sdo, Int) == null){
System.out.println(Int Not supported!);
}
if(helper.getType(commonj.sdo, Long) == null){
System.out.println(Long Not supported!);
}
if(helper.getType(commonj.sdo, long) == null){
System.out.println(long Not supported!);
}
if(helper.getType(commonj.sdo, Float) == null){
System.out.println(Float Not supported!);
}
if(helper.getType(commonj.sdo, float) == null){
System.out.println(float Not supported!);
}
if(helper.getType(commonj.sdo, Double) == null){
System.out.println(Double Not supported!);
}
if(helper.getType(commonj.sdo, double) == null){
System.out.println(double Not supported!);
}
if(helper.getType(commonj.sdo, ByteArray) == null){
System.out.println(ByteArray Not supported!);
}
if(helper.getType(commonj.sdo, Date) == null){
System.out.println(Date Not supported!);
}
if(helper.getType(commonj.sdo, Clob) == null){
System.out.println(Clob Not supported!);
}
if(helper.getType(commonj.sdo, Blob) == null){
System.out.println(Blob Not supported!);
}
if(helper.getType(commonj.sdo, Array) == null){
System.out.println(Array Not supported!);
}
if(helper.getType(commonj.sdo, Object) == null){
System.out.println(Object Not supported!);
}
}
}
The result is :--
boolean Not supported!
long Not supported!
float Not supported!
double Not supported!
ByteArray Not supported!
Clob Not supported!
Blob Not supported!
Array Not supported!
Thus for all the above, in RDB DAS, getEDataType() returns null and then
finally gets a
NPE in GraphBuilderMetaData,createDynamicTypes() , when calling
SDOUtil.createProperty(), due to this null commonj.sdo.Type.
Please let me know if I am doing something totally wrong here. And what is
the way
to make RDB DAS work for the above Types.
Regards,
Amita
On 7/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi,
There is none at present, am giving it a try, will give you some update in
couple of hrs.
Regards,
Amita
On 7/13/07, litaojian [EMAIL PROTECTED] wrote:
Hi Amita ,
Thanks , but where is the sample that I could find ?
litaojian
2007-07-13
发件人： Amita Vadhavkar
发送时间： 2007-07-13 17:08:11
收件人： tuscany-user@ws.apache.org
抄送：
主题： Re: Does DAS could support the blob field read and write ?
Hi,
DAS does show support for Blob. I am trying a small sample with MySQL
-DAS
to verify
the same. There is also a DefaultConverter provided in DAS Impl which
seems
to
be there for handling Blobs.
Thanks,
Amita
On 7/13/07, litaojian [EMAIL PROTECTED] wrote:
Hi All ,
I need to read or write the image data from database blob
field ,
Does the DAS support it ? Is there any solution for this problem ?
Best regards ,
litaojian
2007-07-13
Re: Does DAS could support the blob field read and write ?
Hi, DAS does show support for Blob. I am trying a small sample with MySQL -DAS to verify the same. There is also a DefaultConverter provided in DAS Impl which seems to be there for handling Blobs. Thanks, Amita On 7/13/07, litaojian [EMAIL PROTECTED] wrote: Hi All , I need to read or write the image data from database blob field , Does the DAS support it ? Is there any solution for this problem ? Best regards , litaojian 2007-07-13
Re: [DAS] Transaction support
Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita
[RDB DAS] Consistent use of Parameters in Config
Hi, A few days ago there was a user question about passing name in Parameter:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg19339.html When checking how Parameters are used in Config, came across the following points. There is a difference in Config (SDO) generated Parameter and org.apache.tuscany.das.rdb.impl.ParameterImpl. The one from Config has only ColumnType, Direction and Index whereas in impl, it has in addition Name and some other attributes. Not having Name in Config generated version does not cause any problems anywhere as JDBC PreparedStatement setParameter() requires Index and not Name. But to give a consistent user experience, it can be good to add Name (Optional). Also, when supporting Create, Update, Delete in RDB DAS Config, the attribute parameters is String, which is internally interpreted in Index and Name. This misses the ColumnType and Direction.Direction can be safely assumed as IN for these statements. Also, not supplying ColumnType again causes no issues, as DAS tries to get it from database metadata or using SDO standards. Still here again, if user can specify ColumnType (optional), it will give a consistent user experiece. So, question here, for the sake of consistency and uniform user experience, is it a good idea to replace [1] with [2]? (Same for Update and Delete) [1]xsd:complexType name=Create xsd:attribute name=sql type=xsd:string/ xsd:attribute name=parameters type=xsd:string/ /xsd:complexType [2]xsd:complexType name=Create xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Parameter type=config:Parameter/ /xsd:sequence xsd:attribute name=sql type=xsd:string/ /xsd:complexType Regards, Amita
Re: [VOTE] Release Tuscany Java DAS beta1 (RC2)
Hi, Pease visit JIRA-1419 to find the summary of changes done to different readmes based on all the comments obtained so far. It will be very helpful if these can be reviewed from JIRA attachments and further comments given there, so that the finalilized readmes can be used in RC. Regards, Amita On 7/10/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks, some comments inline. On 7/10/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Here are my observations on this RC. 1) The source builds successfully from a clean maven repo - Notice, Disclaimer and License files missing from source 'rdb' module. These files are in the jar meta-inf. 2) Trying the samples a) I see that the source has two additional directories 'testing' and 'dbconfig' which are not there in binary distro. Maybe we must make it clear that this applies only if one is using the source distro. What's your suggestion here ? Also, for clarification, dbConfig is the utility embedded on some DAS sample apps (web-inf\lib) to create the canned databases. The testing\tomcat project is what we have as DAS Integration test using Tomcat. b) RDB DAS Sample (companyweb) - should we change that title to RDB DAS CompanyWeb Sample. - Readme - the section Running from Tomcat configured by the build has information that cannot be related to with the binary distro. There is a mention of 'testing' module within samples and also the paths seem to be related to the svn structure. (java/das/samples/testing/tomcat/readme.htm) - the section Deploying the CompanyWeb WAR into a Tomcat you configure yourself talks about a 'sample distribution' - and I don't think we have one. Do we ? No, it's now under the binary distro. - furtheron there is mention about copying derby.jar but I see it in the war as well. - and then in Install the canned Derby database to Tomcat, i really cannot figure out where datatest directory is. This was noted by Amita too, this step is obsolet. - I really think this readme needs a overhaul or I am grossly missing something. c) RDB DAS Customer Sample runs clean as mentioned in the readme - Section Running from Tomcat configured by the build may need to mention that it applies only to src distro - there is a mention of 'sample distribution' which we don't have - about copying derby.jar to tomcat lib I guess its common/lib for tomcat 5.x and just 'lib' for tomcat 6.x - I was able to deploy to the war to tomcat, I copied over the derby-10.1.2.1.jar that I found in the war to the lib directory and was able to run the sample successfully. I tried the adhoc queries and they seemed to work fine for me. 3) License and Notice : I find licenses are in place. In the notice there is mention of using software developed by OSOA. Did not quite find anything from osoa. SDO Spec jar is based on the OSOA license. I might need to add the jar file as the line below. License for the Service Data Objects JavaDoc and Interface Definition files. (sdo-api-r2.0.1-1.0-incubator-M2.jar) So, overall its about the READMEs for the samples that need some fixing. Even there the customer and ajax samples can be worked out with the current READMEs - with the Ajax sample really give a feel that DAS works. So I really cannot see a blocker with this. Here is my +1. Thanks. - Venkat On 7/10/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in RC1 should now be fixed. The Release Candidate RC2 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc2/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc2/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc2/das-beta1-rc2-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/ Seems OK to me, here is my +1 -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: New version solves Feature 'ConnectionInfo' not found problem
Hi Enric, I just came across some links from PostgreSQL, relevant to the exception mentioned earlier - Exception in thread main *java.lang.RuntimeException*: * org.postgresql.util.PSQLException*: Returning autogenerated keys is not supported. [1]http://gborg.postgresql.org/project/pgjdbc/bugs/bugupdate.php?984 [2]http://archives.postgresql.org/pgsql-jdbc/2007-02/msg00074.php Seems from [2] that, there is some progress on that front. Regards, Amita On 7/9/07, Enric Staromiejski Torregrosa [EMAIL PROTECTED] wrote: I'll be absent for three or four days, but i'll try it when i'll be back. Thanks for the effort. Enric 2007/7/9, Luciano Resende [EMAIL PROTECTED]: Hi Enric I was chatting with Amita about this problem, and she found that this might be a problem on our code, I have applied a fix for the issue to trunk under revision #554549. Please let us know if that helps. On 7/6/07, Enric Staromiejski Torregrosa [EMAIL PROTECTED] wrote: BTW, did you solve this problem with Oracle? We optionally are allowed to use Oracle instead of PostgreSQL... Regards 2007/7/5, Luciano Resende [EMAIL PROTECTED]: This might be the same issue we have with the Oracle JDBC drive, could you try specifying the resultset shape definition in the das config as described in this user's guide link [1] and see if this make you go further ? [1] http://cwiki.apache.org/confluence/display/TUSCANY/Explicit+ResultSet+shape+definition On 7/5/07, Enric Staromiejski Torregrosa [EMAIL PROTECTED] wrote: Luciano, when configuring the Customer sample against mysql everything goes fine. The PostgreSQL connection and table creation also works fine, but the SELECT sentence reports back the following exception: Exception in thread main *java.lang.RuntimeException*: * org.postgresql.util.PSQLException*: Returning autogenerated keys is not supported. at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery(* ReadCommandImpl.java:65*) at org.apache.tuscany.samples.das.customer.CustomerClient.getCustomers(* CustomerClient.java:168*) at org.apache.tuscany.samples.das.customer.CustomerClient.main(* CustomerClient.java:131*) Caused by: *org.postgresql.util.PSQLException*: Returning autogenerated keys is not supported. at org.postgresql.jdbc3.AbstractJdbc3Connection.prepareStatement(* AbstractJdbc3Connection.java:352*) at org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement (* ConnectionImpl.java:97*) at org.apache.tuscany.das.rdb.impl.Statement.getPreparedStatement (* Statement.java:198*) at org.apache.tuscany.das.rdb.impl.Statement.executeQuery(* Statement.java:52 *) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery(* ReadCommandImpl.java:61*) Regards, Enric 2007/7/5, Luciano Resende [EMAIL PROTECTED]: Yes, the typical one should work. I particularly haven't tried with PostgreSQL, but I don't anticipate any issues, you might have to manually create the databases, or maybe tweak the database generation classes under o.a.t.samples.das.databaseSetup. Once you make it working, and if you want, you could share your updates so we can make it easier for others that want to use the sample with PostgreSQL. I'll be more then happy to review and submit it to trunk. On 7/5/07, Enric Staromiejski Torregrosa [EMAIL PROTECTED] wrote: by the way, the database engine i'll have to use is PostgreSQL 8.1, but the configuration has to be a typicall one, isn't it, something like: ConnectionInfo ConnectionProperties driverClass=org.postgresql.Driver databaseURL=jdbc:postgresql:databasename user=enric password=mypassword loginTimeout=60 /ConnectionProperties /ConnectionInfo 2007/7/5, Enric Staromiejski Torregrosa [EMAIL PROTECTED] : i imagined...but even if i get driverClass accepted, Feature user is not i'm really impressed and happy with your presence and collaboration...it's greatly encouraging to a newby ;) Enric 2007/7/5, Luciano Resende [EMAIL PROTECTED]: The XSD is available here [1]. I would need to give it a try using MySQL, but giving it a quick look on the DAS config files, looks like connection info other then the derby one hasn't been updated recently, and you would need to make some small modifications to it. ConnectionInfo ConnectionProperties
Re: Why the rootDataObject can't save to a xml file ?
Hi,
I have only a limited understanding about SDO and EMF, but what it looks
like is -
List custList = root.getList(CUSTOMER);
for(int i=0; icustList.size(); i++){
System.out.println(XMLHelper.INSTANCE.save
((DataObject)custList.get(i), whatever, myname));
}
will give you details like
?xml version=1.0 encoding=ASCII?
whatever:myname xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:whatever=whatever xsi:type=das:CUSTOMER
ID=1 LASTNAME=John ADDRESS=USA/
?xml version=1.0 encoding=ASCII?
whatever:myname xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xmlns:whatever=whatever xsi:type=das:CUSTOMER
ID=2 LASTNAME=Amita ADDRESS=INDIA/
?xml version=1.0 encoding=ASCII?
And in the tuscany-sdo side, when the save() happens, it works on
XMLResource which
contains the elements (in your case , it is a list of {DataGraphRoot and all
CUSTOMERS}),
and when EMF prints it to the writer, it writes as href, where as when the
list contains
individual CUSTOMER as above, when writing it, EMF explodes the complete
element.
Regards,
Amita
On 7/4/07, litaojian [EMAIL PROTECTED] wrote:
Hi All ,
I write sample to test the das , when I get a root DataObject from
a DAS-RDB command ,
I use the follow code to output a xml string of the root DataObject .
String uri = companyDO.getType().getURI();
String typeName = companyDO.getType().getName();
System.out.println(XMLHelper.INSTANCE.save(root, commonj.sdo,
dataObject));
but the output is
das:COMPANY xmlns:das=http:///org.apache.tuscany.das.rdb/das; href=
root.xml#//
This result is not as my expected .
I need the result as this
?xml version=1.0 encoding=ASCII?
das:COMPANY xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:das=http:///org.apache.tuscany.das.rdb/das;
xsi:type=das:DataGraphRoot
COMPANY ID=1 NAME=IBM EOTMID=88/
COMPANY ID=2 NAME=HP EOTMID=99/
/das:COMPANY
Response expected.
litaojian
2007-07-04
Re: [SDO Java] 1.0 Release Content Review
Hi, I am trying to go through details of JIRA 1317 and will get back here with any questions, doubts. Thanks, Amita On 6/15/07, kelvin goodson [EMAIL PROTECTED] wrote: The IRC chat to review the SDO release content didn't work out (I'd be interested in any feedback why that was), so here's a review of the discussions that have gone on recently on the lists. The discussion thread [4] and othere posts came up with for features that are candidates for 1.0, but don't have volunteers to implement Steffen and Bert's Databinding, dataobject - UI Component [1] Daniel's XML load options [2] Daniel's request to support Evolution of a specific SDO structure over time supported by Ron [3] Christian's request for facet access and validation (part of the release content discussion thread) [4] -- a multipart request that could be split into smaller chunks David Adcox's request for handling multiple namespaces in code generation (discussed in [4]) - TUSCANY-1223 is done, but TUSCANY-303 would be good Steffen: Typesafe collections in the generator -- again in [4] It would be great to get some of these things in, but I feel sure that my time will be easily mopped up by the things I plan to do. Are there any volunteers for any of these things? Things I have on my todo list (some of which I have started) - reorganisation of the build to create release distributions in line with the SCA release format - review and improvement of the samples and implementation of an alternative simple approach to running the samples that does not involve running a maven build - review and improvement of the website documentation (all welcome to pitch in with comments and contributions here) - get the generator metadata creation and initialization story in order [5] - TypeConversionTestCase fails for JDK 1.4.2 [6] - Manifest version number in Java SDO Impl and Tools jars [7] - Interface2JavaGenerator.java is not compatible with JDK 1.4 [8] Regards, Kelvin. [1] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01079.html [2] https://issues.apache.org/jira/browse/TUSCANY-1317 [3] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01000.html [4] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00977.html [5] https://issues.apache.org/jira/browse/TUSCANY-1143 [6] https://issues.apache.org/jira/browse/TUSCANY-1122 [7] https://issues.apache.org/jira/browse/TUSCANY-1284 [8] https://issues.apache.org/jira/browse/TUSCANY-257
Re: [DAS] Status of DAS Release
Small update, tried to build and test with empty repos and it went through with no issues. Regards, Amita On 6/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Things tested to be working - all UT as part of mvn build all samples in different browsers. Apart from das\distribution\binary\pom.xml - change and documentation changes in JIRA 1335, I have a doubt in logging mechanism in web samples. In DBConfig utility , the code uses Logger.getLogger(className) - to get logger from log4j. Whereas in all RDB DAS code, it is LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS util. In this, the level is OFF - hardcoded in the code. So, when the log4j.properties file is used in tomcat to switch on logging, the logging works for DBConfig (as it is using direct log4j), but logging does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB DAS jar. Is this the desired behavior? Will there be any need to switch on logging in web samples for RDB DAS code and how to do it without touching tuscany-das-rdb-1.0-incubating.jar? Regards, Amita On 6/11/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, When tried mvn -Pdistribution on das:- das\distribution\binary\pom.xml - does not list ajax web sample under dependency and thus does not package same As now, non-committer does not have access to edit wiki, I have created JIRA-TUSCANY-1335 for all the pending updates for DAS I was doing. Please see how these can be completed using attached zipped files. Architecture Guide - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+architecture+guide images to upload - ClassDiag.jpg, rdbDAS.gif User Guide - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide Under Samples(See Capabilities in use) Put links for:- Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm J2SE Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm Advanced Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm Development Guide - DAS_Java_Development_Guide.txt - need to add to wiki need to checkin under https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/src/main/release/RELEASE NOTES RELEASE_NOTES.txt About to complete CHANGES.txt , will add by eod to JIRA 1335.. Regards, Amita On 6/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: I went through all das samples and they seem to be working fine on Windows XP Home Edition SP 2 environment. I also corrected some links on readmes that were pointing to old tuscany website. I ran the rat on java/das directory and added Apache Licence header to files that were missing it. Regards, Adriano Crestani On 6/8/07, Luciano Resende [EMAIL PROTECTED] wrote: First of all, let me thank you all for helping on this release. Recently there has been a lot of progress, and things are looking good from the list of issues we had listed in the wiki [1]. The remaining documentation tasks could probably go in parallel with the release candidates. So, we should start thinking about creating a branch for the next release sometime soon, probably over the weekend or Monday and then start publishing release candidates from that. Also, I think we should look into the following items before we create the first RC : - run rat and make the results available - review the contents of license, readme, release_notes, changes, etc - review javadoc - make sure samples readme are updated and correct and the samples are working ok on different environments I'd also like to suggest two other things : - Name the release beta1, to be aligned with the beta1 release of SDO. - Any blocking issue to be tracked as blocking JIRA and directly assigned to beta1 release. Does this sound ok to everyone? Any Thoughts ? [1] http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+Beta1+Release -- 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: [DAS] Status of DAS Release
Things tested to be working - all UT as part of mvn build all samples in different browsers. Apart from das\distribution\binary\pom.xml - change and documentation changes in JIRA 1335, I have a doubt in logging mechanism in web samples. In DBConfig utility , the code uses Logger.getLogger(className) - to get logger from log4j. Whereas in all RDB DAS code, it is LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS util. In this, the level is OFF - hardcoded in the code. So, when the log4j.properties file is used in tomcat to switch on logging, the logging works for DBConfig (as it is using direct log4j), but logging does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB DAS jar. Is this the desired behavior? Will there be any need to switch on logging in web samples for RDB DAS code and how to do it without touching tuscany-das-rdb-1.0-incubating.jar? Regards, Amita On 6/11/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, When tried mvn -Pdistribution on das:- das\distribution\binary\pom.xml - does not list ajax web sample under dependency and thus does not package same As now, non-committer does not have access to edit wiki, I have created JIRA-TUSCANY-1335 for all the pending updates for DAS I was doing. Please see how these can be completed using attached zipped files. Architecture Guide - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+architecture+guide images to upload - ClassDiag.jpg, rdbDAS.gif User Guide - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide Under Samples(See Capabilities in use) Put links for:- Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm J2SE Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm Advanced Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm Development Guide - DAS_Java_Development_Guide.txt - need to add to wiki need to checkin under https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/src/main/release/RELEASE NOTES RELEASE_NOTES.txt About to complete CHANGES.txt , will add by eod to JIRA 1335.. Regards, Amita On 6/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: I went through all das samples and they seem to be working fine on Windows XP Home Edition SP 2 environment. I also corrected some links on readmes that were pointing to old tuscany website. I ran the rat on java/das directory and added Apache Licence header to files that were missing it. Regards, Adriano Crestani On 6/8/07, Luciano Resende [EMAIL PROTECTED] wrote: First of all, let me thank you all for helping on this release. Recently there has been a lot of progress, and things are looking good from the list of issues we had listed in the wiki [1]. The remaining documentation tasks could probably go in parallel with the release candidates. So, we should start thinking about creating a branch for the next release sometime soon, probably over the weekend or Monday and then start publishing release candidates from that. Also, I think we should look into the following items before we create the first RC : - run rat and make the results available - review the contents of license, readme, release_notes, changes, etc - review javadoc - make sure samples readme are updated and correct and the samples are working ok on different environments I'd also like to suggest two other things : - Name the release beta1, to be aligned with the beta1 release of SDO. - Any blocking issue to be tracked as blocking JIRA and directly assigned to beta1 release. Does this sound ok to everyone? Any Thoughts ? [1] http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+Beta1+Release -- 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: DAS M3 Release
Hi Haleh, I have modified http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Releases on similar lines to SCA. Please take a look and change/give comment wherever required. The latest release links are non-working right now, will need to update with the actual links when release is ready. After review, we can scrap the old content at the bottom of this page. Regards, Amita On 6/6/07, haleh mahbod [EMAIL PROTECTED] wrote: A few comments on RDB DAS Releases page. - It would be good to put the latest release first so that reader does not have too scroll down to find the latest release. - Can we follow the same style as other subprojects. Please take a look at SCA Download page for an example. I can help with this if others are OK. On 6/4/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Some more update, -mvn test on DAS is not running all tests, but only DBInitializerTestCase? -http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases - added new para for beta1, please review, so M3 para can deleted if OK - Revised Starting with DAS, please give comments Regards, Amita On 5/28/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi , FAQs in place, please check and give comments/add to it http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Regards, Amita On 5/23/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, Please take a look at the section Ongoing work items on page http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release and whatever is marked under review, please review and give your comments. This will help a lot in doing any necessary modifications to the DAS part of site. Also, I am gathering DAS questions discussed on ML and forming a FAQ, some archived messages are listed in the same section at the bottom. Please forward any FAQs you would like to include. Regards, Amita (Note: For memory analysis JIRA 1295 is added and patch is submitted, currently under review.) On 5/21/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, It is still work-in-progress. Main changes I did are 1) use simple connection pool on Test Cases framework 2) use finalize() in RDB DAS code 3) Do cleanup (removing references) as needed 4) Decouple DatabaseSetup and DasTest - do not share connections With this, there is some success (i.e. I modified a few cases with these changes effective and the multi-schema are running with no out of memory , I repeated the same testcases multiple times to increase number of test cases) Now, I am trying the change on all test cases and will create a new JIRA with patch for the changes. This is not eliminating the memory leak 100% ,but reducing it. Will respond to this mail with the new JIRA number. Regards, Amita On 5/19/07, Adriano Crestani [EMAIL PROTECTED] wrote: Amita, did you solve the JIRA 952 memory leak problem? Except JIRA 800 that luciano is going to commit, is there any other new feature or bug to be implemented for this release? Adriano Crestani On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the initial part of TUSCANY-863 under revision 538267.** On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, Points I gathered so far, we can sort out today. Will check more TODOs: 1) close JIRA-800, 863 2) remove JIRA-952 ? please see my last mail for memory leak, it still can happen with code without JIRA-952. It looks like it has to do with how our UT framework is setup.But so far I have not pin pointed the problem. So what path to follow for this JIRA? I will try more and find exact cause and resolution. 3) check all files license info (Adriano did this before, so just for any new code after that, we might need to do this.) 4) update http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release with closed/removed JIRAs 5) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS [javadoc] - give link *Guides:- -Architecture Guide - should be on Tuscany Home Page and not DAS -Developer Guide - complete - how is working on it? (Some content from http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp can be used and completed here) Some content for htmlunit - http://www.mail-archive.com/[EMAIL PROTECTED]/msg06053.html -User Guide - Advanced Web Sample - add link to this after JIRA-863
Re: DAS M3 Release
Some more update, -mvn test on DAS is not running all tests, but only DBInitializerTestCase? -http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases - added new para for beta1, please review, so M3 para can deleted if OK - Revised Starting with DAS, please give comments Regards, Amita On 5/28/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi , FAQs in place, please check and give comments/add to it http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Regards, Amita On 5/23/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, Please take a look at the section Ongoing work items on page http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release and whatever is marked under review, please review and give your comments. This will help a lot in doing any necessary modifications to the DAS part of site. Also, I am gathering DAS questions discussed on ML and forming a FAQ, some archived messages are listed in the same section at the bottom. Please forward any FAQs you would like to include. Regards, Amita (Note: For memory analysis JIRA 1295 is added and patch is submitted, currently under review.) On 5/21/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, It is still work-in-progress. Main changes I did are 1) use simple connection pool on Test Cases framework 2) use finalize() in RDB DAS code 3) Do cleanup (removing references) as needed 4) Decouple DatabaseSetup and DasTest - do not share connections With this, there is some success (i.e. I modified a few cases with these changes effective and the multi-schema are running with no out of memory , I repeated the same testcases multiple times to increase number of test cases) Now, I am trying the change on all test cases and will create a new JIRA with patch for the changes. This is not eliminating the memory leak 100% ,but reducing it. Will respond to this mail with the new JIRA number. Regards, Amita On 5/19/07, Adriano Crestani [EMAIL PROTECTED] wrote: Amita, did you solve the JIRA 952 memory leak problem? Except JIRA 800 that luciano is going to commit, is there any other new feature or bug to be implemented for this release? Adriano Crestani On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the initial part of TUSCANY-863 under revision 538267.** On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, Points I gathered so far, we can sort out today. Will check more TODOs: 1) close JIRA-800, 863 2) remove JIRA-952 ? please see my last mail for memory leak, it still can happen with code without JIRA-952. It looks like it has to do with how our UT framework is setup.But so far I have not pin pointed the problem. So what path to follow for this JIRA? I will try more and find exact cause and resolution. 3) check all files license info (Adriano did this before, so just for any new code after that, we might need to do this.) 4) update http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release with closed/removed JIRAs 5) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS [javadoc] - give link *Guides:- -Architecture Guide - should be on Tuscany Home Page and not DAS -Developer Guide - complete - how is working on it? (Some content from http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp can be used and completed here) Some content for htmlunit - http://www.mail-archive.com/[EMAIL PROTECTED]/msg06053.html -User Guide - Advanced Web Sample - add link to this after JIRA-863, 800 are commited , dbsetuputility - as its a handy tool for users too -What's new? - list new features in this release -Downloads - add links after 1st RC - [New]Useful Links - http://incubator.apache.org/tuscany/RDB_DAS_white_paper_v-0.2.pdf(for outdated info - how to update?)http://issues.apache.org/jira/browse/TUSCANY-594 - TBD http://java.sys-con.com/read/260053.htm (for outdated info - how to update?) 6) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS 7) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases Make this page in sync with what is going out in M3 8) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Can add below list:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg04822.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16300.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16711.html http
Re: DAS M3 Release - Documentation
Hi Haleh, Thank you for the comments. I am working on it and will put the updated content in 1-2 days. Also, I am working on Java RDB DAS ArchitectureGuide. It is still a word doc and Design Details section not yet complete. I am just attaching it here for the first look. It will be helpful to get everybody's perspective about what should/should not be there , before putting under wiki. I am checking SCA Architecture Guide too. Regards, Amita On 5/30/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Amita, Thanks for your attempt to share more about DAS on the wiki. This is useful. I looked at [1] and left comments in red if I could not figure out something. It looks like that this sample is already in SVN. Does it make sense to link to SVN from the doc instead of repeating each line of code. Then the 'getting started with DAS' guide can be focused on explaining what are the key setup pieces in the sample and what the purpose for each step is? Just a thought.. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Starting+with+DAS On 5/29/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have recently added FAQs and also a couple of new sections in http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS. It will be helpful to get some feedback to make it better. Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DAS M3 Release - Documentation
Hi, I have recently added FAQs and also a couple of new sections in http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS. It will be helpful to get some feedback to make it better. Regards, Amita
Re: DAS M3 Release
Hi , FAQs in place, please check and give comments/add to it http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Regards, Amita On 5/23/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, Please take a look at the section Ongoing work items on page http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release and whatever is marked under review, please review and give your comments. This will help a lot in doing any necessary modifications to the DAS part of site. Also, I am gathering DAS questions discussed on ML and forming a FAQ, some archived messages are listed in the same section at the bottom. Please forward any FAQs you would like to include. Regards, Amita (Note: For memory analysis JIRA 1295 is added and patch is submitted, currently under review.) On 5/21/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, It is still work-in-progress. Main changes I did are 1) use simple connection pool on Test Cases framework 2) use finalize() in RDB DAS code 3) Do cleanup (removing references) as needed 4) Decouple DatabaseSetup and DasTest - do not share connections With this, there is some success (i.e. I modified a few cases with these changes effective and the multi-schema are running with no out of memory , I repeated the same testcases multiple times to increase number of test cases) Now, I am trying the change on all test cases and will create a new JIRA with patch for the changes. This is not eliminating the memory leak 100% ,but reducing it. Will respond to this mail with the new JIRA number. Regards, Amita On 5/19/07, Adriano Crestani [EMAIL PROTECTED] wrote: Amita, did you solve the JIRA 952 memory leak problem? Except JIRA 800 that luciano is going to commit, is there any other new feature or bug to be implemented for this release? Adriano Crestani On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the initial part of TUSCANY-863 under revision 538267.** On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, Points I gathered so far, we can sort out today. Will check more TODOs: 1) close JIRA-800, 863 2) remove JIRA-952 ? please see my last mail for memory leak, it still can happen with code without JIRA-952. It looks like it has to do with how our UT framework is setup.But so far I have not pin pointed the problem. So what path to follow for this JIRA? I will try more and find exact cause and resolution. 3) check all files license info (Adriano did this before, so just for any new code after that, we might need to do this.) 4) update http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release with closed/removed JIRAs 5) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS [javadoc] - give link *Guides:- -Architecture Guide - should be on Tuscany Home Page and not DAS -Developer Guide - complete - how is working on it? (Some content from http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp can be used and completed here) Some content for htmlunit - http://www.mail-archive.com/[EMAIL PROTECTED]/msg06053.html -User Guide - Advanced Web Sample - add link to this after JIRA-863, 800 are commited , dbsetuputility - as its a handy tool for users too -What's new? - list new features in this release -Downloads - add links after 1st RC - [New]Useful Links - http://incubator.apache.org/tuscany/RDB_DAS_white_paper_v-0.2.pdf(for outdated info - how to update?)http://issues.apache.org/jira/browse/TUSCANY-594 - TBD http://java.sys-con.com/read/260053.htm (for outdated info - how to update?) 6) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS 7) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases Make this page in sync with what is going out in M3 8) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Can add below list:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg04822.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16300.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16711.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg01162.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16520.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00589.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg06635.html How to create non containment association ? http://www.mail-archive.com/[EMAIL PROTECTED]/msg12091.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg17136.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg05860.html
Re: DAS M3 Release
Hi, Please take a look at the section Ongoing work items on page http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release and whatever is marked under review, please review and give your comments. This will help a lot in doing any necessary modifications to the DAS part of site. Also, I am gathering DAS questions discussed on ML and forming a FAQ, some archived messages are listed in the same section at the bottom. Please forward any FAQs you would like to include. Regards, Amita (Note: For memory analysis JIRA 1295 is added and patch is submitted, currently under review.) On 5/21/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, It is still work-in-progress. Main changes I did are 1) use simple connection pool on Test Cases framework 2) use finalize() in RDB DAS code 3) Do cleanup (removing references) as needed 4) Decouple DatabaseSetup and DasTest - do not share connections With this, there is some success (i.e. I modified a few cases with these changes effective and the multi-schema are running with no out of memory , I repeated the same testcases multiple times to increase number of test cases) Now, I am trying the change on all test cases and will create a new JIRA with patch for the changes. This is not eliminating the memory leak 100% ,but reducing it. Will respond to this mail with the new JIRA number. Regards, Amita On 5/19/07, Adriano Crestani [EMAIL PROTECTED] wrote: Amita, did you solve the JIRA 952 memory leak problem? Except JIRA 800 that luciano is going to commit, is there any other new feature or bug to be implemented for this release? Adriano Crestani On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the initial part of TUSCANY-863 under revision 538267.** On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, Points I gathered so far, we can sort out today. Will check more TODOs: 1) close JIRA-800, 863 2) remove JIRA-952 ? please see my last mail for memory leak, it still can happen with code without JIRA-952. It looks like it has to do with how our UT framework is setup.But so far I have not pin pointed the problem. So what path to follow for this JIRA? I will try more and find exact cause and resolution. 3) check all files license info (Adriano did this before, so just for any new code after that, we might need to do this.) 4) update http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release with closed/removed JIRAs 5) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS [javadoc] - give link *Guides:- -Architecture Guide - should be on Tuscany Home Page and not DAS -Developer Guide - complete - how is working on it? (Some content from http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp can be used and completed here) Some content for htmlunit - http://www.mail-archive.com/[EMAIL PROTECTED]/msg06053.html -User Guide - Advanced Web Sample - add link to this after JIRA-863, 800 are commited , dbsetuputility - as its a handy tool for users too -What's new? - list new features in this release -Downloads - add links after 1st RC - [New]Useful Links - http://incubator.apache.org/tuscany/RDB_DAS_white_paper_v-0.2.pdf(for outdated info - how to update?)http://issues.apache.org/jira/browse/TUSCANY-594 - TBD http://java.sys-con.com/read/260053.htm (for outdated info - how to update?) 6) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS 7) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases Make this page in sync with what is going out in M3 8) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Can add below list:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg04822.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16300.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16711.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg01162.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16520.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00589.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg06635.html How to create non containment association ? http://www.mail-archive.com/[EMAIL PROTECTED]/msg12091.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg17136.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg05860.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg17146.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg04672.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg09827.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg09571.html ..Need to keep adding to this. 9) run RAT tool?http
Re: Tuscany DAS Features/Questions
Hi Folks,
Can I create JIRAs for these and mark them for DAS Mx, just to have a
pointer to come back to these features?
Regards,
Amita
On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
It will be interesting to get these features into DAS using JIRAs.
I am just trying to get a clear picture of what all details these features
can consist.
1. This can be support for explicit as well as SDO-integrated
inserts/updates
2. a. Here validations can be based on Database provided Meta Data, also,
we can think of defining custom validations per Command basis in DAS
config. What do you think?
2. b. As part of {2. c. 2} , This will have more control on individual
DataGraphs contained
in the root Data Graph. With this, invalid (validation failed) Data Graphs
can be
deleted from the tree. The dependency management logic will need to handle
the consequent
actions for this deletion(parent-child etc.).
2. c. There can be 2 situations -
1 when the data graphs are not of related database entities, here
different config files can split the work
2 when they are for related entities, the worker threads will be sharing
part of load
of same transaction.
Please add your thoughts and any more desirable but missing features, that
DAS can
take up.
Regards,
Amita
On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote:
Should we start creating some JIRAs for these enhancement requests ?
On 5/14/07, Brent Daniel [EMAIL PROTECTED] wrote:
1. Not today, though I think this would be a good feature for the DAS
to pick up.
2 a. No, but that would be an interesting capability. Today I think
validation would best be performed at the client level.
b. It's probably easiest to do this on a case by case basis..
Unfortunately I don't think there's an easy way to undo individual
changes (though you can always undo everything using
ChangeSummary.undoChanges()). To undo an insert, you can simply
delete the DataObject. For property changes, you can use
changeSummary.getOldValues () to get the previous values and re-set
them. I'm not sure if anything easier is coming in future versions of
SDO or not.
c. The DAS has some paging capability for situations like this. From
your description of your application, it sounds like you may also be
able to simply break the app down so that you use several different
config files with independent DataGraphs.
Brent
On 5/11/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Greetings,
We are considering replacing some of our custom, home-grown DAS'
with
Tuscany DAS. As a result, I have a few Tuscany DAS questions.
1. Does the Tuscany DAS have any support for JDBC Batch
Update/Insert
operations?
2. I have a multi-tiered application in which I send a DataGraph of
DataObjects from the middle-tier to a client and later receive the
updated
DataGraph from that client. I would like to apply validation to some
of the
DataObjects in the DataGraph before the changes are persisted to the
database.
a. Is there a mechanism for integrating my validation into the
DAS'
applyChanges() operation to avoid the overhead of traversing the
ChangeSummary twice, once by me and once by the DAS?
b. When a single DataObject fails validation, what is the best
way
for me to undo the changes to that particular DataObject so the DAS
ignores
just those changes and doesn't persist them to the database?
c. The DataGraph of changed DataObjects if often large in my
application. Also, my custom validation logic is quite expensive. So,
I
would like to break the DataGraph into multiple sub-DataGraphs and
execute
the validation logic and the DAS' applyChanges() on separate
WorkManager
threads. I am doing something like that today with my own home-grown
DAS
that is custom to my trivial data model, whereby the DataGraph is
simply a
container for a list of DataObjects that map one-to-one to a database
table.
Thanks in advance for your assistance/insights,
- Ron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
http://people.apache.org/~lresende
Re: DAS M3 Release
Hi All, Points I gathered so far, we can sort out today. Will check more TODOs: 1) close JIRA-800, 863 2) remove JIRA-952 ? please see my last mail for memory leak, it still can happen with code without JIRA-952. It looks like it has to do with how our UT framework is setup.But so far I have not pin pointed the problem. So what path to follow for this JIRA? I will try more and find exact cause and resolution. 3) check all files license info (Adriano did this before, so just for any new code after that, we might need to do this.) 4) update http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release with closed/removed JIRAs 5) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS [javadoc] - give link *Guides:- -Architecture Guide - should be on Tuscany Home Page and not DAS -Developer Guide - complete - how is working on it? (Some content from http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp can be used and completed here) Some content for htmlunit - http://www.mail-archive.com/[EMAIL PROTECTED]/msg06053.html -User Guide - Advanced Web Sample - add link to this after JIRA-863, 800 are commited , dbsetuputility - as its a handy tool for users too -What's new? - list new features in this release -Downloads - add links after 1st RC - [New]Useful Links - http://incubator.apache.org/tuscany/RDB_DAS_white_paper_v-0.2.pdf (for outdated info - how to update?)http://issues.apache.org/jira/browse/TUSCANY-594 - TBD http://java.sys-con.com/read/260053.htm (for outdated info - how to update?) 6) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS 7) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases Make this page in sync with what is going out in M3 8) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Can add below list:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg04822.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16300.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16711.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg01162.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg16520.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00589.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg06635.html How to create non containment association ? http://www.mail-archive.com/[EMAIL PROTECTED]/msg12091.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg17136.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg05860.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg17146.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg04672.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg09827.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg09571.html ..Need to keep adding to this. 9) run RAT tool?http://code.google.com/p/arat/ java -jar RAT/ratsomthing.jar base dir 10) svn - branching, tagging/labeling 11) RAT and UT - where all? Win, Linux,...? 12) where to host RC? what are the steps to create RC? http://issues.apache.org/jira/browse/TUSCANY-890?? 13) what is this http://www.mail-archive.com/[EMAIL PROTECTED]/msg16628.html what did you do here? 14) http://www.mail-archive.com/[EMAIL PROTECTED]/msg09612.html what was this? Regards, Amita On 5/11/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have made a few changes to http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide as below:- Capabilities(How To) Added*DAS support for J2SE environment Added*Explicit Create,Update,Delete Added*Explicit Result Set Shape definition Added*Graph Merger Added Section*Samples (See Capabilities In Use) Please check and give comments. Regards, Amita On 4/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I have worked on a couple of jiras, and planning to analyze more JIRAs soon.So far the JIRAs I have worked on are as below:- TUSCANY-800 - Ajax DAS - patch available, creating a final patch TUSCANY-841 - Compound Key Relationship Tests - resolved TUSCANY-863 - Auto canned DB creation - patch available TUSCANY-948 - DAS support for standalone/J2SE applications - resolved TUSCANY-952 - multiple schema support - patch available TUSCANY-864 - DAS SCA container - may need to be tied to next SCA release, work-in-progress Please give your feedback about how these JIRAs can be made part of DAS Java M3. Also, it will really helpful to get your perspective about what all can be the key features, any pending JIRAs which can add value to this release, any must JIRA which need to be newly added. I am going to research too on this front. Appreciate your comments. Regards, Amita On 4/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Recently we had couple inquires about a DAS Release [1] and [2], so it's probably time to start discussing what should be in the next DAS release.Wecould start by reviewing the discussion we had
DAS Release: IRC chat log 15 May 2007
Start of #tuscany buffer: Tue May 15 21:35:03 2007 * Now talking in #tuscany * adrianocrestani has joined #tuscany adrianocrestani hi lresende hi * Venkat has joined #tuscany kgoodson hi lresende Amita wanted to discuss the status of the das release, and i think this would be good exercise to see where we are Amita hi Amita i have just sent a mail also to ML about what all I found, please check and add to it lresende yes, we could go trough the e-mail now lresende and start putting the results on the wiki Amita shall we go one by one over the items i tried to list in the mail lresende I think 1st we need Jira-863 Amita yes it will be useful utility lresende and i was working on it, so I plan to check that in in couple mins, and i'd use some help to finish it lresende basically, I'd need help finishing the insert part lresende the rest looks like working Amita I would like to help in this Amita please let me know the details lresende JIRA-800 - Amita, where we are with that ? looks like pretty good and almost done ? but I think it has dependency on JIRA-863, right ? Amita yes, i have a working copy with last patch of 863 integrated in 800, but after 863 is done , committed Amita i will touch this again and submit for review in JIRA lresende JIRA-952, the issue is with Out Of Memory, right ? Amita yes, will you please see the last mail on that thread? Amita I have a few reports attached without any code from JIRA952 Amita and they seem quite interesting Amita jprofiler reports Amita all these reports are for the code from trunk, no 952 code lresende so, do you think it's a metter of calling das.releaseResourcesand making the proper clean-up on the das unit tests ? lresende and then the out-of-memory issues will be gone ? Amita yes, as the number of test cases add up, heap memory increases Amita also, we need to have proper finalize() methods in DAS RDB lresende we have ReleaseResources, right ? Amita and please see the issue I mentioned about static DAS variable lresende what with statics ? lresende the jdbc connection ? Amita in UT framwwork - DatabaseSetup shares Connection with DasTest, and in one of the places it is static Amita and same is passed to DAS() instance Amita so what will be the effect on GC? lresende hummm... i see Amita I have some local code am trying to separate this connection sharing lresende we might need to revisit this Amita need a day to see the effect, work in progress lresende k Amita but all this is without 952 lresende so we have these 3 jiras + out-of-memory in the test cases Amita yes lresende and the rest is more like documentation ? lresende and can go in paralel with rc ? Amita yes documentation can go in // with RC ant_ Can i suggest one more thing - change the distributions so there's just two - a src and a binary, and have those unzip into a folder with the same name as the download file? lresende ant, I think we have today bin, source, sample, javadoc lresende javadoc could be incorporated into bin lresende problem is size of distributions lresende why would you like samples to be as one ? ant_ ...why would it be kept seperate? :) ant_ I'd like all the Tuscany distro's to be the same Venkat lresende, I have been testing a bit the sca disbs today.. and as a user I felt good to see the samples as part of each disb. ant_ src which includes all the src ant_ bin which includes all the jars and dependencies, the javadoc and samples ant_ thats what the SCA one is like and what SDO have said they'll change to lresende my view is that, binary distribution is the libraries you need to incorporate into your app in order to run the das framework ant_ another reason is with so many downloads it makes the download page really complicated lresende the samples, would have things you don't need if you are familiar with the technology, etc... lresende but i think we can revisit this ant_ by deploying the jar's to the maven repo youmake them available to easiliy incorporate into an app lresende well, not everybody uses maven :) ant_ still can just click on the repos link, or use the binary distro lresende otherwise we woudn't be creating ant scripts and one big sca jar file, right ? lresende to use the repos link, it would be necessary to download variousl things in multiple places, right ? das have dependencies on sdo, etc lresende i'd also like to check what other opensource projects are doing ant_ sure ok, think you'll find just a src and bin is preety common lresende k, i lresende i'll send e-mail to the dev list with this proposal lresende so the comunity can have a say on that as well ant_ cool lresende Amita lresende on your last e-mail you say something about Architecture guide being on tuscany site Amita also, for JIRA 952, what should be the action? Amita yes that is next lresende so, for 952, i think the jira itself might be ok lresende but we need the fix on unit tests framework first, right ? Amita yes * rfeng has joined #tuscany lresende k, so we can
IRC for DAS release - May15th , 8.00 a.m. PST
Hi, Regarding DAS release , we need to know where we are and what is still left. So it will be really helpful if we can talk in IRC at the proposed time. See you there. Regards, Amita
Re: DAS M3 Release
Hi, I have made a few changes to http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide as below:- Capabilities(How To) Added*DAS support for J2SE environment Added*Explicit Create,Update,Delete Added*Explicit Result Set Shape definition Added*Graph Merger Added Section*Samples (See Capabilities In Use) Please check and give comments. Regards, Amita On 4/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I have worked on a couple of jiras, and planning to analyze more JIRAs soon.So far the JIRAs I have worked on are as below:- TUSCANY-800 - Ajax DAS - patch available, creating a final patch TUSCANY-841 - Compound Key Relationship Tests - resolved TUSCANY-863 - Auto canned DB creation - patch available TUSCANY-948 - DAS support for standalone/J2SE applications - resolved TUSCANY-952 - multiple schema support - patch available TUSCANY-864 - DAS SCA container - may need to be tied to next SCA release, work-in-progress Please give your feedback about how these JIRAs can be made part of DAS Java M3. Also, it will really helpful to get your perspective about what all can be the key features, any pending JIRAs which can add value to this release, any must JIRA which need to be newly added. I am going to research too on this front. Appreciate your comments. Regards, Amita On 4/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Recently we had couple inquires about a DAS Release [1] and [2], so it's probably time to start discussing what should be in the next DAS release.Wecould start by reviewing the discussion we had right after we released DAS M2 [3], and also get a list of things we already have done after our previous release. Couple things I would like to help for our next release: - Review MySQL Support Sample - Automate creation of Canned databases for DAS Samples (TUSCANY-863) Documentation - Continue to work on DAS User's guide - Migrate it to new wiki and investigate the possibility to add to the release package Infrastructure - Automate release distribution process Once we agree on a set of items for our next release, we then could start tracking the release progress on our wiki. Thoughts ? [1] - http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00798.html [2] - http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00589.html [3] - http://www.mail-archive.com/[EMAIL PROTECTED]/msg11017.html [4] - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases -- Luciano Resende http://people.apache.org/~lresende
Re: DAS M3 Release
Hi All, I have worked on a couple of jiras, and planning to analyze more JIRAs soon.So far the JIRAs I have worked on are as below:- TUSCANY-800 - Ajax DAS - patch available, creating a final patch TUSCANY-841 - Compound Key Relationship Tests - resolved TUSCANY-863 - Auto canned DB creation - patch available TUSCANY-948 - DAS support for standalone/J2SE applications - resolved TUSCANY-952 - multiple schema support - patch available TUSCANY-864 - DAS SCA container - may need to be tied to next SCA release, work-in-progress Please give your feedback about how these JIRAs can be made part of DAS Java M3. Also, it will really helpful to get your perspective about what all can be the key features, any pending JIRAs which can add value to this release, any must JIRA which need to be newly added. I am going to research too on this front. Appreciate your comments. Regards, Amita On 4/16/07, Luciano Resende [EMAIL PROTECTED] wrote: Recently we had couple inquires about a DAS Release [1] and [2], so it's probably time to start discussing what should be in the next DAS release.Wecould start by reviewing the discussion we had right after we released DAS M2 [3], and also get a list of things we already have done after our previous release. Couple things I would like to help for our next release: - Review MySQL Support Sample - Automate creation of Canned databases for DAS Samples (TUSCANY-863) Documentation - Continue to work on DAS User's guide - Migrate it to new wiki and investigate the possibility to add to the release package Infrastructure - Automate release distribution process Once we agree on a set of items for our next release, we then could start tracking the release progress on our wiki. Thoughts ? [1] - http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00798.html [2] - http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00589.html [3] - http://www.mail-archive.com/[EMAIL PROTECTED]/msg11017.html [4] - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases -- Luciano Resende http://people.apache.org/~lresende
