Re: [VOTE] Release SDO Java version 1.1-incubating (release candidate 2)

[Amita Vadhavkar]

I have tested the RC2 in details, and all seems fine, so here is my
+1

Regards,
Amita

On Tue, Mar 4, 2008 at 7:05 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I have done some basic testing on Linux, compiles fine from a clean
> maven repo and samples are working. I have also looked at license and
> notice files, seems fine.
>
> +1
>
> On Sun, Mar 2, 2008 at 5:16 PM, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> > It looks good to me. +1
> >
> >  Frank.
> >
> >  [EMAIL PROTECTED] wrote on 02/29/2008 06:30:37 AM:
> >
> >
> >
> >  > Please review and vote to release the 1.1-incubating release of
> Tuscany
> >  SDO
> >  > for Java
> >  >
> >  > The distribution files are at [1]
> >  > Maven artifacts for the release candidate are available at [2]
> >  > The tag for the release is at [3]
> >  >
> >  > The rat report is at - [4], [5]
> >  >
> >  > Here's my +1
> >  >
> >  > Kelvin.
> >  >
> >  > [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/tags/java/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
> >
> >
> >  -
> >  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]
>
>

[Java SDO] Need help in completing release management for SDO 1.1-incubating

[Amita Vadhavkar]

Hi All,
I will not be able to continue doing the release management activities from
now on for the ongoing SDO release.
It will be really great if somebody can pick the thread and complete what is
remaining in the release.

Regards,
Amita

Re: [DAS] Running tomcat samples

[Amita Vadhavkar]

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/ 
>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/ 
>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/ 
>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/ 
>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/ 
>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/ 
>at com.ga

SDO Java 1.1-incubating release candidate 1

[Amita Vadhavkar]

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-RC1
[2] 
http://people.apache.org/~amita/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.txt
[5]
http://people.apache.org/~amita/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

[jira] Updated: (TUSCANY-1360) New SDOUtil: Getting the enumeration facet

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1360:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> New SDOUtil: Getting the enumeration facet
> --
>
> Key: TUSCANY-1360
> URL: https://issues.apache.org/jira/browse/TUSCANY-1360
> Project: Tuscany
>  Issue Type: Wish
>  Components: Java SDO Tools
>Reporter: Christian Landbo Frederiksen
>    Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 1360-Amita.patch, 1360-Frank.patch
>
>
> This has been discussed in the lists: 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg01095.html
> I do this:
>   public static List getEnumerationFacet(Type type) {
>return
>  ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
>}
> Kelvin suggested another way
> I think you should be able to do
> type.getInstanceProperties() and find the Property called "enumeration".
> Then you can get the enumerations using that Property.
> (see MetaDataInstancePropertiesTestCase [2])
> Having this encapsuled by the SDOUtil would be cool (but maybe overkill - you 
> decide)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-829) Investigate integration of RogueWave tests

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-829:


Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-1.1
>
> Attachments: jira-829.zip, sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1359) New SDOUtil: Upper and lower bound on properties where 'isMany' is true

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1359:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> New SDOUtil: Upper and lower bound on properties where 'isMany' is true
> ---
>
> Key: TUSCANY-1359
> URL: https://issues.apache.org/jira/browse/TUSCANY-1359
> Project: Tuscany
>  Issue Type: Wish
>  Components: Java SDO Tools
>Reporter: Christian Landbo Frederiksen
>Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 1359.patch
>
>
> Can be implemented like this:
>  public static int getUpperBound(Property property) {
> return ((EStructuralFeature) property).getUpperBound();
>  }
>public static int getLowerBound(Property property) {
>return ((EStructuralFeature) property).getLowerBound();
>}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2011:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> include apache headers in xmls and xsds without causing test case failures
> --
>
> Key: TUSCANY-2011
> URL: https://issues.apache.org/jira/browse/TUSCANY-2011
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation, Java SDO Tools
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-1.1
>
>
> there are total 7 files in sdo-impl and 3 files in tools-test which can 
> contain Apache headers without any test case failures, so do so for a 
> successful RAT report

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2025) SDO Java Samples - minor commentary fixes

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2025:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SDO Java Samples - minor commentary fixes
> -
>
> Key: TUSCANY-2025
> URL: https://issues.apache.org/jira/browse/TUSCANY-2025
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-1.1
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2009:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Java SDO's EqualityHelper doesn't compare Bytes values correctly
> 
>
> Key: TUSCANY-2009
> URL: https://issues.apache.org/jira/browse/TUSCANY-2009
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-1.1
>
> Attachments: 2009.patch, Test2009.java
>
>
> Comparison of two Bytes values fails when it should succeed.  The test for 
> equality passes through the EqualityHelperImpl.equal method.  In that method, 
> the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, 
> EAttribute).  For a simple type, it defers to java's '==' operator.  So, two 
> different object arrays are being compared, not for their contents, but 
> rather if they are the same object.  Attached is a test case which 
> demonstrates this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2007:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SDO Samples - fix sampleProgramContents.html's Firefox display issue
> 
>
> Key: TUSCANY-2007
> URL: https://issues.apache.org/jira/browse/TUSCANY-2007
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 2007.patch
>
>
> By 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. Without it, it was displaying as html text on the 
> browser.
>  title="http://www.w3.org/TR/html4/loose.dtd";>" 
> class="link">http://www.w3.org/TR/html4/loose.dtd";>
> So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
> above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1935) Conversion of Bytes to/from String properties is not functioning correctly.

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1935:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Conversion of Bytes to/from String properties is not functioning correctly.
> ---
>
> Key: TUSCANY-1935
> URL: https://issues.apache.org/jira/browse/TUSCANY-1935
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-1.1
>
> Attachments: 1935.patch, 1935WithTestAugmentation.patch, Test1935.java
>
>
> According to the SDO for Java specification v. 2.1.0, conversion of string 
> properties to byte arrays and from byte array properties to string is a 
> supported conversion type.  This is confirmed on page 138 of the spec.  
> Additionally, sections 8.1.4 and 8.1.5 describe the behavior of such 
> conversions.  When an attempt is made to perform one of the following 
> functions, though, a ClassCastException is thrown:
>  dataObj.getBytes("stringPropName");
>  dataObj.set("stringPropName", byteArrayValue);
>  dataObj.set("byteArrayPropName", stringValue);
> The dataObj.getString("byteArrayPropName") method seems to be functioning 
> correctly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1853:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> XSD2JavaGenerator generates Java identifier with dots
> -
>
> Key: TUSCANY-1853
> URL: https://issues.apache.org/jira/browse/TUSCANY-1853
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
> Environment: Windows XP, jre 1.5
>Reporter: Cezary Tkaczyk
> Fix For: Java-SDO-1.1
>
>
> Hello,
> While I'm trying to compile generated by XSD2JavaGenerator Java classes, I've 
> got such an error:
> 
> [javac] 
> C:\projekty\eclipse-workspace-rbpl-sdo-1.0\REB-Catalog-SDO-Java\src-autogen\pl\esb\impl\EsbFactoryImpl.java:169:
>  ';' expected
> [javac] pl.esb.blm.adapter.AdapterFactory 
> pl.esb.blm.adapter.AdapterFactoryInstance = 
> pl.esb.blm.adapter.AdapterFactory.INSTANCE;
> [javac]^
>  
> The problem is: variable identifier cannot contain dots.
> The place, where this error appears looks like this:
> public static EsbFactoryImpl init()
>   {
> if (instance != null ) return instance;
> instance = new EsbFactoryImpl();
> // Initialize dependent packages
> AdapterFactory AdapterFactoryInstance = AdapterFactory.INSTANCE;
> RebFactory RebFactoryInstance = RebFactory.INSTANCE;
> pl.raiffeisen.esb.blm.adapter.AdapterFactory 
> pl.raiffeisen.esb.blm.adapter.AdapterFactoryInstance = 
> pl.raiffeisen.esb.blm.adapter.AdapterFactory.INSTANCE;
> 
> // Create package meta-data objects
> instance.createMetaData();
> // Initialize created meta-data
> instance.initializeMetaData();
> 
> // Mark meta-data to indicate it can't be changed
> //theEsbFactoryImpl.freeze(); //FB do we need to freeze / should we 
> freeze 
> return instance;
>   }
> I think the problem is that I have two namespaces of the same suffix:
> http://www.esb.pl/blm/adapter
> http://www.esb.pl/ods1/adapter
> So, generator is trying to avoid the problem creating unique variable name: 
> pl.esb.blm.adapter.AdapterFactoryInstance
> Unfortunately, this is not valid identifier.
> Kind Regards,
> Czarek

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1838:
-

  Component/s: Java SDO Implementation
Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> HelperContext provided to createObjectOutputStream is inadvertantly ignored
> ---
>
> Key: TUSCANY-1838
> URL: https://issues.apache.org/jira/browse/TUSCANY-1838
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-1.1
>
>
> Ron Gavlin reported in http://www.mail-archive.com/[EMAIL 
> PROTECTED]/msg01884.html an issue with HelperContexts being unavailable 
> during marshalling.  I feel sure that this is due to this piece of code here 
> in HelperProviderBase::ResolvableImpl#writeDataObject
> XMLHelper xmlHelperLocal = xmlHelper;
> if(objectOutput instanceof SDOObjectInputStream)
> {
> xmlHelperLocal = 
> ((SDOObjectInputStream)objectOutput).getHelperContext().getXMLHelper();
> }
> xmlHelperLocal.save(dataObject, "commonj.sdo", "dataObject", 
> gzipOutputStream);
> where the instanceof test and cast should be to SDOObjectOutputStream

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1842:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> IOException loading DataGraph containing a deleted dataObject with a property 
> whose type extends a complexType w/simple integer content
> ---
>
> Key: TUSCANY-1842
> URL: https://issues.apache.org/jira/browse/TUSCANY-1842
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
> Environment: Windows XP, Sun JDK 1.5.0_09
>Reporter: Ron Gavlin
>Priority: Critical
> Fix For: Java-SDO-1.1
>
> Attachments: 1842data.zip, tuscany-sdo.TUSCANY-1842.patch
>
>
> In the test method, testComplexTypeWithSimpleContentExtensionChangeSummary() 
> listed below, a DataGraph is created with a dataObject whose property type 
> extends a complexType with simple integer content. After the dataObject is 
> deleted, an attempt is made to save and load the DataGraph. While the 
> DataGraph is being loaded, an unsuccessful attempt is made to convert a 
> zero-length string into a BigInteger. 
> Any suggestions on how to best fix this are most welcome.
> Thanks,
> - Ron
> ==
> substitutionWithExtensionValues.xsd
> == 
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   
>   
>  substitutionGroup="sev:result" />
>   
>   
>   
>  maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>value="English" />
>value="French" />
>value="Spanish" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> ==
> substitutionWithExtensionValues2.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV2";
>   xmlns:sev2="http://www.example.com/substitutionEV2";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   http://www.example.com/substitutionEV";
>   schemaLocation="substitutionWithExtensionValues.xsd" />
>   
>   
>   
>   
>maxOccurs="unbounded"
>   type="sev2:Results2Type" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   

[jira] Updated: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1832:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Complex type w/simple content restriction facets are ignored
> 
>
> Key: TUSCANY-1832
> URL: https://issues.apache.org/jira/browse/TUSCANY-1832
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.1
>
>
> Namespace "http://www.example.com/substitutionEV"; includes two complex type 
> with simple content named CommentType and MyCommentType. MyCommentType 
> restricts CommentType with facet maxLength="40". This maxLength facet does 
> not appear to exist in the SDO metadata. The sample test case named 
> testComplexTypeWithSimpleContentExtension() is included below.
> ==
> substitutionWithExtensionValues.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   
>   
>  substitutionGroup="sev:result" />
>   
>   
>   
>  maxOccurs="unbounded" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>value="English" />
>value="French" />
>value="Spanish" />
>   
>   
>   
>   
>   
>   
>   
>   
> 
>   
> 
> 
>   
> 
>   
>   
> 
> ==
> substitutionWithExtensionValues2.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV2";
>   xmlns:sev2="http://www.example.com/substitutionEV2";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   http://www.example.com/substitutionEV";
>   schemaLocation="substitutionWithExtensionValues.xsd" />
>   
>   
>   
>   
>maxOccurs="unbounded"
>   type="sev2:Results2Type" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> ==
> substitutionWithExtensionValues1.xml
> ==
> 
> http://www.example.com/substitutionEV2";>
>   
>   http://www.example.com/substitutionEV";>
>   
>   
>   
>   name1
>   value1
>   
>   
>   
>   myName2
>   myValue2
>   
>   comment0
>   
>   http://www.example.com/substitutionEV";>
>   A

[jira] Updated: (TUSCANY-1830) SimpleType extension across mixed static/dynamic namespaces is broken

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1830:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SimpleType extension across mixed static/dynamic namespaces is broken
> -
>
> Key: TUSCANY-1830
> URL: https://issues.apache.org/jira/browse/TUSCANY-1830
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.1
>
>
> I have a statically registered namespace 
> "http://www.example.com/substitutionEV"; with a simpleType named UuidType with 
> a pattern facet. I also have a dynamically registered namespace 
> "http://www.example.com/substitutionEV2"; with a simpleType named Uuid2Type 
> which is a restriction of UuidType. When I invoke uuid2Type.getBaseTypes(), 
> the parent UuidType is not returned. I have included a sample test below.
> ==
> substitutionWithExtensionValues.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV"; 
> xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   
>   
>   
>substitutionGroup="sev:result"/>
>   
>   
> 
>   
>   
>   
> 
>   
>   
>   
> 
>   
>   
>   
> 
>   
>   
>   
> 
>   
> 
>   
>   
>   
> 
>value="[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-f]{12}"/>
> 
>   
>   
>   
> 
>   
> 
>   
>   
> 
> ==
> substitutionWithExtensionValues2.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
>   targetNamespace="http://www.example.com/substitutionEV2";
>   xmlns:sev2="http://www.example.com/substitutionEV2";
>   xmlns:sev="http://www.example.com/substitutionEV";>
>   
>   http://www.example.com/substitutionEV";
>   schemaLocation="substitutionWithExtensionValues.xsd" />
>   
>   
>   
>   
>maxOccurs="unbounded"
>   type="sev2:Results2Type" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> ==
> substitutionWithExtensionValues1.xml
> ==
> 
> http://www.example.com/substitutionEV2";>
>   ----
>   http://www.example.com/substitutionEV";>
> ----
>   
>   
> ----
>   name1
>   value1
>   
>   
>   
> ----
>   myName2
>   myValue2
>   
>   comment0
>   
>   http://www.example.com/substitutionEV";>
> ----
>   
>   
> ----
>   myNameB
>   myValueB
>   
>   commentA
>   
>   commentZ
> 
> ==
> SubstitutionWithExtensionValuesTestCase.java
> ==
> /**
>  *
>  *  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,

[jira] Updated: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1812:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> XMLHelper.load() IOException using schema that has both a substitution group 
> and an extension
> -
>
> Key: TUSCANY-1812
> URL: https://issues.apache.org/jira/browse/TUSCANY-1812
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Critical
> Fix For: Java-SDO-1.1
>
> Attachments: tuscany-sdo.TUSCANY-1812_1830_1832.patch
>
>
> Below, please find a failing Java test case and its XSD and XML test 
> resources. Also, please find the stacktrace from the failing Java test case. 
> It is interesting to note that this test does not fail when using dynamic 
> SDO. Please comment if you have questions.
> - Ron
> package org.apache.tuscany.sdo.test;
> import java.io.IOException;
> import junit.framework.TestCase;
> import com.example.substitution.ev.SEVFactory;
> import commonj.sdo.DataObject;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.impl.HelperProvider;
> public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
>   
>   public void test() throws IOException {
> HelperContext hc = HelperProvider.getDefaultContext();
> SEVFactory.INSTANCE.register(hc);
> 
> XMLHelper xmlHelper = hc.getXMLHelper();
> DataObject loadedObject = 
> xmlHelper.load(getClass().getResourceAsStream("/substitutionWithExtensionValues1.xml")).getRootObject();
>   }
> }
> substitutionWithExtensionValues.xsd
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV"; 
> xmlns:sv="http://www.example.com/substitutionEV";>
>   
>   
>   
>   
>substitutionGroup="sv:result"/>
>   
>   
> 
>   
>   
> 
>   
>   
>   
> 
>   
>   
> 
>   
>   
> 
>   
> 
>   
>   
> 
> substitutionWithExtensionValues1.xml
> 
> http://www.example.com/substitutionEV";>
>   
> name1
> value1
>   
>   
> myName1
> myValue1
>   
>   comment1
> 
> STACKTRACE
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 
> 'myResult' not found. (http:///temp.xml, 7, 17)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
>   at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
>   at 
> org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
>   at 
> org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
>   at 
> org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
>   at 
> org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
>   at 
> org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
>   at 
> org.apache.tuscany.sdo.test.SubstitutionWithExtensionValuesTestCase.test(SubstitutionWithExtensionValuesTestCase.java:40)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 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 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.jun

[jira] Updated: (TUSCANY-1788) DataObjectXMLStreamReader doesn't declare the xsi namespace if there is a xsi:type or xsi:nil attribute

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1788:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> DataObjectXMLStreamReader doesn't declare the xsi namespace if there is a 
> xsi:type or xsi:nil attribute
> ---
>
> Key: TUSCANY-1788
> URL: https://issues.apache.org/jira/browse/TUSCANY-1788
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Reporter: Raymond Feng
>Assignee: Raymond Feng
> Fix For: Java-SDO-1.1
>
>
> In the case that we need to produce an xsi:type or xsi:nil attribute, the 
> current code doesn't declare the xsi namespace. As a result, it creates an 
> invalid XML stream. I'll check in a fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1811) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:float

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1811:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> ClassCastException saving codegen-based DataGraph with ChangeSummary 
> containing an xsd:float
> 
>
> Key: TUSCANY-1811
> URL: https://issues.apache.org/jira/browse/TUSCANY-1811
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.1
>
> Attachments: tuscany-sdo.TUSCANY-1811.patch
>
>
> This problem is similar to TUSCANY-1393 except the schema type in this case 
> is an xsd:float instead of an xsd:int. The fix involves adding the following 
> lines to DataObjectBase.java. If you would like me to submit a patch with a 
> revised testcase, let me know.
> LINES TO BE ADDED to DataObjectBase.java:
>   protected void notify(int changeKind, int property, float oldFloatValue, 
> float newFloatValue)
>   {
> eNotify(new ENotificationImpl(this, Notification.SET, property, 
> oldFloatValue, newFloatValue));
>   }
>   
>   protected void notify(int changeKind, int property, float oldFloatValue, 
> float newFloatValue, boolean isSetChange)
>   {
> eNotify(new ENotificationImpl(this, Notification.SET, property, 
> oldFloatValue, newFloatValue, isSetChange));
>   }
> END OF LINES TO BE ADDED
> - Ron
> P.S., below I have included the stacktrace for the problem.
> java.lang.ClassCastException: java.lang.Double
>   at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertFloatToString(ModelFactoryImpl.java:2036)
>   at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertToString(ModelFactoryImpl.java:318)
>   at 
> org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.convertToString(FactoryBase.java:291)
>   at 
> org.eclipse.emf.ecore.util.EcoreUtil.convertToString(EcoreUtil.java:2994)
>   at 
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getDataValue(FeatureChangeImpl.java:228)
>   at 
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.eIsSet(FeatureChangeImpl.java:771)
>   at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:818)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1107)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:620)
>   at 
> org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$SaveImpl.traverse(DataGraphResourceFactoryImpl.java:382)
>   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233)
>   at 
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203)
>   at 
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
>   at 
> org.apache.tuscany.sdo.helper.SDOHelperImpl.saveDataGraph(SDOHelperImpl.java:182)
>   at org.apache.tuscany.sdo.api.SDOUtil.saveDataGraph(SDOUtil.java:158)
>   at 
> org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithIntAndFloat(ChangeSummaryGenTestCase.java:128)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc

[jira] Updated: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1780:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> [JAVA-SDO] Incorrect generation of class with default value for a list
> --
>
> Key: TUSCANY-1780
> URL: https://issues.apache.org/jira/browse/TUSCANY-1780
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0, Java-SDO-Next
> Environment: Windows XP, JRE 1.4.2 and JRE 1.5
>Reporter: Chris Mildebrandt
>Priority: Critical
> Fix For: Java-SDO-1.1
>
> Attachments: Address.xsd, Address2.xsd, SDOClass.java
>
>
> Hello,
> There seems to be a problem when generating static classes when lists are 
> involved. I have the following lines in my schema:
>  default="myCat"/>
> 
> 
> 
> This generates the following line in the impl class:
> protected static final Object CATEGORY_TYPE_DEFAULT_ = 
> ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(),
>  "myCat");
> The class ModelPackageImpl doesn't exist.
> I've tried this with the 1.0 version of SDO and a version I built today.
> Let me know if you need any more information. Thanks,
> -Chris

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1726) List DataObject.getList(String path) should return an empty list when there is no value

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1726:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> List DataObject.getList(String path) should return an empty list when there 
> is no value
> ---
>
> Key: TUSCANY-1726
> URL: https://issues.apache.org/jira/browse/TUSCANY-1726
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SDO-1.1
>
> Attachments: 1726.patch
>
>
> According to SDO 2.1 spec section 3.1.4, it said "DataObject methods with a 
> return type of List, on the DataObject interface or generated, return empty 
> lists rather than null when there is no value."  This means getList() method 
> should return an empty list when there is no value.  Current implementation 
> returns null which is wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1655) Generated code uses deprecated method FactoryBase.getProperty(Type,int)

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1655:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Generated code uses deprecated method FactoryBase.getProperty(Type,int)
> ---
>
> Key: TUSCANY-1655
> URL: https://issues.apache.org/jira/browse/TUSCANY-1655
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Assignee: Fuhwei Lwo
> Fix For: Java-SDO-1.1
>
>
> Please refer - 
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22705.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1673) PackageClassInfo being override when Element and ComplexType have same name

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1673:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> PackageClassInfo being override when Element and ComplexType have same name
> ---
>
> Key: TUSCANY-1673
> URL: https://issues.apache.org/jira/browse/TUSCANY-1673
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-Next
>Reporter: Luciano Resende
>Priority: Blocker
> Fix For: Java-SDO-1.1
>
> Attachments: 1673.patch, 1673.patch, interopdoc.wsdl
>
>
> In Wsdl2Java, interfaces are getting generated wrong, because isAnonymous 
> information is getting overridden when element and complexType have same 
> name. I'll attach the wsdl in question here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1645) XSD2JavaGenerator failed to gen on the wsdl files with only element in

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1645:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> XSD2JavaGenerator failed to gen on the wsdl files with only  
> element in 
> 
>
> Key: TUSCANY-1645
> URL: https://issues.apache.org/jira/browse/TUSCANY-1645
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SDO-1.1
>
> Attachments: 1645.patch, 1645.patch, EchoService_schema1.xsd, 
> TUSCANY-544.wsdl
>
>
> NullPointerException was thrown when a WSDL with XSD definition like below 
> was used by the XSD2JavaGenerator. In this case, there is no targetNamespace 
> was specified in the 
> 
> 
>   http://test/"; 
> schemaLocation="EchoService_schema1.xsd"/>
> 
>   
> This problem was derived from SCA JIRA TUSCANY-544 and related to SDO JIRA 
> TUSCANY-1327.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1638:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SDO command-line code generator behaves differently than standalone when 
> invoked in Eclipse
> ---
>
> Key: TUSCANY-1638
> URL: https://issues.apache.org/jira/browse/TUSCANY-1638
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
> Environment: OS is Windows XP Professional SP2, and the SDO command 
> line tool is invoked in side an Eclipse 3.3 plugin.
>Reporter: Sean Zhou
> Fix For: Java-SDO-1.1
>
> Attachments: 1638.patch, test1638.zip
>
>
> I am trying to invoke the SDO command-line code generator inside eclipse 
> which is causing it to behave differently than standalone. The following fix 
> is suggested by Frank in Tuscany:
>1) In class 
> org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory 
> add another override method, createGenModelAdapter(), to return a new Tuscany 
> subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter).
>2) In the new subclass, override the ensureProjectExists() method to do 
> nothing.
>3) Override anything else you need to ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1574) SDOXSDEcoreBuilder.createResourceSet() is not thread safe

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1574:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SDOXSDEcoreBuilder.createResourceSet() is not thread safe
> -
>
> Key: TUSCANY-1574
> URL: https://issues.apache.org/jira/browse/TUSCANY-1574
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-1.1
>
> Attachments: 1574.patch
>
>
> The method createResourceSet() in SDOXSDEcoreBuilder is not thread safe.  It 
> performs an enumeration of EPackage resource objects and adds them to the 
> ResourceSet created within the method.  The problem is that a ResourceSet 
> object is a container.  So, when the Resource objects are added with this 
> statement:
> resources.add(resource);
> EMF attempts to first unlink the resource from its previous container.  That 
> in itself is an issue, but beyond that, during a stress run, the unlinking 
> can occur simultaneously on multiple threads, causing exceptions.  This code 
> was added for Tuscany-513.  I'm not clear what are the goals, but I was 
> wondering if we can accomplish the same task in another manner.  The goal 
> seems to be to expose the newly created ResourceSet to the built-in models.  
> Perhaps this pattern from DataObjectUtil.configureResourceSet would work:
> resourceSet.setPackageRegistry(new 
> EPackageRegistryImpl(HelperContextImpl.getBuiltInModelRegistry()));
> Would this line of code accomplish a similar function?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1545) Change default XML encoding to "UTF-8".

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1545:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Change default XML encoding to "UTF-8". 
> 
>
> Key: TUSCANY-1545
> URL: https://issues.apache.org/jira/browse/TUSCANY-1545
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
>Reporter: Frank Budinsky
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 1545.patch
>
>
> XMLHelper.save() uses "ASCII" encoding by default, but the spec says the 
> default encoding is "UTF-8". 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1540:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Abstract Static Base Types mixed with Dynamic Extended Types
> 
>
> Key: TUSCANY-1540
> URL: https://issues.apache.org/jira/browse/TUSCANY-1540
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
>Reporter: Murtaza Goga
> Fix For: Java-SDO-1.1
>
> Attachments: TUSCANY-1540-TestCases.patch
>
>
> Setting a property on a static data object with an object of a type extended 
> in a dynamic model results in a ClassCastException.
> Scenario:
> Static schema-
>   
> 
>   
>   
> 
>   
>   
>   
> Dynamic Schema
> 
>   
> 
>   
> 
>   
> 
>   
> 
> The following will fail:
> DataFactory factory = scope.getDataFactory();
> factory.create(CustomerType.class).setDataObject("info", 
> factory.create("dynamicNS", "InfoType"));
> It should be legal to assign a property to an object if they are in the same 
> hierachy.
> Steps to reproduce within Tuscany:
> Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 
> 'InfoType' defined in extensible/customer.xsd  is marked as abstract.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1531) Java SDO Documentation page should be updated to default website stype/design

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1531:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Java SDO Documentation page should be updated to default website stype/design
> -
>
> Key: TUSCANY-1531
> URL: https://issues.apache.org/jira/browse/TUSCANY-1531
> Project: Tuscany
>  Issue Type: Bug
>  Components: Website
>Affects Versions: Java-SDO-Next
>Reporter: Luciano Resende
> Fix For: Java-SDO-1.1
>
>
> The default left side menus are missing or wrong
> 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.
> User guide has wrong styles : 
> http://incubator.apache.org/tuscany/sdo-java-user-guide.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1528:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> ClassCastException thrown when trying to deserializing an XML with undefined 
> global element
> ---
>
> Key: TUSCANY-1528
> URL: https://issues.apache.org/jira/browse/TUSCANY-1528
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SDO-1.1
>
> Attachments: 1528-testcase.patch, 1528.patch
>
>
> Using simple.xsd, I can serialize and deserialize an XML with a undefined 
> global element. If I removed the global element definition from the 
> simple.xsd, a ClassCastException will be thrown. It seems without the global 
> element definition's presence some required step was not done.  Here is the 
> stack trace and test case.
> junit.framework.AssertionFailedError: java.lang.ClassCastException: 
> org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with 
> commonj.sdo.DataObject
>   at junit.framework.Assert.fail(Assert.java:47)
>   at 
> org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:615)
>   at 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 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1514) DataHelperImpl.toDate will report a NullPointerException

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1514:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> DataHelperImpl.toDate  will report a NullPointerException
> -
>
> Key: TUSCANY-1514
> URL: https://issues.apache.org/jira/browse/TUSCANY-1514
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: Leo Li
> Fix For: Java-SDO-1.1
>
>
> Hi All , 
>   when I  read the data from a table , there is a Datetime field in the 
> table , if the datetime field'value is null , the SDO will produce a 
> NullPointException , Maybe this is a bug , and How to fixed it  ? 
>  
> Exception content as follow : 
>  
> 12:02:21,015 [main] ERROR [DasService]
> java.lang.NullPointerException
>  at
> org.apache.tuscany.sdo.helper.DataHelperImpl.toDate(DataHelperImpl.java:48)
>  at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createDateFromString(Mode
> lFactoryImpl.java:1931)
>  at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createFromString(ModelFac
> toryImpl.java:224)
>  at
> org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.createFromString(Fac
> toryBase.java:270)
>  at
> org.eclipse.emf.ecore.util.EcoreUtil.createFromString(EcoreUtil.java:2982)
>  at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getValue(FeatureChangeIm
> pl.java:428)
>  at
> org.apache.tuscany.sdo.impl.ChangeSummarySettingImpl.getValue(ChangeSummaryS
> ettingImpl.java:89)
>  at
> org.apache.tuscany.das.rdb.util.DataObjectUtil.restoreAttributeValues(DataOb
> jectUtil.java:74)
>  at
> org.apache.tuscany.das.rdb.util.DataObjectUtil.getRestoredCopy(DataObjectUti
> l.java:41)
>  at
> org.apache.tuscany.das.rdb.impl.DeleteOperation.(DeleteOperation.java:
> 34)
>  at
> org.apache.tuscany.das.rdb.impl.ChangeFactory.createDeleteOperation(ChangeFa
> ctory.java:77)
>  at
> org.apache.tuscany.das.rdb.impl.ChangeSummarizer.createChange(ChangeSummariz
> er.java:103)
>  at
> org.apache.tuscany.das.rdb.impl.ChangeSummarizer.loadChanges(ChangeSummarize
> r.java:80)
>  at
> org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute(ApplyChanges
> CommandImpl.java:64)
>  at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges(DASImpl.java:310)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1505:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Naming scheme used for variables in code gen factory init() method breaks 
> under specific circumstances
> --
>
> Key: TUSCANY-1505
> URL: https://issues.apache.org/jira/browse/TUSCANY-1505
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 1505.patch, 1505.patch, test1505.zip
>
>
> A new code gen pattern was recently added to change how dependent packages 
> are initialized in the xxxFactoryImpl.init() method.  Under this new pattern, 
> all dependent packages are initialized via the factoryInterface.INSTANCE 
> method.   An initialization call is made for each dependent gen package.  The 
> getImportedFactoryInterfaceName() is used to retrieve the short name.  This 
> value is mashed with the text 'Instnace' to form a variable name.  If 
> circumstances dictate that multiple packages contain the same factory 
> interface name, the getImportedFactoryInterfaceName() will fully qualify the 
> response instead of using the short name.  This breaks the generated code, 
> due to the use of a '.' in the variable name.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1484) StackOverflowException invoking isSet on a static DataObject with a dynamically-added property

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1484:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> StackOverflowException invoking isSet on a static DataObject with a 
> dynamically-added property
> --
>
> Key: TUSCANY-1484
> URL: https://issues.apache.org/jira/browse/TUSCANY-1484
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
> Fix For: Java-SDO-1.1
>
> Attachments: tuscany-sdo.TUSCANY-1484.patch
>
>
> I have a Type and a corresponding statically-generated class. At runtime, I 
> dynamically add an add'l Property to this Type using 
> SDOUtil.createProperty(). Then, when I invoke 
> dataObjectInstance.isSet(dynamicallyAddedProperty), the  
> StackOverflowException listed below is generated:
> > java.lang.StackOverflowError
> > at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135)
> >
> >
> > at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821)
> > at org.apache.tuscany.sdo.impl.DataObjectBase.
> > eStaticClass(DataObjectBase.java:378)
> > at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
> > eClass(ExtensibleDataObjectImpl.java:118)
> > at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
> > eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87)
> > at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
> > eIsSet(BasicEObjectimpl.java:815)
> >
> > at
> org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
> >
> > at
> org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
> >
> > at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
> >
> >
> > at
> org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
> > at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
> > eIsSet(BasicEObjectimpl.java:818)
> > at
> org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
> > at
> org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
> > ...
> > at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
> >
> > at
> org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
> >
> > at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
> > eIsSet(BasicEObjectimpl.java:818)
> >
> > at
> org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
> >
> > at
> org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
> >
> > ...
> >
> Frank's characterization of the problem is included below.
> - Original Message 
> From: Frank Budinsky <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Thursday, July 26, 2007 3:03:15 PM
> Subject: Re: How to add Property to an XSDHelper-defined Type
> Since the properties start at 0, the extra property number should be equal
> to INTERNAL_PROPERTY_COUNT. That looks right.
> The StackOverflowException problem looks to me to be caused by the fact
> that the generated methods like isSet(int) are expected to find the
> property and only call super in the dynamic case. In your case, the
> property isn't statically handled, so it eventually calls
> DataObjectBase.eIsSet():
>   public boolean eIsSet(int featureID)
>   {
> if (isDynamic())
> {
>   return super.eIsSet(internalConvertIndex(featureID));
> } else
> {
>   return isSet(internalConvertIndex(featureID));
> }
>   }
> which will recursively call isSet() again because isDynamic() returns
> false. Somehow the code needs to be changed so that the dynamic property
> also causes it to go down the isDynamic() path.
> Actually, this eIsSet() method looks fishy to me regardless. First, the
> call to internalConvertIndex(featureID) for the call to super.eIsSet()
> looks wrong to me. I think it should be just featureID. The super call is
> expecting the internal (EMF) number, not the converted SDO number. Second,
> even in the dynamic sublass case (which this is supposed to be handling, I
> think that a client call to eIsSet() won't work, because it won't ever go
> down the isSet() patch which handles the static properties (in the base
> class(es)).
> I think the isDynamic() part of this method should be removed and instead
> t

[jira] Updated: (TUSCANY-1293) SDO does not work with OSGi

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1293:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-1.1
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Con

[jira] Updated: (TUSCANY-1397) createDataObject() throws NPE if property does not exist

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1397:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> createDataObject() throws NPE if property does not exist
> 
>
> Key: TUSCANY-1397
> URL: https://issues.apache.org/jira/browse/TUSCANY-1397
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Reporter: Andy Grove
> Fix For: Java-SDO-1.1
>
> Attachments: tuscany1397-v2.patch, tuscany1397.patch
>
>
> Calling createDataObject( "foo" ) where the data object's type does not 
> define a property "foo" causes a null pointer exception in 
> DataObjectUtil.createDataObject(DataObject dataObject, Property property, 
> Type type) because it attempts to call property.isContainment without 
> checking if the property is null.
> Calling createDataObject( "foo" ) on an open type should create an on-demand 
> property. If the type is not open and the property does not exist then an 
> exception should be thrown.
> Thanks,
> Andy.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1272) CrudWithChangeHistory test case fails as it's not finding the deleted object in the changeSummary

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1272:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> CrudWithChangeHistory test case fails as it's not finding the deleted object 
> in the changeSummary
> -
>
> Key: TUSCANY-1272
> URL: https://issues.apache.org/jira/browse/TUSCANY-1272
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Luciano Resende
>Assignee: Luciano Resende
> Fix For: Java-SDO-1.1
>
>
> Looks like DAS is not finding the deleted object in the changeSummary to 
> remove from the DB
> testDeleteAndCreate(org.apache.tuscany.das.rdb.test.CrudWithChangeHistory)  
> Time elapsed: 0.266 sec  <<< FAILURE!
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertFalse(Assert.java:34)
> at junit.framework.Assert.assertFalse(Assert.java:41)
> at 
> org.apache.tuscany.das.rdb.test.CrudWithChangeHistory.testDeleteAndCreate(CrudWithChangeHistory.java:83)
> at 
> org.apache.tuscany.das.rdb.test.CrudWithChangeHistory.testDeleteAndCreate(CrudWithChangeHistory.java:83)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at 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 junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at 
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
> at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1084:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Java Serialization: The Type definition is overwritten in the registry within 
> the same scope
> 
>
> Key: TUSCANY-1084
> URL: https://issues.apache.org/jira/browse/TUSCANY-1084
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SCA-M2
> Environment: All
>Reporter: Hasan Muhammad
> Fix For: Java-SDO-1.1
>
> Attachments: JavaSerializeDeserializeTestCase.java
>
>
> When a DataObject is serialized using the java serialization ( 
> ObjectOutputStream.writeObject) and deserialized back using 
> ObjectInputStream.readObject, the types of the two dataobjects do not match, 
> even though this all in the same scope ( global in this case ).
> During deserialization, it seems that the type of the dataobject cannot be 
> found, and it is creating the type again and simply overwrites the previously 
> registered type. This results in the dataobjects getting different types and 
> the test case fails. 
> There is another issue here, which is that currently there seems to be no way 
> to provide a scope when using these java serialization methods. For instance, 
> when using XMLHelper, you can get a scope defined XMLHelper. But how do you 
> do this when you are using the java serialization methods ? If you want me to 
> open another Jira for this i will.
> Hasan

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1079) Possible error in XSDSerialization tests

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1079:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Possible error in XSDSerialization tests
> 
>
> Key: TUSCANY-1079
> URL: https://issues.apache.org/jira/browse/TUSCANY-1079
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-SDO-Next
>Reporter: Andy Grove
> Fix For: Java-SDO-1.1
>
>
> The current test cases are expecting 2 types to be created from the following 
> schema but does not contain assertions about what those types should look 
> like. I would expect this schema to create only one type 
> (http://www.example.com/simple#Quote) and one open content property 
> (stockQuote) of that type. What other type should be created?
> Thanks,
> Andy.
>targetNamespace="http://www.example.com/simple";
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
>   xmlns:simple="http://www.example.com/simple";> 
>   
>
>
>
>   
>   
>   
>   
>   
>   
>   
>   
>maxOccurs="unbounded"/>
>
>
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1006:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
> --
>
> Key: TUSCANY-1006
> URL: https://issues.apache.org/jira/browse/TUSCANY-1006
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: Sun JDK 1.4.2_11, 2-CPU server
>Reporter: Ron Gavlin
>Priority: Critical
> Fix For: Java-SDO-1.1
>
> Attachments: tuscany-sdo-impl.TUSCANY-1006.patch
>
>
> I have an application in which multiple threads access a shared 
> ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() 
> repeatedly. This causes one or more of the threads to enter an infinite 
> "while (true) -" loop in HashMap.get(Object) with the following stack trace:
> HashMap.get(Object) line: 323
> ChangeSummaryImpl.getOldValues(DataObject) line: 481
> ...
> I suspect this occurs because the access to HashMap cachedSDOObjectChanges is 
> not synchronized. 
> I have been unable as of yet to create a simple test case that demonstrates 
> the problem. In the meantime, I will try to implement a short-term fix by 
> changing line 93 of ChangeSummaryImpl 
> from
> protected HashMap cachedSDOObjectChanges = new HashMap();
> to
> protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new 
> HashMap());
> I will let you know if that fixes the problem. Any insight or assistance you 
> can offer concerning this problem is appreciated. This is a show-stopper 
> problem for us.
> Regards,
> - Ron

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-612) Java SDO Overview doc doesnt address setting of M2_REPO variable

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-612:


Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Java SDO Overview doc doesnt address setting of M2_REPO variable
> 
>
> Key: TUSCANY-612
> URL: https://issues.apache.org/jira/browse/TUSCANY-612
> Project: Tuscany
>  Issue Type: Bug
>  Components: Website
>Affects Versions: Java-SCA-M2
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-1.1
>
>
> when initializing a new eclipse environment as per the instructions in the 
> java sdo overview,  the eclipse projects generated by the mvn eclipse:eclipse 
> commands don't build until the M2_REPO variable is set.  This needs 
> describing in the docvument 
> (instruction outline --  right click a project, properties, build path, 
> libraries,  click a library with M2_REPO var referenced, edit, variable, 
> folder, browse to repository (on windows this is c:\Documents and 
> Settings\\.m2\repository) and set the variable)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-257:


Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> recently added file Interface2JavaGenerator.java is not compatible with JDK 
> 1.4
> ---
>
> Key: TUSCANY-257
> URL: https://issues.apache.org/jira/browse/TUSCANY-257
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: all
>Reporter: Paul Golick
> Fix For: Java-SDO-1.1
>
> Attachments: 257.patch, newFiles.jar, 
> patchInterface2JavaGenerator.txt, patchUpdated.txt
>
>
> Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
> java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
> that the portion of Interface2JavaGenerator that uses ParameterizedType and 
> Type is not needed for Java 1.4 classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1498) Improve SubstitutionValuesTestCase

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1498:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Improve SubstitutionValuesTestCase
> --
>
> Key: TUSCANY-1498
> URL: https://issues.apache.org/jira/browse/TUSCANY-1498
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: tuscany-sdo-impl.TUSCANY-1498.patch
>
>
> Improve SubstitutionValuesTestCase. Will attach a patch in the near future.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1468) Use HelperContext for scope in Tuscany API

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1468:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Use HelperContext for scope in Tuscany API
> --
>
> Key: TUSCANY-1468
> URL: https://issues.apache.org/jira/browse/TUSCANY-1468
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-1.1
>
> Attachments: 1468_sdo_part.patch
>
>
> TUSCANY-1429 contained a fix for the 1.0-incubating relese of SDO that 
> altered the previously unreleased Tuscany APIs to use the HelperContext as a 
> scope argument rather than a TypeHelper, see ...
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20388.html
> This JIRA opened to cover the equivalent change in the trunk

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1483) Static SDO generator: problem with elements named internal*

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1483:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Static SDO generator: problem with elements named internal*
> ---
>
> Key: TUSCANY-1483
> URL: https://issues.apache.org/jira/browse/TUSCANY-1483
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-beta1
>Reporter: Daniel Peter
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 1483-withTestCase.patch, 
> 1483-withTestCaseInToolsTest.patch, 1483.patch, test1483.xsd
>
>
> Hi,
> I run into a problem with the static generated SDOs, when having a xsd with 
> the following two elements:
> 
> 
> In the generated Impl class this leads twice to the same constant 
> INTERNAL_ABC.
> The xsd elements might simply be renamed in order to avoid this clash, but 
> there might be situations where this is not possible. 
> The generator could use a different, less probable prefix (e.g. ___INTERNAL_).
> Thanks, Daniel.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1399) Generate SDO test classes using maven-sdo-plugin

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1399:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Generate SDO test classes using maven-sdo-plugin
> 
>
> Key: TUSCANY-1399
> URL: https://issues.apache.org/jira/browse/TUSCANY-1399
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Reporter: Ron Gavlin
>Priority: Minor
> Fix For: Java-SDO-1.1
>
>
> Tuscany needs a better way to test the various options supported by the 
> XSD2JavaGenerator. The first step is to code-generate test classes on the fly 
> using the maven-sdo-plugin rather than managing code-generated classes 
> directly within SVN. Then a significant number of the same tests could be run 
> multiple times using different options passed to the maven-sdo-plugin.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1283) Better organization of the interfaces and classes in the SDO Java project

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1283:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Better organization of the interfaces and classes in the SDO Java project
> -
>
> Key: TUSCANY-1283
> URL: https://issues.apache.org/jira/browse/TUSCANY-1283
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Reporter: Frank Budinsky
> Fix For: Java-SDO-1.1
>
>
> Currently, there is no clean separation between client API vs. implementation 
> (internal) classes. There's also no separation between the EMF-dependent and 
> independent parts of the RT.
> We have been recommending clients stick to standard SDO APIs (from the spec) 
> and for anything else use class SDOUtil, which is where we put all the 
> required extensions that people have requested. One other interface, 
> XMLStreamHelper (for working with StAX streams) is the only other interface 
> in Tuscany that clients are expected to use directly.
> So, clients that are only using standard SDO APIs, SDOUtil, and 
> XMLStreamHelper, should be unaffected by the reorganization for now, because 
> we will keep deprecated versions of SDOUtil and XMLStreamHelper around for a 
> while, but we would like to move them to a better package and have clients 
> gradually move to the new ones.
> Here is the concrete plan:
> package org.apache.tuscany.sdo.api (all client API will be under this package)
>   SDOUtil (new one)
>   XMLStreamHelper (new one)
>   other new things ...
> package org.apache.tuscany.sdo.rtemf (EMF-based runtime implementation 
> classes)
>   subset of existing classes (most of them) that have EMF dependencies
>   (these are existing packages just moved down one level, e.g., 
> org.apache.tuscany.sdo.helper -> org.apache.sdo.tuscany.sdo.rtemf.helper)
> package org.apache.tuscany.sdo.rtlib (common runtime implementation classes)
>   subset of existing classes that have no EMF dependencies
> package org.apache.tuscany.sdo.util (deprecated)
>   SDOUtil (deprecated - clients should switch to 
> org.apache.tuscany.sdo.api.SDOUtil)
> package org.apache.tuscany.sdo.helper (deprecated)
>   XMLStreamHelper (deprecated - clients should switch to 
> org.apache.tuscany.sdo.api.XMLStreamHelper)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1063) Improve diagnostics running XSD2JavaGenerator against bad schema

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1063:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Improve diagnostics running XSD2JavaGenerator against bad schema
> 
>
> Key: TUSCANY-1063
> URL: https://issues.apache.org/jira/browse/TUSCANY-1063
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Affects Versions: Java-SCA-M2
>Reporter: Scott Kurz
>Priority: Minor
> Fix For: Java-SDO-1.1
>
>
> I gave an invalid XSD file to the XSD2JavaGenerator and had to use the 
> debugger to figure out the problem.
> It might be nice to do a printStackTrace() on any exception before throwing 
> out of main().
> Also it might be good to print out simple error messages in the cases that:
>  a) the usage was correct but the specified file can't be read
>  b) the file can be read but there is no valid schema found
> As a sample of the latter here is my invalid schema 
> http://helloworld"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" 
> targetNamespace="http://helloworld";>
>  
> 
> 
> 
> 
>  
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-193) Fix eclipse warnings for sdo/tools

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-193:


Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Fix eclipse warnings for sdo/tools
> --
>
> Key: TUSCANY-193
> URL: https://issues.apache.org/jira/browse/TUSCANY-193
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Reporter: Daniel Kulp
>Assignee: Frank Budinsky
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: sdo.patch
>
>
> Very small and minor patch to the sdo/tools section to remove the last 
> eclipse warning in there.   Also patches one file in sdo/impl.   The only 
> eclipse warning left in there is use of a deprecated API.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1527:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Allow for custom data binding of DataObjects in a Swing UI
> --
>
> Key: TUSCANY-1527
> URL: https://issues.apache.org/jira/browse/TUSCANY-1527
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Reporter: bert.robben
> Fix For: Java-SDO-1.1
>
> Attachments: agfasdoui.tar.gz, com.zip
>
>
> We're developing 3-tier applications with a swing client, JBoss app server 
> and a couple of databases in the back-end. On the client side we use sdo 
> objects as model objects for our UI. As such, we need a mechanism for binding 
> our objects to the UI controls such that changes in the objects are reflected 
> in the UI and vice versa.
> At the moment, there is no real standard for data binding and many different 
> implementations exist. As such, it would not be a good idea to build support 
> for this directly into the sdo core. Ideally, the sdo core would allow 
> implementations supporting data binding to be added as extensions [an 
> extension as in jar, module, bundle, component, ...]. This is a request for 
> supporting this in Tuscany SDO.
> -
> For our applications, we developed our own implementation of the sdo 
> specification. This implementation is designed to support that kind of 
> extensions. In the rest of this description, I'd like to show more details on 
> our implementation to make this more clear and to serve as food for a 
> possible discussion.
> Our sdo core module defines the abstract class AbstractPartialDataObject 
> implementing DataObject. This class (together with its superclasses) 
> implements the majority of the bevahiour of DataObject. This includes 
> bi-directional property updates, type-safe properties, containment, ... It 
> doesn't implement however the basic access to property values.
> Here's a code fragment.
> public abstract class AbstractPartialDataObject extends AbstractDataObject 
> implements PartialDataObject {
>   protected abstract Object basicGet(Property property);
>   
>   protected abstract void basicSet(Property property, Object value);
>   
>   public Object get(Property property) { ... }
>   public void set(Property property, Object value) { ... }
>...
> }
> The sdo core module also provides a non-abstract class 
> DataObjectImplementation that provides a simple implementation of this 
> abstract behaviour where the property values are stored in an ArrayList.
> On top of that we defined an extension that deals with our UI requirements. 
> Our UI is based on a proprietary UI framework. This framework has the 
> following requirements:
> - single valued properties should be exposed as XObservables. An XObservable 
> is a kind of ValueModel that provides access to a value (get/set) and also 
> allows for registration of change listeners
> - multi valued properties should be exposed as ListModel instances. A 
> ListModel is a proprietary class (a bit similar to the javax.swing.ListModel) 
> that provides List functionality and also allows for change listeners
> - the data object itself should allow registration of attribute change 
> listeners that are notified each time a property changes   
> The extension implements these requirements by providing an appropriate 
> subclass ObservableDataObject of AbstractPartialDataObject. The only other 
> pieces of code needed in the extension is an appropriate implementation of 
> DataFactory and a wrapper to deal with the differences between ListModel and 
> List. 
> Here's the class with the most important code snippets.
> public class ObservableDataObject extends CompositePartialDataObject 
> implements  {
> private XObservable[] properties;
> 
> protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
> super(type);
> this.properties = new XObservable[type.getProperties().size()];
> for (int i = 0; i < properties.length; i++) {
> initializeProperty(type.getProperty(i));
> }
> }
>   private XObservable initializeProperty(Property prop) {
>   XObservable observable = 
> XObservableFactory.create(prop.getType().getInstanceClass(), this);
>   if (prop.isMany()) {
>   observable.init(new DataObjectListModel(this, prop));
>   }
&g

[jira] Updated: (TUSCANY-1128) Support attribute and element with same name

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1128:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> Support attribute and element with same name
> 
>
> Key: TUSCANY-1128
> URL: https://issues.apache.org/jira/browse/TUSCANY-1128
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Yang ZHONG
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 1128.patch, 1128.patch, 
> DifferAttrFromElementTestCase.java, dupelement.xsd, dupelement.xsd, 
> DupElementTestCase.java, DupElementTestCase.java
>
>
> To support attribute and element with same name within one Type such as
>   
> 
>   
> 
> 
>   
> and using "@property" to access attribute and "property" to access element.
> This is to support OTA standard schema used in the travel industry.
> "@property" notation comes from XPath:
> http://www.w3.org/TR/xpath#path-abbrev

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1355) DAS-RDB does not support Oracle or SqlServer well

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1355.
--

Resolution: Fixed

Based on the last comment from wangful, marking this as resolved.

> DAS-RDB does not support Oracle or SqlServer well
> -
>
> Key: TUSCANY-1355
> URL: https://issues.apache.org/jira/browse/TUSCANY-1355
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-M2
> Environment: DAS-RDB to access the database of Oracle
>Reporter: wangful
> Fix For: Java-DAS-Next
>
>
> I have used the following simple codes to use DAS to access an Oracle 
> database.
>   //String url = 
> "jdbc:db2j:D:/RAD6/runtimes/base_v6/cloudscape/DAS";
>   String url = "jdbc:oracle:thin:wcs/wcs1@//raptor08:1521/g10";
>   String query = "select * from MYCUSTOMER";
>   String query_result="";
>   Connection conn = null;
>   //  Class.forName("com.ibm.db2j.jdbc.DB2jDriver").newInstance();
>   DriverManager.registerDriver(new 
> oracle.jdbc.driver.OracleDriver());
>   conn = DriverManager.getConnection(url);
>   conn.setAutoCommit(false);
>DAS das = 
> DAS.FACTORY.createDAS(conn);
>   Command readStores = das.createCommand(query);
>   DataObject root = (DataObject)readStores.executeQuery();
>   DataObject cus1 = root.getDataObject("MYCUSTOMER[1]");
>   
>   System.out.println(root.getInt("MYCUSTOMER[1]/ID"));
>   System.out.println(root.getString("MYCUSTOMER[1]/NAME"));
> It will caused the following error: 
> Exception in thread "main" java.lang.IllegalArgumentException: Class 
> 'DataGraphRoot' does not have a feature named 'MYCUSTOMER'
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1804)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2367)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getProperty(DataObjectImpl.java:1287)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2054)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2161)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1940)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1860)
>   at 
> org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:744)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216)
>   at 
> org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:326)
>   at TestDAS.main(TestDAS.java:47)
> But the same code and same config will work well for  cloudscape database.
> There are also some other problems for Oracle, seems DAS can't work for 
> oracle.
> Will someone look into this problem?
> Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1295) Resolve Memory Leaks in RDB DAS source and test cases code

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar closed TUSCANY-1295.


Resolution: Duplicate

After TUSCANY-1872 applied verified that memory leaks issue is fixed. So 
closing this JIRA as duplicate

> Resolve Memory Leaks in RDB DAS source and test cases code
> --
>
> Key: TUSCANY-1295
> URL: https://issues.apache.org/jira/browse/TUSCANY-1295
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>    Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
> Attachments: JIRA1295_952_May21.txt, JIRA1295_952_May21.txt, 
> JIRA1295_952_May22.txt, JProfReportsMay21.zip, JProfReportsMay21.zip
>
>
> It is seen that as the number of test cases in RDB DAS JUnit testing 
> increase, the memory consumption increase
> and beyond a certail limit, there is OutOfMemory exception for heap memory. 
> This JIRA is created to elaborate the 
> cause-solution for this and provide the fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568889#action_12568889
 ] 

Amita Vadhavkar commented on TUSCANY-1293:
--

yes, it's fixed now.

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.re

[jira] Resolved: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-257.
-

Resolution: Fixed

resolved at rev 620782

> recently added file Interface2JavaGenerator.java is not compatible with JDK 
> 1.4
> ---
>
> Key: TUSCANY-257
> URL: https://issues.apache.org/jira/browse/TUSCANY-257
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: all
>Reporter: Paul Golick
> Fix For: Java-SDO-Next
>
> Attachments: 257.patch, newFiles.jar, 
> patchInterface2JavaGenerator.txt, patchUpdated.txt
>
>
> Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
> java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
> that the portion of Interface2JavaGenerator that uses ParameterizedType and 
> Type is not needed for Java 1.4 classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568085#action_12568085
 ] 

Amita Vadhavkar commented on TUSCANY-1293:
--

I am not clear about 106 outputs , but I see the same failure in [continuum] 
BUILD FAILURE: Apache Tuscany SDO Implementation Project latest mail.
Will you please check the details there?

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at 
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at 
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at 
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at 
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at 
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccesso

[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568078#action_12568078
 ] 

Amita Vadhavkar commented on TUSCANY-1293:
--

---
Test set: org.apache.tuscany.sdo.test.osgi.OSGiTestCase
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 8.469 sec <<< 
FAILURE!
test(org.apache.tuscany.sdo.test.osgi.OSGiTestCase)  Time elapsed: 8.438 sec  
<<< ERROR!
org.osgi.framework.BundleException: Activator start error.
at org.apache.felix.framework.Felix._startBundle(Felix.java:1580)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1470)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:354)
at 
org.apache.tuscany.sdo.test.osgi.OSGiTestCase.test(OSGiTestCase.java:172)
Caused by: junit.framework.AssertionFailedError: expected:<0> but was:<106>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at 
org.apache.tuscany.sdo.test.osgi.TestBundleActivator.runSDOTests(TestBundleActivator.java:63)
at 
org.apache.tuscany.sdo.test.osgi.TestBundleActivator.start(TestBundleActivator.java:40)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1536)
... 29 more

Please see the exception during mvn

> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException.  I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
>   provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
>   HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
>   implName = getImplementationName(cl);
> which ends up calling:
>   InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME = 
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in 
> the API bundle.  It exists in the IMPL bundle and since you are using the 
> class loader from the API bundle, it won't work.  
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as 
>   return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException.  Again, this is because you are 
> trying to load a class outside the bundle with the wrong class loader.
>  tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem 
> (although I believe this is specific to eclipse and won't work for OSGi in 
> general), but when HelperProvider is initializing, you get the following 
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at 
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at 
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassIn

[jira] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-257:


Attachment: 257.patch

have used Paul's work and created 257.patch. please review

> recently added file Interface2JavaGenerator.java is not compatible with JDK 
> 1.4
> ---
>
> Key: TUSCANY-257
> URL: https://issues.apache.org/jira/browse/TUSCANY-257
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
> Environment: all
>Reporter: Paul Golick
> Fix For: Java-SDO-Next
>
> Attachments: 257.patch, newFiles.jar, 
> patchInterface2JavaGenerator.txt, patchUpdated.txt
>
>
> Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and 
> java.lang.reflect.Type that were added in Java 5 for generics.  It appears 
> that the portion of Interface2JavaGenerator that uses ParameterizedType and 
> Type is not needed for Java 1.4 classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1838.
--

Resolution: Fixed

Marking resolved based on the previous comment. If required please provide a 
test case which demonstrates the failure and reopen the JIRA if necessary.

> HelperContext provided to createObjectOutputStream is inadvertantly ignored
> ---
>
> Key: TUSCANY-1838
> URL: https://issues.apache.org/jira/browse/TUSCANY-1838
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SDO-1.0
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-Next
>
>
> Ron Gavlin reported in http://www.mail-archive.com/[EMAIL 
> PROTECTED]/msg01884.html an issue with HelperContexts being unavailable 
> during marshalling.  I feel sure that this is due to this piece of code here 
> in HelperProviderBase::ResolvableImpl#writeDataObject
> XMLHelper xmlHelperLocal = xmlHelper;
> if(objectOutput instanceof SDOObjectInputStream)
> {
> xmlHelperLocal = 
> ((SDOObjectInputStream)objectOutput).getHelperContext().getXMLHelper();
> }
> xmlHelperLocal.save(dataObject, "commonj.sdo", "dataObject", 
> gzipOutputStream);
> where the instanceof test and cast should be to SDOObjectOutputStream

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1360) New SDOUtil: Getting the enumeration facet

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1360.
--

Resolution: Fixed

1360-Amita.patch applied to rev.  619858

> New SDOUtil: Getting the enumeration facet
> --
>
> Key: TUSCANY-1360
> URL: https://issues.apache.org/jira/browse/TUSCANY-1360
> Project: Tuscany
>  Issue Type: Wish
>  Components: Java SDO Tools
>Reporter: Christian Landbo Frederiksen
>    Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 1360-Amita.patch, 1360-Frank.patch
>
>
> This has been discussed in the lists: 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg01095.html
> I do this:
>   public static List getEnumerationFacet(Type type) {
>return
>  ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
>}
> Kelvin suggested another way
> I think you should be able to do
> type.getInstanceProperties() and find the Property called "enumeration".
> Then you can get the enumerations using that Property.
> (see MetaDataInstancePropertiesTestCase [2])
> Having this encapsuled by the SDOUtil would be cool (but maybe overkill - you 
> decide)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[SDO Java] Pluggable SDOPackageRegistryDelegator and Tuscany-1459

[Amita Vadhavkar]

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

[jira] Commented: (TUSCANY-1831) Make SDOPackageRegistryDelegator pluggable

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566995#action_12566995
 ] 

Amita Vadhavkar commented on TUSCANY-1831:
--

I am not very sure, but there was some design discussion in Tuscany-1459 and 
the requirement in current JIRA and the topic of Tuscany-1459 can be having some
conflicts. I guess it will be better, if we can discuss this more on ML and 
come up with some exact code level suggestions about what can be done and what
can be the implications etc.  Let me start a ML thread and let us get some 
inputs from those involved in Tuscany-1459 and others.

> Make SDOPackageRegistryDelegator pluggable
> --
>
> Key: TUSCANY-1831
> URL: https://issues.apache.org/jira/browse/TUSCANY-1831
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> The current SDOPackageRegistryDelegator implementation assumes that a 
> standard, hierarchical classloader structure is present in the "hosting 
> environment". BEA WebLogic, for example, uses an unusual "change aware" 
> classloading scheme which does not meet the expectations of the 
> SDOPackageRegistryDelegator. Prior to Tuscany SDO 1.0, I was able to 
> work-around this former EMF problem by setting the EMF JVM property 
> "org.eclipse.emf.ecore.EPackage.Registry.INSTANCE". In Tuscany SDO 1.0, this 
> setting is no longer relevant. I would like to be able to plugin my own 
> SDOPackageRegistryDelegator implementation that provides a 
> non-classloader-aware registry, knowing full well the limitations of of this 
> implementation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1835) XSDHelper.getAppinfo() returns wrong result

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566505#action_12566505
 ] 

Amita Vadhavkar commented on TUSCANY-1835:
--

Please give more details,what constraints apply, what investigation led to 
conclusion about "appinfo". Thanks

> XSDHelper.getAppinfo() returns wrong result
> ---
>
> Key: TUSCANY-1835
> URL: https://issues.apache.org/jira/browse/TUSCANY-1835
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: WinXP
>Reporter: Fuhwei Lwo
>Assignee: Fuhwei Lwo
> Fix For: Java-SDO-Next
>
> Attachments: 1835.patch
>
>
> According to SDO 2.1 spec section 3.13 (The getAppinfo() methods return the 
> XML, starting from the specified source element.).  This means if we have an 
> annotation defined like below.
> 
>   
>   http://www.example.com/simple";>
>   fbnt
>   
>   
> 
> XSDHelper.getAppinfo() should return
> 
>   http://www.example.com/simple";>
>   fbnt
>   
> 
> Now it's returning the wrong result like below.
>   http://www.example.com/simple";>
>   fbnt
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2014) XMLDocument object's rootElement member not intialized properly

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566500#action_12566500
 ] 

Amita Vadhavkar commented on TUSCANY-2014:
--

Please comment on importance of this fix to be included in 1.1-incubating 
release (ongoing) and it will be very helpful if you can provide a patch for it.
-Regards

> XMLDocument object's rootElement member not intialized properly
> ---
>
> Key: TUSCANY-2014
> URL: https://issues.apache.org/jira/browse/TUSCANY-2014
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test2014.java
>
>
> This problem occurs during a roundtrip operation where a new SDO Type is 
> created, then an instance DO is created from that type.  That instance DO is 
> then serialized to an XML document.  Then, using XMLHelper.load(String), the 
> document is loaded into an XMLDocument object.  When that object is 
> inspected, the rootElement member is not set properly, implying there is 
> either something wrong with the serialization of the DO or the 
> deseriazliation of the xml document. 
> Investigation is underway.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1918) Support for dynamic containment

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566498#action_12566498
 ] 

Amita Vadhavkar commented on TUSCANY-1918:
--

This issue has a dependency on spec. waiting on that.

> Support for dynamic containment
> ---
>
> Key: TUSCANY-1918
> URL: https://issues.apache.org/jira/browse/TUSCANY-1918
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: bert.robben
> Fix For: Java-SDO-Next
>
>
> In SDO, the boundaries of a datagraph are defined by the containment 
> relation. Only objects which can be reached from the root object by following 
> properties that are contained are part of the datagraph. Containment is 
> defined at the type level.
> In cases where applications need to dynamically select what information they 
> want, this fixed containment relationship is an issue. For instance, suppose 
> in a medical context you have defined a number of types defines to represent 
> patients together with their clinical (e.g. procedures they have taken) and 
> administrative data (for instance their address). The type definition needs 
> to decide on the containment of the clinical and administrative data. However 
> it is hard to decide whether or not the administrative and clinical data 
> should be contained because some applications might only need clinical or 
> administrative data and others might need both. In cases where the type 
> system is large or where there are large volumes of data involved (for 
> instance in the example, procedures could have an associated pdf-report 
> property) this becomes a real issue.
> Current solutions within the SDO framework could be (for the interested, 
> there has been a mail thread about this a while ago in the user mailing list)
> - Each app shoud define its own type with an appropriate containment 
> relation. The downside of this is a proliferation of types.
> - The main types should not have any containment relations. Containment is 
> specified using a synthetic type. Think of this as a special list type that 
> contains its elements. The root of the datagraph then would be an instance of 
> such a list type. All instances that are needed should be put in this flat 
> list.
> I would like to propose an alternative solution. In this solution, 
> containment would not be specified at the type level. Whenever the boundary 
> of a datagraph is needed (for instance when an xml document it be generated 
> or a datagraph is to be exchanged between for instance a client and a 
> server), the application should provide appropriate information that 
> specifies exactly what is part of the graph and what not. This can be seen as 
> a select clause for sql, or even better as a set of fetch joins in Hibernate. 
> This would give the application control over exactly what it wants. In the 
> example for instance, the application can easily decide at each point whether 
> or not it would want the address information together with the patient data.
> This proposal would have a number of interesting implications.
> - What is the implication of this for cases where datagraphs are represented 
> as xml documents that should be according to an xml schema?
> - How to deal with links to objects that don't belong to the datagraph? One 
> strategy could be just to drop them. Another one to provide some kind of 
> proxy.
> Interested parties can have a look at our SDO implementation (see also JIRA 
> 1527 and 1493) where we try to support this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from and

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566497#action_12566497
 ] 

Amita Vadhavkar commented on TUSCANY-1327:
--

Fuhwei, please confirm if this issue is for wsdl2java or xsd2java. based on 
that need to decide component / release. 

> Generate static SDO APIs from wsdl files with type definition from 
>  and 
> ---
>
> Key: TUSCANY-1327
> URL: https://issues.apache.org/jira/browse/TUSCANY-1327
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SCA-Next
>
> Attachments: Bindings.wsdl, Messages.wsdl, Types.xsd
>
>
> Today, SDO codegen tool can recognize and parse  content to 
> generate static SDO APIs. However, it ignores  and 
> . This means if I have types defined in other wsdl files and 
> they are imported or included by  or  elements, 
> they won't never get generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-761) Support the ability to unregister all the SDO Types in a namespace

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566490#action_12566490
 ] 

Amita Vadhavkar commented on TUSCANY-761:
-

There is some discussion on Feb4,5,6 2008 IRCs, - here is the summary - what is 
the memory cost of having to init number of HelperContexts?
Each one has at constrcution an instance of all HElpers that require to manage 
their own state -- i.e. not CopyHelper or 
EqualityHelper,  but all the others . The state of each of these helpers is not 
large until you start registering types
so i think there would only be significant cost if there were  duplication in 
storage of metadata across typehelpers
so the problem with multiple HelperContexts would be when loading XML

Also, please let know if the issue mentioned in the JIRA still a requirement.

> Support the ability to unregister all the SDO Types in a namespace
> --
>
> Key: TUSCANY-761
> URL: https://issues.apache.org/jira/browse/TUSCANY-761
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Java-SCA-M2
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> Add an SDO lifecycle metadata Tuscany extension to unregister all the SDO 
> Types in a namespace. The suggested method is 
> SDOUtil.unregisterTypes(TypeHelper typeHelper, String namespace).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-67) ClassLoader issues with SDO

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566484#action_12566484
 ] 

Amita Vadhavkar commented on TUSCANY-67:


there has some work done in this area and JIRA is not clear on the particular 
issue. HelperContext came up after this issue. Some 
work done on DefaultHelperContext to work with thread local context. So, 
discuss and make appropriate comment

> ClassLoader issues with SDO
> ---
>
> Key: TUSCANY-67
> URL: https://issues.apache.org/jira/browse/TUSCANY-67
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation, Java Spec APIs
>Reporter: Jeremy Boynes
> Fix For: Java-SDO-Next
>
>
> The SDO spec makes extensive use of INSTANCE static fields on the helper 
> interfaces which results in a solution that is complex to use and error prone 
> in any environment where more than one ClassLoader is involved.
> We should work with the spec group to formulate a model that is easier for 
> people to use in today's more complex environments (including build 
> frameworks like Maven and Ant, IDE environments like Eclipse, server 
> environments like Tomcat and Geronimo, application frameworks like Spring, 
> etc. etc.). I will open a sub-task specfically for this.
> We should also ensure that the Tuscany implementation of SDO is easy to use 
> in these environments irrespective of what the spec says. We need to define a 
> set of APIs that make it easy to handle multiple type spaces in the same JVM 
> and/or ClassLoader without requiring the user to play tricks with the 
> Thread's context classloader (which they may not even have permission to do). 
> We should also ensure any usage of SDO by the SCA runtime uses these APIs, 
> reserving the default SDO type space for user applications.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1514) DataHelperImpl.toDate will report a NullPointerException

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1514.
--

Resolution: Fixed

Revision 564600 contains the code fix in DataHelperImpl.toDate() to check for 
null input. Also for test confirmation, 
I added testNullStringToDate() in DateConversionTestCase in rev. 618933

With this I am marking the JIRA resolved. 

> DataHelperImpl.toDate  will report a NullPointerException
> -
>
> Key: TUSCANY-1514
> URL: https://issues.apache.org/jira/browse/TUSCANY-1514
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
>Reporter: Leo Li
> Fix For: Java-SDO-Next
>
>
> Hi All , 
>   when I  read the data from a table , there is a Datetime field in the 
> table , if the datetime field'value is null , the SDO will produce a 
> NullPointException , Maybe this is a bug , and How to fixed it  ? 
>  
> Exception content as follow : 
>  
> 12:02:21,015 [main] ERROR [DasService]
> java.lang.NullPointerException
>  at
> org.apache.tuscany.sdo.helper.DataHelperImpl.toDate(DataHelperImpl.java:48)
>  at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createDateFromString(Mode
> lFactoryImpl.java:1931)
>  at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createFromString(ModelFac
> toryImpl.java:224)
>  at
> org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.createFromString(Fac
> toryBase.java:270)
>  at
> org.eclipse.emf.ecore.util.EcoreUtil.createFromString(EcoreUtil.java:2982)
>  at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getValue(FeatureChangeIm
> pl.java:428)
>  at
> org.apache.tuscany.sdo.impl.ChangeSummarySettingImpl.getValue(ChangeSummaryS
> ettingImpl.java:89)
>  at
> org.apache.tuscany.das.rdb.util.DataObjectUtil.restoreAttributeValues(DataOb
> jectUtil.java:74)
>  at
> org.apache.tuscany.das.rdb.util.DataObjectUtil.getRestoredCopy(DataObjectUti
> l.java:41)
>  at
> org.apache.tuscany.das.rdb.impl.DeleteOperation.(DeleteOperation.java:
> 34)
>  at
> org.apache.tuscany.das.rdb.impl.ChangeFactory.createDeleteOperation(ChangeFa
> ctory.java:77)
>  at
> org.apache.tuscany.das.rdb.impl.ChangeSummarizer.createChange(ChangeSummariz
> er.java:103)
>  at
> org.apache.tuscany.das.rdb.impl.ChangeSummarizer.loadChanges(ChangeSummarize
> r.java:80)
>  at
> org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute(ApplyChanges
> CommandImpl.java:64)
>  at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges(DASImpl.java:310)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566049#action_12566049
 ] 

Amita Vadhavkar commented on TUSCANY-1838:
--

See below analysis of what I understood so far - conclusion from that - 
Kelvin's fix in http://svn.apache.org/viewvc?rev=583095&view=rev
is correct even though it is irrelevant for the below as well as for Ron's test 
condition.

HelperProviderBase is abstract but HelperProviderImpl does provide required 
Helpers. When the call comes to 
Resolvable.writeExternal(ObjectOutput) and when target in Resolvable is set to 
a DataObject - 
HelperProvideBase.ResolvableImpl.writeDataObject(DataObject dataObject, 
ObjectOutput objectOutput) is called.
In this if DataObject(target) does not have a DataGraph and does not have a 
container, xmlHelperLocal is assigned
from instance member xmlHelper. As HelperProviderImpl does provide all Helpers, 
at this point xmlHelper should be
not null. Further as a special case, if ObjectOutput is instance of 
SDOObjectOutputStream, its HelperContext is used
and so xmlHelperLocal take value from it. But if ObjectOutput is not instance 
of SDOObjectOutputStream, the xmlHelper
already obtained from HelperProviderImpl will hold good. So it will be 
"available".  

To further verify this, I wrote a small test case like below - please note - 
quote.detach();//to make sure data graph and container are null

public void testWriteDataObject() throws Exception {
URL url = getClass().getResource("/simple.xsd");
InputStream inputStream = url.openStream();
XSDHelper.INSTANCE.define(inputStream, url.toString());
inputStream.close();

DataGraph dataGraph = SDOUtil.createDataGraph();
Type quoteType = dataGraph.getType("http://www.example.com/simple";, 
"Quote");
DataObject quote = dataGraph.createRootObject(quoteType);
quote.setString("symbol", "HP");
System.out.println("before detach:"+XMLHelper.INSTANCE.save(quote, 
"quote", "quote"));

quote.detach();//***to make sure data graph and container are null

System.out.println("after detach:"+XMLHelper.INSTANCE.save(quote, 
"quote", "quote"));

ByteArrayOutputStream compressedByteArrayOutputStream = new 
ByteArrayOutputStream();
GZIPOutputStream gzipOutputStream = new 
GZIPOutputStream(compressedByteArrayOutputStream);
XMLHelper.INSTANCE.save(quote, "commonj.sdo", "dataObject", 
gzipOutputStream);
gzipOutputStream.close(); // Flush the contents
System.out.println("byes in target DO..being 
written:"+compressedByteArrayOutputStream.toByteArray().length);

HelperProvider hp = HelperProvider.getInstance();
if(hp instanceof HelperProviderBase) {
HelperProviderBase hpb = (HelperProviderBase)hp;
Resolvable resolvable = hpb.resolvable(quote);

FileOutputStream fos = new FileOutputStream("c:/test123.txt");

ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);

resolvable.writeExternal(oos);
oos.flush();

byte[] writtenDOBytes = baos.toByteArray();
fos.write(writtenDOBytes);
fos.flush();
fos.close();

System.out.println("Reading Now...");

FileInputStream fis = new FileInputStream("c:/test123.txt");
ObjectInputStream ois = new ObjectInputStream(fis);
byte firstByte = ois.readByte();
System.out.println("firstByte:"+firstByte);
int nextInt = ois.readInt();
System.out.println("nextInt-length:"+nextInt);
int idx = 0;
byte[] readRemainingBytes = new byte[1000];

while(true) {
try{
readRemainingBytes[idx] = ois.readByte();
//System.out.println("read byte:"+idx);
idx++;
} catch(Exception e) {
//e.printStackTrace();
break;
}
}

String stringOfDO = new String(readRemainingBytes, 0, idx); 

System.out.println("stringOfDOBytes 
length:"+stringOfDO.length());  
}

}
*

Re: [Java SDO] getEncoding() during load() - issues + TUSCANY-1545

[Amita Vadhavkar]

Looks like there are 2 issues
1] with InputSource(reader) in JDK5 -> ignores pre-existing encoding and
sets it to ASCII
2] with null encoding (done by XMLDocument.setEncoding(null))in EMF -> give
NPE during save
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:242)

Not sure about the causes behind this and the correct solution but if by
using some workaround - JDK and
EMF issues can be isolated from Tuscany, one way could be -

In sdo-impl XMLHelperImpl,for load() variations accepting String as input,
do
ByteArrayInputStream bais = new ByteArrayInputStream(inputString.getBytes
());
and call from there- public XMLDocument load(InputStream inputStream, String
locationURI, Object options)
in the same class. This will use XMLDocumentImpl's load() variations which
accept InputStream
and so JDK 5 at least the result will retain correct encoding. And
inputString.getBytes()
will use System's default encoding to get the bytes. So other than
XMLHelperImpl.load(Reader inputReader, String locationURI, Object options)
no other call will reach
XMLDocumentImpl.load(Reader inputReader, String locationURI, Object
options).

Also, in org.apache.tuscany.sdo.helper.XMLDocumentImpl.save(
XMLDocumentImpl.java:232)
(from stack trace of NPE during null encoding case), Tuscany can default it
to UTF-8
like -
if(resource.getEncoding() == null) {
   resource.setEncoding("UTF-8");
}

Still the issues remain are -
1) JIRA-1545 is mandating UTF-8 encoding during save, so end user does not
have a way to save document
with any other encoding

2) Tuscany SDO Java does not support as of today passing
XMLResource.OPTION_ENCODING during save.

3) If EMF allows setEncoding(null), why it throws NPE during save on such a
XMLResource?

4) JDK5 and JDK6 difference in behavior and how Tuscany SDO Java will
support this? (My previous response
regd. InputSource() - Jan 29)

Regards,
Amita

On Jan 29, 2008 3:15 PM, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

> The getEncoding() issue I was facing was related to my env. JDK setting ,
> it was failing because it was set to JDK6
> when changed to JDK5 compile and runtime, getEncoding() succeeded.
>
> Also, below is a tailored version of testEncoding2() from Kelvin where I
> have tried to pinpoint the exact place of problem.
> Still not able to get the Bug ID from JDK 6 for this difference in
> behavior. Please also take note of the comment -
> VVIMP - substr was not giving UTF-8 -> sw.toString().substring(40); in
> testEncodingN() test case. And see the difference
> in
> System.out.println("noDeclDirect:" + noDeclDirect.getEncoding()+"\n");
> and
> System.out.println("noDeclDirect again:" + noDeclDirect.getEncoding
> ()+"\n");
>
> which highlights the fact that InputSource(inputstream) and
> InputSource(reader) behave differently in JDK5 and JDK6, where
> In JDK5, InputSource(InputStream) always yields correct output where as
> InputSource(reader) gives some hardcoded default
> behavior(ASCII).
> and In JDK6, InputSource(InputStream) as well as InputSource(reader)
> neglect the input and give some hardcoded default
> behavior(ASCII).
>
> Any clue?
>
> --
>   public void testEncodingN() throws IOException
>   {
>   TypeHelper types = hc.getTypeHelper();
>   Type stringType = types.getType("commonj.sdo", "String");
>   DataObject customerType = hc.getDataFactory().create("commonj.sdo",
> "Type");
>   customerType.set("uri", "http://example.com/simple";);
>   customerType.set("name", "Simple");
>   DataObject multiProperty = customerType.createDataObject
> ("property");
>   multiProperty.set("name", "name");
>   multiProperty.set("type", stringType);
>   types.define(customerType);
>   DataObject obj = hc.getDataFactory().create("
> http://example.com/simple";, "Simple");
>   obj.set("name", "John Smith");
>
>   ByteArrayOutputStream baos = new ByteArrayOutputStream();
>   hc.getXMLHelper().save(obj, "http://www.example.com/company"; ,
> "company", baos);
>   System.out.println("baos:"+baos);
>   System.out.println
> ("*");
>
>   ByteArrayInputStream bais = new ByteArrayInputStream(baos.toString
> ().getBytes());
>   XMLDocument xmlDoc = hc.getXMLHelper().load(bais);
>   System.out.println("xmlDoc:"+xmlDoc.getEncoding()+"\n");
>   System.out.printl

[jira] Resolved: (TUSCANY-2025) SDO Java Samples - minor commentary fixes

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-2025.
--

Resolution: Fixed

corrected all found issues

> SDO Java Samples - minor commentary fixes
> -
>
> Key: TUSCANY-2025
> URL: https://issues.apache.org/jira/browse/TUSCANY-2025
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2025) SDO Java Samples - minor commentary fixes

[Amita Vadhavkar (JIRA)]

SDO Java Samples - minor commentary fixes
-

 Key: TUSCANY-2025
 URL: https://issues.apache.org/jira/browse/TUSCANY-2025
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Samples
Affects Versions: Java-SDO-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
Priority: Minor
 Fix For: Java-SDO-Next




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1483) Static SDO generator: problem with elements named internal*

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1483.
--

Resolution: Fixed

patch applied at revision 615169

> Static SDO generator: problem with elements named internal*
> ---
>
> Key: TUSCANY-1483
> URL: https://issues.apache.org/jira/browse/TUSCANY-1483
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-beta1
>Reporter: Daniel Peter
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 1483-withTestCase.patch, 
> 1483-withTestCaseInToolsTest.patch, 1483.patch, test1483.xsd
>
>
> Hi,
> I run into a problem with the static generated SDOs, when having a xsd with 
> the following two elements:
> 
> 
> In the generated Impl class this leads twice to the same constant 
> INTERNAL_ABC.
> The xsd elements might simply be renamed in order to avoid this clash, but 
> there might be situations where this is not possible. 
> The generator could use a different, less probable prefix (e.g. ___INTERNAL_).
> Thanks, Daniel.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-2011.
--

Resolution: Fixed

completed at revision 616270

> include apache headers in xmls and xsds without causing test case failures
> --
>
> Key: TUSCANY-2011
> URL: https://issues.apache.org/jira/browse/TUSCANY-2011
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation, Java SDO Tools
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
>
> there are total 7 files in sdo-impl and 3 files in tools-test which can 
> contain Apache headers without any test case failures, so do so for a 
> successful RAT report

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures

[Amita Vadhavkar (JIRA)]

include apache headers in xmls and xsds without causing test case failures
--

 Key: TUSCANY-2011
 URL: https://issues.apache.org/jira/browse/TUSCANY-2011
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation, Java SDO Tools
Affects Versions: Java-SDO-Next
Reporter: Amita Vadhavkar
Priority: Minor
 Fix For: Java-SDO-Next


there are total 7 files in sdo-impl and 3 files in tools-test which can contain 
Apache headers without any test case failures, so do so for a successful RAT 
report

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1531) Java SDO Documentation page should be updated to default website stype/design

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1531.
--

Resolution: Fixed

After some content updates as shown in 
http://cwiki.apache.org/TUSCANY/sdo-java-documentation-menu.html, the issues 
mentioned in this JIRA seem to be resolved.

> Java SDO Documentation page should be updated to default website stype/design
> -
>
> Key: TUSCANY-1531
> URL: https://issues.apache.org/jira/browse/TUSCANY-1531
> Project: Tuscany
>  Issue Type: Bug
>  Components: Website
>Affects Versions: Java-SDO-Next
>Reporter: Luciano Resende
> Fix For: Java-SDO-Next
>
>
> The default left side menus are missing or wrong
> 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.
> User guide has wrong styles : 
> http://incubator.apache.org/tuscany/sdo-java-user-guide.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Java SDO] getEncoding() during load() - issues + TUSCANY-1545

[Amita Vadhavkar]

I am making this a separate thread and referring it in
http://www.mail-archive.com/[EMAIL PROTECTED]/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=emf&version=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 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.e

[jira] Resolved: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-2009.
--

Resolution: Fixed

Applied patch at revision 614489

> Java SDO's EqualityHelper doesn't compare Bytes values correctly
> 
>
> Key: TUSCANY-2009
> URL: https://issues.apache.org/jira/browse/TUSCANY-2009
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: 2009.patch, Test2009.java
>
>
> Comparison of two Bytes values fails when it should succeed.  The test for 
> equality passes through the EqualityHelperImpl.equal method.  In that method, 
> the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, 
> EAttribute).  For a simple type, it defers to java's '==' operator.  So, two 
> different object arrays are being compared, not for their contents, but 
> rather if they are the same object.  Attached is a test case which 
> demonstrates this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561598#action_12561598
 ] 

Amita Vadhavkar commented on TUSCANY-2009:
--

The patch looks fine to me.

There is another pre-existing issue in the current SDO code base. Please see - 
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02434.html, is this a known 
issue and is there a solution to it?  



> Java SDO's EqualityHelper doesn't compare Bytes values correctly
> 
>
> Key: TUSCANY-2009
> URL: https://issues.apache.org/jira/browse/TUSCANY-2009
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: 2009.patch, Test2009.java
>
>
> Comparison of two Bytes values fails when it should succeed.  The test for 
> equality passes through the EqualityHelperImpl.equal method.  In that method, 
> the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, 
> EAttribute).  For a simple type, it defers to java's '==' operator.  So, two 
> different object arrays are being compared, not for their contents, but 
> rather if they are the same object.  Attached is a test case which 
> demonstrates this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-2007.
--

Resolution: Fixed

completed at revision 614190

> SDO Samples - fix sampleProgramContents.html's Firefox display issue
> 
>
> Key: TUSCANY-2007
> URL: https://issues.apache.org/jira/browse/TUSCANY-2007
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 2007.patch
>
>
> By 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. Without it, it was displaying as html text on the 
> browser.
>  title="http://www.w3.org/TR/html4/loose.dtd";>" 
> class="link">http://www.w3.org/TR/html4/loose.dtd";>
> So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
> above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly

[Amita Vadhavkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561294#action_12561294
 ] 

Amita Vadhavkar commented on TUSCANY-2009:
--

http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/util/EcoreUtil.EqualityHelper.html
specifies that Java equality is followed and in Java below bt1 is not equal to 
bt2.
byte[] bt1 = new byte[]{120, 80, -40};
byte[] bt2 = new byte[]{120, 80, -40};
if(bt1.equals(bt2)) {
   //false
}

In SDO Impl, super.haveEqualAttribute(eObject1, eObject2, attribute);  is 
called. So to make meaningful comparisons, instead of calling super viz. EMF 
EcoreUtil.EqualityHelper(), will meaningful equality check be needed inside SDO 
Impl itself?

Regards,
Amita

> Java SDO's EqualityHelper doesn't compare Bytes values correctly
> 
>
> Key: TUSCANY-2009
> URL: https://issues.apache.org/jira/browse/TUSCANY-2009
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test2009.java
>
>
> Comparison of two Bytes values fails when it should succeed.  The test for 
> equality passes through the EqualityHelperImpl.equal method.  In that method, 
> the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, 
> EAttribute).  For a simple type, it defers to java's '==' operator.  So, two 
> different object arrays are being compared, not for their contents, but 
> rather if they are the same object.  Attached is a test case which 
> demonstrates this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2007:
-

Attachment: 2007.patch

changed DocumentSamples.java and 
distribution\src\main\release\bin\samples\sampleProgramContents.html. 

> SDO Samples - fix sampleProgramContents.html's Firefox display issue
> 
>
> Key: TUSCANY-2007
> URL: https://issues.apache.org/jira/browse/TUSCANY-2007
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>    Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 2007.patch
>
>
> By 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. Without it, it was displaying as html text on the 
> browser.
>  title="http://www.w3.org/TR/html4/loose.dtd";>" 
> class="link">http://www.w3.org/TR/html4/loose.dtd";>
> So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
> above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

SDO Samples - fix sampleProgramContents.html's Firefox display issue


 Key: TUSCANY-2007
 URL: https://issues.apache.org/jira/browse/TUSCANY-2007
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Samples
Affects Versions: Java-SDO-Next
Reporter: Amita Vadhavkar
Priority: Minor
 Fix For: Java-SDO-Next


By 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. Without it, it was displaying as html text on the 
browser.

http://www.w3.org/TR/html4/loose.dtd";>" 
class="link">http://www.w3.org/TR/html4/loose.dtd";>

So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Java SDO] Tuscany SDO Java 1.1-incubating

[Amita Vadhavkar]

In the interest of avoiding the confusion that can be caused by cross-list
posting,  we'lll continue this discussion over
on the user list here at
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02415.html,
please make sure you are
subscribed to this list if you wish to be involved

Regards,
Amita

On Jan 18, 2008 4:08 PM, 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/tuscany-dev@ws.apache.org/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&#

[Java SDO] Tuscany SDO Java 1.1-incubating

[Amita Vadhavkar]

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/tuscany-dev@ws.apache.org/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.html we
have -
Open CSA (SCA Standards)

2) changes in http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.htmlfor
new features, improvements

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

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?

3) http://incubator.apache.org/tuscany/tuscany-sdo-java-faq.html page does
not have menu

4) http://incubator.apache.org/tuscany/sdo-project-code-structure.html no
menu , old structure

5) http://incubator.apache.org/tuscany/getting-source.html no menu and old
structure

6) developer guide - should we refer to
http://incubator.apache.org/tuscany/sca-java-development-guide.html and
make SDO Dev Guide more complete?

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.)

Can we provide this link in
http://incubator.apache.org/tuscany/sdo-java-user-guide.html

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.
And with 7) we can fix comment #2 - User guide has wrong styles :
http://incubator.apache.org/tuscany/sdo-java-user-guide.html

Regards,
Amita

Re: [Java SDO] What should we be attacking?

[Amita Vadhavkar]

Have a couple of question about release -

What will be the name of the Java SDO release?

After checking Java-SDO-Next and Java-SDO-CTS-Next from ASF-JIRA and
referring to
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html
I have tried to gather a list of all JIRAs (Fixed, Open,...) at -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project

Also, referring again to -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html,

Below are in-progress JIRAs-
   TUSCANY-1360
   TUSCANY-1483
   TUSCANY-1293

Are there any other in-progress JIRAs?

So we are left with below ones -

 Simple Starters
===
TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be
created
TUSCANY-1263XMLEqualityChecker too strict
TUSCANY-1659SDO DateConversion test cases fail under linux

Particular Skills JIRAs
=
For anyone with JavaJet experience there's

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)

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

Is anybody working on any from the above list? Also please take a look at
the cwiki link above to see if any other JIRAs from
there are of interest and can be made part of the release. Any other
issues/features missed so far in above which can be
included?

===
Regards,
Amita

On Jan 16, 2008 1:47 PM, kelvin goodson <[EMAIL PROTECTED]> wrote:

> Hey Amita,
>  that's great!  I guess collating the state of the fixed and unfixed
> JIRAs,  and producing a definitive list of what's going to be in and out
> is
> the first step.  I think the states and marked fix levels  on the JIRAs
> are
> all as they should be,  so that should be a relatively smooth operation.
> I'll try to find pointers to the best reference information later in the
> day
> and post them.
>
> Kelvin.
>
> On 16/01/2008, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > 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
> > &

[jira] Updated: (TUSCANY-1483) Static SDO generator: problem with elements named internal*

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1483:
-

Attachment: 1483-withTestCaseInToolsTest.patch

Acted on previous comments.

> Static SDO generator: problem with elements named internal*
> ---
>
> Key: TUSCANY-1483
> URL: https://issues.apache.org/jira/browse/TUSCANY-1483
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-beta1
>Reporter: Daniel Peter
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 1483-withTestCase.patch, 
> 1483-withTestCaseInToolsTest.patch, 1483.patch, test1483.xsd
>
>
> Hi,
> I run into a problem with the static generated SDOs, when having a xsd with 
> the following two elements:
> 
> 
> In the generated Impl class this leads twice to the same constant 
> INTERNAL_ABC.
> The xsd elements might simply be renamed in order to avoid this clash, but 
> there might be situations where this is not possible. 
> The generator could use a different, less probable prefix (e.g. ___INTERNAL_).
> Thanks, Daniel.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Java SDO] What should we be attacking?

[Amita Vadhavkar]

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.
> >
>

[jira] Updated: (TUSCANY-1483) Static SDO generator: problem with elements named internal*

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1483:
-

Attachment: 1483-withTestCase.patch

test case added to patch

> Static SDO generator: problem with elements named internal*
> ---
>
> Key: TUSCANY-1483
> URL: https://issues.apache.org/jira/browse/TUSCANY-1483
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-beta1
>Reporter: Daniel Peter
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 1483-withTestCase.patch, 1483.patch, test1483.xsd
>
>
> Hi,
> I run into a problem with the static generated SDOs, when having a xsd with 
> the following two elements:
> 
> 
> In the generated Impl class this leads twice to the same constant 
> INTERNAL_ABC.
> The xsd elements might simply be renamed in order to avoid this clash, but 
> there might be situations where this is not possible. 
> The generator could use a different, less probable prefix (e.g. ___INTERNAL_).
> Thanks, Daniel.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1923) DB Schema -> SDO Model XSD generator

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1923.
--

Resolution: Fixed

marking it resolved and further enhancements based on future requirements.

> DB Schema -> SDO Model XSD generator
> 
>
> Key: TUSCANY-1923
> URL: https://issues.apache.org/jira/browse/TUSCANY-1923
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
>    Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26054.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[SDO] SDO generator

[Amita Vadhavkar]

Hi,
I was just scanning through SDO for the things I was trying in 2007 and came
across JIRA-1483. David has already
provided the patch and test xsd. I would like to give it a try using javajet
and apply it.

Old discussion -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26269.html
Suggestions?
Regards,
Amita

Re: [SDO] questions about support for Enumeration facet

[Amita Vadhavkar]

Please see the 2 patches attached to JIRA-1360 and give comments.

Regards,
Amita

On Jan 1, 2008 4:11 PM, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

> Hi Kelvin,
> Yes , below is the change I tried to see to make a Property of type
> Strings, in DataObjectUtil -
>
>   protected static Property getGlobalProperty(HelperContext hc, String
> uri, String name)
>   {
> Property property;
> if (ExtendedMetaData.ANNOTATION_URI.equals(uri)) {
>   if ("minExclusive".equals(name) ||...
>   "enumeration".equals(name) ||
>   "pattern".equals(name))
>   {
>   if("enumeration".equals(name) || "pattern".equals(name)) {
>   property = SDOUtil.createOpenContentProperty(hc, uri, name,
> ((ModelFactoryImpl)ModelFactory.INSTANCE).getStrings());
>   } else {
>   property = SDOUtil.createOpenContentProperty(hc, uri, name,
> ((ModelFactoryImpl)ModelFactory.INSTANCE).getString());
>   }
>   }
>   else
>   {
> property = null;
>   }
> }
> else
> {
>   property = hc.getTypeHelper().getOpenContentProperty(uri, name);
>   if (property == null)
>   {
> property = SDOUtil.createOpenContentProperty(hc, uri, name,
> ((ModelFactoryImpl)ModelFactory.INSTANCE).getString());
>   }
> }
> return property;
>   }
>
> Regards,
> Amita
>
>
> On Dec 21, 2007 4:31 PM, kelvin goodson <[EMAIL PROTECTED] >
> wrote:
>
> > Amita,
> >  I'm a little unclear what you have changed.  Have you altered the
> > enumeration facet Property type to commonj.sdo.{Strings}?
> > Regards, Kelvin.
> >
> > On 21/12/2007, Amita Vadhavkar <[EMAIL PROTECTED] > wrote:
> > >
> > > This looks quite easy with one small difference in the behavior -
> > >
> > > For enum like below -
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > 1) below returns size as 3 i.e. conuts for the null value
> > >   if(metaObject instanceof EDataTypeImpl){
> > >   System.out.println("metaObject instance of EDataTypeImpl");
> > >   if( property.getName().equals("enumeration")) {
> > >   System.out.println
> > >
> > (((EDataTypeImpl)metaObject).getExtendedMetaData().getEnumerationFacet());
> > >   List enumVals =
> > >
> > ((EDataTypeImpl)metaObject).getExtendedMetaData().getEnumerationFacet();
> > >   System.out.println("enum size from
> > **EMF**"+enumVals.size());
> > >   }
> > >   }
> > >
> > > 2) whereas below returns size as 2, i.e. does not count for null
> > > result = SDOUtil.createFromString (getInstanceProperty(type,
> > > "enumeration").getType(), type.get(getInstanceProperty(type,
> > > "enumeration")).toString());
> > > System.out.println("Frank:enumeration"+result+", result
> > > type:"+result.getClass().getName()+", size-"+ ((java.util.ArrayList
> > > )result).size());
> > >
> > > in 2) the EMF call is made to EcoreUtil.createFromString
> > > ((EDataType)dataType,
> > > literal);
> > > and assumed that DataObjectUtil.getGlobalProperty() checks for enum
> > and
> > > does
> > > SDOUtil.createOpenContentProperty() for Strings.
> > >
> > > Suggestions?
> > >
> > > Regards,
> > > Amita
> > >
> > > On Dec 17, 2007 4:10 PM, kelvin goodson <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Amita,
> > > >
> > > >   I think Frank's note in this thread is key to the solution,  in
> > that
> > > the
> > > > line ...
> > > > return SDOUtil.createFromString(property.getType(), value);
> > > > will create a List if the type of the Property is set to "
> > > > commonj.sdo{Strings}"
> > > >
> > > >
> > > > Regards, Kelvin.
> > > >
> > > >
> > > > On 14/12/2007, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Tried to do little more analysis to see what is the way to reach
> > > > > ExtendedMetadata from DataObjectUtil. Please see the findings
> > below.
> > > > >
> > > > > DataObjectUtil.getMetaObjectInstanceProperty (EModelElement,
> >

[jira] Updated: (TUSCANY-1360) New SDOUtil: Getting the enumeration facet

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1360:
-

Attachment: 1360-Frank.patch
1360-Amita.patch

Attaching 2 patches 
1) 1360-Amita.patch - approach from 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26426.html
(check //Amita comment)

2) 1360-Frank.patch - approach from 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26623.html
(check //Frank comment)

Please review and see what can be the better way to provide this support. I 
have coded for enum and
pattern facets as both follow on similar lines.

> New SDOUtil: Getting the enumeration facet
> --
>
> Key: TUSCANY-1360
> URL: https://issues.apache.org/jira/browse/TUSCANY-1360
> Project: Tuscany
>  Issue Type: Wish
>  Components: Java SDO Tools
>Reporter: Christian Landbo Frederiksen
>    Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 1360-Amita.patch, 1360-Frank.patch
>
>
> This has been discussed in the lists: 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg01095.html
> I do this:
>   public static List getEnumerationFacet(Type type) {
>return
>  ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
>}
> Kelvin suggested another way
> I think you should be able to do
> type.getInstanceProperties() and find the Property called "enumeration".
> Then you can get the enumerations using that Property.
> (see MetaDataInstancePropertiesTestCase [2])
> Having this encapsuled by the SDOUtil would be cool (but maybe overkill - you 
> decide)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: implementation-data-sdo

[Amita Vadhavkar]

Please see the prototype in
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/amita/sca, the
README under implementation-data-sdo
will have details.

Regards,
Amita

On Jan 8, 2008 5:03 PM, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

> Making a separate mail thread as it is no more talking about web service.
> Old mail ref -
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26764.html
>
> Some more comments and need suggestions about implementation-data-sdo.
>
> To keep the interface Collection simple as it is now, internally K(key)
> can be checked for delimiter separated list of Strings e.g. comma,
> to take care of compound PK, a common situation when it comes to DBs. This
> can be checked in impl-data-sdo.
>
> In .composite implementation.sdo can have attribute "key" as well, e.g.
>  This
> can be the way to get to know the PK columns. Convention like DAS can be
> used like -
> in absence of "key" attribute , it can be assumed to be single column
> "ID".
>
> For the above necessary places like SDOImplementation will have
> get/setKey()
>
> Assume that SDO Type and Property names are same as Database Table and
> Column names for simplicity. i.e. do not go into mapping these two.
>
> In query(string), assume that the params values are hardcoded in WHERE
> clause, i.e. no need to pass params later.
>
> put(K, D) //i.e. update - D should be taken from a DataGraph having
> ChangeSummary e.g.
>   Object result = dataService.get(id);
>   ((DataObject)result).getDataObject("COMPANY[ID=50]").set("NAME", "MY
> ABC");
>dataService.put(List{50}, result);
>
> Regards,
> Amita
>

implementation-data-sdo

[Amita Vadhavkar]

Making a separate mail thread as it is no more talking about web service.
Old mail ref -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26764.html

Some more comments and need suggestions about implementation-data-sdo.

To keep the interface Collection simple as it is now, internally K(key) can
be checked for delimiter separated list of Strings e.g. comma,
to take care of compound PK, a common situation when it comes to DBs. This
can be checked in impl-data-sdo.

In .composite implementation.sdo can have attribute "key" as well, e.g.
 This
can be the way to get to know the PK columns. Convention like DAS can be
used like -
in absence of "key" attribute , it can be assumed to be single column "ID".

For the above necessary places like SDOImplementation will have get/setKey()

Assume that SDO Type and Property names are same as Database Table and
Column names for simplicity. i.e. do not go into mapping these two.

In query(string), assume that the params values are hardcoded in WHERE
clause, i.e. no need to pass params later.

put(K, D) //i.e. update - D should be taken from a DataGraph having
ChangeSummary e.g.
  Object result = dataService.get(id);
  ((DataObject)result).getDataObject("COMPANY[ID=50]").set("NAME", "MY
ABC");
   dataService.put(List{50}, result);

Regards,
Amita

Re: XSD --> DB and Vice Versa

[Amita Vadhavkar]

For SDO Types -> XSD , there is XSDHelper.generate(List of Types) support
existing in SDO Impl.

For XSD-> DB Schema - I have a question, as far as SDO does not support
IDREF/KEYREF
in SDO definitions, how a containment relationship in XSD model can get
successfully translated
into referential integrity constraint (relationship) in a database?

For this (i.e. lack of IDREF) RDB DAS has provided /
where user can specify the
required information. And it is used during data access.

Regards,
Amita

On Jan 7, 2008 11:13 AM, Ole Ersoy <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I know Amita is looking into DB > XSD.  I was wondering if there is any
> work being done on XSD > DB?  Also can the SDO implementation generate the
> XSD if the SDO types are provided, enabling SDO Type > XSD > DB?
>
> Thanks,
> - Ole
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [DAS] DAS as web service

[Amita Vadhavkar]

I am checking impl-data-pojo from the sandbox and also can see the generic
org.apache.tuscany.sca.implementation.data.collection.Collection from
impl-data-api.
I guess this interface is generic and can be used as the starting point for
any sample
implementations like what is there in impl-data-pojo. Just one question, why
do we need
to copy Collection interface in
org.apache.tuscany.sca.implementation.openjpa.collection?

>From the below from Collection interface -
Map getAll();
Map query(String queryString);
K post(D item);
D get(K key) throws NotFoundException;
void put(K key, D item) throws NotFoundException;
void delete(K key) throws NotFoundException;

getAll(), query(), get(), delete() will have a straight implementation using
sdo+das.

For post() - it can be forming complete INSERT using the input D - i.e.
property->column mapping
and grabbing all values from D.

For put(i.e. update), is a place in DAS, where it uses Change Summary
effectively. Here D will
have the changes on the top of the result obtained by some get(), so will be
DataGraph having ChangeSummary.

I am right now trying to get the get() working and will put the working code
in my sandbox.

Please give suggestions, comments on this initial approach and anything
else.

Regards,
Amita

On Dec 14, 2007 7:01 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:

> Sure, maybe a good first step would be to agree on a "data" interface
> to be used.
>
> On Dec 14, 2007 4:52 AM, Amita Vadhavkar <[EMAIL PROTECTED]>
> wrote:
> > Thanks Luciano, I will give a try to implementation-data-sdo.
> > -Amita
> >
> >
> > On Dec 13, 2007 5:18 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > > Looks like you are starting to face some of the same issues I had in
> > > the past... I can see two issues here : Passing Data Graphs and Change
> > > Summary, and ensuring the client (e.g a web 2.0 application) would be
> > > SDO Enabled to handle this data representation and maintain it.
> > >
> > > Maybe a better alternative would be to leverage SCA to expose Data
> > > Service CRUD + Query interface utilizing SCA bindigns. We could
> > > leverage some of the work we have been doing on implementation.data
> > > for this and define a interface for SDO or for regular Pojos and use
> > > that interface as the main interface for the Data components.This
> > > would also give us some more flexibility in terms of what
> > > communication protocols would be supported (e.g ws, rmi, jsonrpc, etc)
> > >
> > > Well, these are only some initial thoughts, and I'd appreciate input
> > > from others on the community.
> > >
> > >
> > > On Dec 12, 2007 11:58 PM, Amita Vadhavkar <[EMAIL PROTECTED]>
> > > wrote:
> > > > I could see that static and dynamic DOs (using xsd:anyType) can be
> > > passed
> > > > using web service, but when it comes to DataGraph containing
> > > ChangeSummary
> > > > is there a way to pass it as parameter?
> > > >
> > > > -Amita
> > > >
> > > >
> > > > On Nov 14, 2007 6:34 PM, Amita Vadhavkar <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > > There is an old thread -
> > > > >
> http://www.mail-archive.com/[EMAIL PROTECTED]/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.
> > >

[jira] Closed: (TUSCANY-1852) Use static model to define DAS Config relationships

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar closed TUSCANY-1852.


Resolution: Fixed

can re-open based on new features in SDO in future.

> Use static model to define DAS Config relationships
> ---
>
> Key: TUSCANY-1852
> URL: https://issues.apache.org/jira/browse/TUSCANY-1852
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>    Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24861.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1929) generate xml from dataobject

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar closed TUSCANY-1929.


Resolution: Fixed

In case the prevision explanation is not applicable to the problem , please 
re-open the issue.

> generate xml from dataobject
> 
>
> Key: TUSCANY-1929
> URL: https://issues.apache.org/jira/browse/TUSCANY-1929
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-M2
> Environment: java ee 1.5, eclipse 3.3.1.1. , windows xp, das 1.0 beta 
> 2, access mdb - no access installed, sca 1.0
>Reporter: Kristina 
>Assignee: Amita Vadhavkar
> Attachments: XMLHelperSample.java
>
>
> hi all,
> not sure if this is a bug or is just me... bottom line i need help :)
> when trying to generate the xml from dataobject , i get an empty one 
> eventhough the dataobject is filled
> I am using: String generatedXml = XMLHelper.INSTANCE.save(root, 
> "http://helloworld2";, "MaterialListForTest"); where root is my dataobject
> what am i doing wrong?
> thanks,
> kristina

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]