from:"Amita Vadhavkar"


 [ 
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
   complexType
 sequence
   element name=property type=int/
 /sequence
 attribute name=property type=string/
   /complexType
 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] Updated: (TUSCANY-1468) Use HelperContext for scope in Tuscany API


 [ 
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-1498) Improve SubstitutionValuesTestCase


 [ 
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-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4


 [ 
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-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe


 [ 
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-1399) Generate SDO test classes using maven-sdo-plugin


 [ 
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


 [ 
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


 [ 
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 
 xsd:schema xmlns:tns=http://helloworld; 
 xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified 
 targetNamespace=http://helloworld;
  complexType name=Person
 sequence
 element name=firstName type=string/
 element name=lastName type=string/
 /sequence
  /complexType
 /xsd:schema

-- 
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-1397) createDataObject() throws NPE if property does not exist


 [ 
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-1514) DataHelperImpl.toDate will report a NullPointerException


 [ 
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.init(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-1531) Java SDO Documentation page should be updated to default website stype/design


 [ 
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-1540) Abstract Static Base Types mixed with Dynamic Extended Types


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

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-
   xsd:complexType name=CustomerType
 xsd:all
   xsd:element name=number type=xsd:integer /
   xsd:element form=unqualified name=info type=InfoType /
 /xsd:all
   /xsd:complexType
   
   xsd:complexType name=InfoType abstract=true/
 Dynamic Schema
 xsd:complexType name=InfoType
   xsd:complexContent
 xsd:extension base=staticNS:InfoType
   xsd:sequence
 xsd:element name=zipcode type=xsd:string /
   /xsd:sequence
 /xsd:extension
   /xsd:complexContent
 /xsd:complexType
 The following will fail:
 DataFactory factory = scope.getDataFactory();
 factory.create(CustomerType.class).setDataObject(info, 
 factory.create(dynamicNS, InfoType));
 It should be legal to assign a property to an object if they are in the same 
 hierachy.
 Steps to reproduce within Tuscany:
 Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 
 'InfoType' defined in extensible/customer.xsd  is marked as abstract.

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


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

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


 [ 
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
 there should be an implementation of isSet(int) (in ExtensibleDataObject
 probably?) that handles the case of a property that is either in a dynamic
 sublass or was dynamically added to a static type.
 Frank.
 Ron Gavlin [EMAIL PROTECTED] wrote on 07/26/2007 01:09:27 PM:
  Frank,
 
  This scenario appears to trigger a property-indexing problem. The
  newly added property's EMF featureID of 18 equals the value of
  MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.
  INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any
  ideas for working around this problem?
 
  - Ron
 

-- 
This message

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


 [ 
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-1655) Generated code uses deprecated method FactoryBase.getProperty(Type,int)


 [ 
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-1272) CrudWithChangeHistory test case fails as it's not finding the deleted object in the changeSummary


 [ 
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-1780) [JAVA-SDO] Incorrect generation of class with default value for a list


 [ 
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:
 xsd:attribute name=categoryType type=address:CategoryType use=required 
 default=myCat/
 simpleType name=CategoryType
 list itemType=category /
 /simpleType
 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


 [ 
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-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope

[
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


 [ 
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.
 xsd:schema 
   targetNamespace=http://www.example.com/simple;
   xmlns:xsd=http://www.w3.org/2001/XMLSchema; 
   xmlns:simple=http://www.example.com/simple; 
   
xsd:element name=stockQuote type=simple:Quote/
xsd:complexType name=Quote
xsd:sequence
   xsd:element name=symbol type=xsd:string/
   xsd:element name=companyName type=xsd:string/
   xsd:element name=price type=xsd:decimal/
   xsd:element name=open1 type=xsd:decimal/
   xsd:element name=high type=xsd:decimal/
   xsd:element name=low type=xsd:decimal/
   xsd:element name=volume type=xsd:double/
   xsd:element name=change1 type=xsd:double/
   xsd:element name=quotes type=simple:Quote minOccurs=0 
 maxOccurs=unbounded/
/xsd:sequence
/xsd:complexType
 /xsd:schema

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

[
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-1811) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:float


 [ 
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(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

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


 [ 
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-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element


 [ 
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-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension


 [ 
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
 schema xmlns=http://www.w3.org/2001/XMLSchema;
 targetNamespace=http://www.example.com/substitutionEV; 
 xmlns:sv=http://www.example.com/substitutionEV;
   !--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 License); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
 http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
   --
   element name=results type=sv:ResultsType/
   
   element name=result type=sv:ResultType/
   element name=myResult type=sv:MyResultType 
 substitutionGroup=sv:result/
   
   complexType name=ResultsType
 sequence
   element ref=sv:result minOccurs=0 maxOccurs=unbounded/
   element name=comment type=string/
 /sequence
   /complexType
   
   complexType name=ResultType
 sequence
   element name=name type=string/
   element name=value type=string/
 /sequence
   /complexType
   complexType name=MyResultType
 complexContent
   extension base=sv:ResultType/
 /complexContent
   /complexType
   
 /schema
 substitutionWithExtensionValues1.xml
 ?xml version=1.0 encoding=ASCII?
 sev:results xmlns:sev=http://www.example.com/substitutionEV;
   sev:result
 sev:namename1/sev:name
 sev:valuevalue1/sev:value
   /sev:result
   sev:myResult
 sev:namemyName1/sev:name
 sev:valuemyValue1/sev:value
   /sev:myResult
   sev:commentcomment1/sev:comment
 /sev:results
 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

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


 [ 
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
 ==
 schema xmlns=http://www.w3.org/2001/XMLSchema;
 targetNamespace=http://www.example.com/substitutionEV; 
 xmlns:sev=http://www.example.com/substitutionEV;
   !--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 License); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
 http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
   --
   element name=results type=sev:ResultsType/
   
   element name=result type=sev:ResultType/
   element name=myResult type=sev:MyResultType 
 substitutionGroup=sev:result/
   
   complexType name=ResultsType
 sequence
   element name=uuid type=sev:UuidType/
   element ref=sev:result minOccurs=0 maxOccurs=unbounded/
   element name=comment type=string/
 /sequence
   /complexType
   
   complexType name=ResultType
 sequence
   element name=uuid type=sev:UuidType/
   element name=name type=string/
   element name=value type=string/
 /sequence
   /complexType
   
   complexType name=MyResultType
 complexContent
   extension base=sev:ResultType/
 /complexContent
   /complexType
   
   simpleType name=UuidType
 restriction base=sev:AsciiStringType
   pattern 
 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}/
 /restriction
   /simpleType
   
   simpleType name=AsciiStringType
 restriction base=string
   pattern value=\p{IsBasicLatin}*/
 /restriction
   /simpleType
   
 /schema
 ==
 substitutionWithExtensionValues2.xsd
 ==
 schema xmlns=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;
   !--
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   License); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at
   
   http://www.apache.org/licenses/LICENSE-2.0
   
   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
   --
   import namespace=http://www.example.com/substitutionEV;
   schemaLocation=substitutionWithExtensionValues.xsd /
   element name=allResults type=sev2:AllResultsType /
   complexType name=AllResultsType
   sequence

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


 [ 
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-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue


 [ 
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.
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN   
 title=http://www.w3.org/TR/html4/loose.dtd; 
 class=linkhttp://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-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly


 [ 
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-1545) Change default XML encoding to UTF-8.


 [ 
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-1359) New SDOUtil: Upper and lower bound on properties where 'isMany' is true


 [ 
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-829) Investigate integration of RogueWave tests


 [ 
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-1360) New SDOUtil: Getting the enumeration facet


 [ 
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 ListString 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-2011) include apache headers in xmls and xsds without causing test case failures


 [ 
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-1574) SDOXSDEcoreBuilder.createResourceSet() is not thread safe

[
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-1645) XSD2JavaGenerator failed to gen on the wsdl files with only xsd:import element in xsd:schema


 [ 
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 xsd:import 
 element in xsd:schema
 

 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 xsd:schema
 types
 xsd:schema
   xsd:import namespace=http://test/; 
 schemaLocation=EchoService_schema1.xsd/
 /xsd:schema
   /types
 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-1832) Complex type w/simple content restriction facets are ignored


 [ 
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
 ==
 schema xmlns=http://www.w3.org/2001/XMLSchema;
   targetNamespace=http://www.example.com/substitutionEV;
   xmlns:sev=http://www.example.com/substitutionEV;
   !--
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   License); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at
   
   http://www.apache.org/licenses/LICENSE-2.0
   
   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
   --
   element name=results type=sev:ResultsType /
   element name=result type=sev:ResultType /
   element name=myResult type=sev:MyResultType
   substitutionGroup=sev:result /
   complexType name=ResultsType
   sequence
   element name=id type=sev:IdType /
   element ref=sev:result minOccurs=0
   maxOccurs=unbounded /
   element name=comment type=sev:CommentType /
   /sequence
   /complexType
   complexType name=ResultType
   sequence
   element name=id type=sev:IdType /
   element name=name type=string /
   element name=value type=sev:CommentType /
   /sequence
   /complexType
   complexType name=MyResultType
   complexContent
   extension base=sev:ResultType /
   /complexContent
   /complexType
   simpleType name=IdType
   restriction base=sev:AsciiStringType
   maxLength value=32 /
   pattern value=[0-9a-fA-F]* /
   /restriction
   /simpleType
   simpleType name=AsciiStringType
   restriction base=string
   pattern value=\p{IsBasicLatin}* /
   /restriction
   /simpleType
   complexType name=CommentType
   simpleContent
   extension base=sev:AsciiStringType
   attribute name=language use=optional
   simpleType
   restriction base=string
   enumeration 
 value=English /
   enumeration 
 value=French /
   enumeration 
 value=Spanish /
   /restriction
   /simpleType
   /attribute
   /extension
   /simpleContent
   /complexType
   
   complexType name=MyCommentType
 simpleContent
   restriction base=sev:CommentType
 minLength value=0 /
 maxLength value=40 /
   /restriction
 /simpleContent
   /complexType
   
 /schema
 ==
 substitutionWithExtensionValues2.xsd
 ==
 schema xmlns=http://www.w3.org/2001/XMLSchema;
   targetNamespace=http://www.example.com

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


 [ 
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-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content


 [ 
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
 == 
 schema xmlns=http://www.w3.org/2001/XMLSchema;
   targetNamespace=http://www.example.com/substitutionEV;
   xmlns:sev=http://www.example.com/substitutionEV;
   !--
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   License); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at
   
   http://www.apache.org/licenses/LICENSE-2.0
   
   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
   --
   element name=results type=sev:ResultsType /
   element name=result type=sev:ResultType /
   element name=myResult type=sev:MyResultType
   substitutionGroup=sev:result /
   complexType name=ResultsType
   sequence
   element name=id type=sev:IdType /
   element ref=sev:result minOccurs=0
   maxOccurs=unbounded /
   element name=comment type=sev:CommentType /
   /sequence
   /complexType
   complexType name=ResultType
   sequence
   element name=id type=sev:IdType /
   element name=name type=string /
   element name=value type=sev:ValueType /
   /sequence
   /complexType
   complexType name=MyResultType
   complexContent
   extension base=sev:ResultType /
   /complexContent
   /complexType
   simpleType name=IdType
   restriction base=sev:AsciiStringType
   maxLength value=32 /
   pattern value=[0-9a-fA-F]* /
   /restriction
   /simpleType
   simpleType name=AsciiStringType
   restriction base=string
   pattern value=\p{IsBasicLatin}* /
   /restriction
   /simpleType
   complexType name=ValueType
   simpleContent
   extension base=sev:Integer32Bit /
   /simpleContent
   /complexType
   complexType name=Integer32Bit
   simpleContent
   restriction base=integer
   minInclusive value=0 /
   maxInclusive value=429000 /
   /restriction
   /simpleContent
   /complexType
   
   complexType name=CommentType
   simpleContent
   extension base=sev:AsciiStringType
   attribute name=language use=optional
   simpleType
   restriction base

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


 [ 
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] Closed: (TUSCANY-1295) Resolve Memory Leaks in RDB DAS source and test cases code

2008-02-19 Thread 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] Resolved: (TUSCANY-1355) DAS-RDB does not support Oracle or SqlServer well

2008-02-19 Thread 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] Commented: (TUSCANY-1293) SDO does not work with OSGi

2008-02-14 Thread Amita Vadhavkar (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
 at 
 org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
 at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
 at 
 org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
 at 
 org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
 at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
 at commonj.sdo.impl.HelperProvider.clinit(HelperProvider.java:69

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

2008-02-12 Thread Amita Vadhavkar (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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.clinit(ModelFactory.java:41)
 at 
 org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
 at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
 at 
 org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
 at 
 org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
 at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl.init(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.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157

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

2008-02-12 Thread Amita Vadhavkar (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.clinit(AttributeImpl.java:126)
 at 
 org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
 at org.apache.tuscany.sdo.impl.ClassImpl.clinit(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.clinit(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

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

2008-02-12 Thread 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] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4

2008-02-11 Thread 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] Commented: (TUSCANY-1831) Make SDOPackageRegistryDelegator pluggable

2008-02-08 Thread Amita Vadhavkar (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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]

[SDO Java] Pluggable SDOPackageRegistryDelegator and Tuscany-1459

2008-02-08 Thread 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] Resolved: (TUSCANY-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored

2008-02-08 Thread 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

2008-02-08 Thread 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 ListString 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] Commented: (TUSCANY-761) Support the ability to unregister all the SDO Types in a namespace


[ 
https://issues.apache.org/jira/browse/TUSCANY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2014) XMLDocument object's rootElement member not intialized properly


[ 
https://issues.apache.org/jira/browse/TUSCANY-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1835) XSDHelper.getAppinfo() returns wrong result


[ 
https://issues.apache.org/jira/browse/TUSCANY-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
 xsd:annotation
   xsd:appinfo source=appinfosrc
   simple:stockQuote xmlns:simple=http://www.example.com/simple;
   symbolfbnt/symbol
   /simple:stockQuote
   /xsd:appinfo
 /xsd:annotation
 XSDHelper.getAppinfo() should return
 xsd:appinfo source=appinfosrc
   simple:stockQuote xmlns:simple=http://www.example.com/simple;
   symbolfbnt/symbol
   /simple:stockQuote
 /xsd:appinfo
 Now it's returning the wrong result like below.
   simple:stockQuote xmlns:simple=http://www.example.com/simple;
   symbolfbnt/symbol
   /simple:stockQuote

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

[
https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored

2008-02-06 Thread Amita Vadhavkar (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=583095view=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());  
}

}

Output

before detach:?xml version=1.0 encoding=UTF-8?
quote:quote xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xmlns:quote=quote
xmlns:simple=http://www.example.com/simple; xsi:type=simple:Quote
  symbolHP/symbol

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

2008-02-06 Thread 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.init(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-67) ClassLoader issues with SDO

2008-02-06 Thread Amita Vadhavkar (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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]

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

2008-02-04 Thread 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.println
 (*);

   StringWriter sw = new StringWriter();
   hc.getXMLHelper().save(xmlDoc, sw, null);
   StringReader sr = new StringReader(sw.toString());
   String nodecl = sw.toString().substring(40);
   //System.out.println(sw/nodecl:+ nodecl+\n);
   StringBuffer strbuf = new StringBuffer();
   char[] i = new char[1];
   while(sr.read(i) != -1) {
   strbuf.append(i);
   continue;
   }

   System.out.println(sw/nodecl:+ strbuf.toString() +\n);//VVIMP -
 substr

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

2008-01-31 Thread 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-2025) SDO Java Samples - minor commentary fixes

2008-01-31 Thread 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] Resolved: (TUSCANY-1483) Static SDO generator: problem with elements named internal*

2008-01-29 Thread 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:
 xsd:element name=abc type=xsd:integer /
 xsd:element name=internalAbc type=xsd:integer /
 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

2008-01-29 Thread 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]

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

2008-01-25 Thread 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=emfversion=2.2.x

* 2.2.2
* 2.2.2RC2 (2 bugs fixed)
  o 173815 Bad link exist on EMF/SDO/XSD Developer Guide
  o 173681 encoding is ignored during XMLResource#load
*

surefire-reports

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.172 sec
 FAILURE!
testEncoding(org.apache.tuscany.sdo.test.XMLHelperTestCase)  Time elapsed:
3.125 sec   FAILURE!
junit.framework.AssertionFailedError: Encoding ('ASCII' is not correct.
UTF-8 is the expected encoding.
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding (
XMLHelperTestCase.java:313)
at org.apache.tuscany.sdo.test.XMLHelperTestCase.testEncoding(
XMLHelperTestCase.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest (TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run( TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(
JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet (
AbstractDirectoryTestSuite.java:138)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(

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

2008-01-25 Thread 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]

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

2008-01-25 Thread 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-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly

2008-01-23 Thread 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] Updated: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue


 [ 
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.
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN   
 title=http://www.w3.org/TR/html4/loose.dtd; 
 class=linkhttp://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


[ 
https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Resolved: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue


 [ 
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.
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN   
 title=http://www.w3.org/TR/html4/loose.dtd; 
 class=linkhttp://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