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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1918:
-

Hi Bert,

Yes, please forward your comments to the OASIS list. Also please mention the 
charter item (10.  Relaxing Containment Requirements) that they're related to.

Thanks,
Frank.

 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

 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-1918) Support for dynamic containment

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1918:
-

Hi Bert,

Non-members can monitor the email archives 
(http://www.oasis-open.org/archives/sdo/) and the document repository 
(http://www.oasis-open.org/committees/documents.php?wg_abbrev=sdo), and provide 
comments/feedback via the email list 
(http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=sdo).

Links to all three of these resources are found on the TC Public page at: 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdo

Frank.


 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

 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-1918) Support for dynamic containment

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1918:
-

Hi Bert,

If you want to join the TC and attend the regular telecons, you (or your 
company) needs to be an OASIS member. We'd love to have you :-) Alternatively, 
anybody can observe what's going on and provide comments. 

Details can be found at: 
http://lists.oasis-open.org/archives/tc-announce/200710/msg00011.html

Frank.

 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

 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-1918) Support for dynamic containment

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1918:
-

There is also a related feature in the charter for SDO 3. See item 10 in the 
Function (V3.0) section: http://www.oasis-open.org/committees/sdo/charter.php

Note that SDO 3 TC at OASIS welcomes all interested parties.

 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

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1780:
-

I'd suggest replacing this:

 stringBuffer.append(genFeature.getStaticDefaultValue()); 

with something like this:

 stringBuffer.append(SDOGenUtil.getStaticDefaultValue(genFeature)); 

Then you can implement SDOGenUtil.getStaticDefaultValue() to produce only what 
is needed for SDO.

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

 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] Commented: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1853:
-

Hi Czarek, This looks familiar, I think we may have fixed it already. Can you 
try the latest from trunk and see if you still experience problems. Thanks.

 XSD2JavaGenerator generates Java identifier with dots
 -

 Key: TUSCANY-1853
 URL: https://issues.apache.org/jira/browse/TUSCANY-1853
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
 Environment: Windows XP, jre 1.5
Reporter: Cezary Tkaczyk

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

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


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

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1842:
-

Hi Ron,

It looks like the problem is caused because DataObject.delete() calls unset() 
on the special value property of a wrapper type which causes an invalid 
instance to be serialized:

   objectsToAttach xsi:type=sev:ValueType/

Your hack works around the issue by forcing the loader to accept the invalid 
instance.

A better fix would be to prevent DataObject.delete() from calling unset() on 
value properties, but there is currently no way to detect that a property is 
one of these special wrapper value properties. So, I guess your hack is as good 
as any for now, but we need to document the fact that this is a temporary fix. 
In the future we need to ensure that unset() is not called - or it has special 
behavior - for the value properties.

Frank.
 

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


 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 /
   

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1832:
-

Hi Ron,

What you're doing here is really very EMF specific. Even the fact that there is 
a second type, _MyCommentType, is an EMF detail. None of that is defined in 
the SDO spec. All the SDO spec requires is that the type of the value property 
is something capable of holding the value, so AsciiStringType is as good as 
anything from the spec perspective. The problem is caused by the fact that EMF 
validation relies on the constraints being associated with an EDataType - 
that's why EMF defines the special _MyCommentType type with the constraints. 
Unfortunately, this corner case of a complexType with simple content restricing 
another completType with simple content is broken because of EMF limitiations 
described above and by Ed.

So, to answer your question, I think SDO, not just Tuscany, should handle this, 
but I'm not sure there's a good quick fix. I think the SDO spec needs to 
specify this (e.g., how are simple content constraints represented in a complex 
type with a value property). My guess is that the correct answer is that they 
should appear as instanceProperties on the actual type MyCommentType. Maybe 
that's something we could try to implement in Tuscany ahead of time, but I'm 
not sure if it's easily doable - and since SDO 2.1 hasn't defined standard 
properties for constraints yet, it would still be Tuscany specific.

How important is it that you have access to these constraints? The alternative 
is to simply get them by reading the XSD directly.

 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

 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
   

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1832:
-

Hi Ron,

 So, if we remove the EMF validation from the test listed above, is it 
 reasonable to expect the test to work?

Yes, other than the validator not complaining about invalid instances, it 
should work. Doesn't it?

 How tough would it be to implement this support in Tuscany SDO? Thoughts? 

What support do you mean? Validation of constraints on subtypes of complex 
types? If so, then I think it would be very difficult to get it working using 
the existing EMF-based validator. But, it SDO 3, there are plans to provide 
complete XSD metadata, so at that point I could imagine a proper XSD based 
validator implementation that would be able to check the constraints that the 
EMF-based model can not.

 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

 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 /
  

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1832:
-

Hi Ron,

Your change will break the behavior that the SDO spec requires - the name of an 
anonymous type should be the name of its enclosing element . For your case, we 
have complex type with a nested anonymous simple type. So I think what you 
probably want is something like this:

  protected String getAliasName(XSDNamedComponent xsdNamedComponent) {
String result = xsdNamedComponent.getName();
if (result == null)
{
  XSDConcreteComponent container = xsdNamedComponent.getContainer();
  if (container instanceof XSDNamedComponent)
  {
result = getAliasName((XSDNamedComponent)container);
if (container instanceof XSDTypeDefinition)
{
  result = _ + result;
}
  }

}
return result;
  }


I hope that doesn't break anything else though.

One thing to notice about the EMF fix, is that it will now create a datatype 
with the constraint metadata, but because the value feature is not using the 
new datatype, the validator will still not  check those constraints.


 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

 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
  

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1832:
-

Hi Ron,

It looks like you've run into an EMF limitation that can't be fixed easily, if 
at all. The problem is that constraints imposed by a complex type with simple 
content which extends another complex type with simple content will not be 
validated. The problem is because the base type (CommentType) defines the 
value property and the subtype (MyCommentType) can't override it. It's an EMF 
limitation similar to the pre Java 5 limitation that said if a class defines a 
method to return some base type, for example:

class Foo {
  Base getFoo() { ... }
}

then you can't override the method in a subclass to return a sub type:

class Bar extends Foo {
   Sub getFoo() { ... }
}

That's the analogous problem to the one EMF has with properties.

So, unless you run an actual XML validator, or merge the constraints into the 
base type, you're not going to be able to validate them.


 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

 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 /
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

I think the last suggestion sounds like the simplest sollution. Eagerly 
precache the holders for static packages. We can do it right away when we 
register a static package. Maybe we could do it in 
SDOExtendedMetaDataImpl.putPackage() which is called by the Factory.register() 
method. We could simply add code to walk through the package and call 
ExtnededMetaData.getName() on all the classifiers and structural features.


 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

 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 
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Hi Ron,

I think that with Ed's suggestion we don't want to use the 
extendedMetaDataHolderCache. That is, you should not include my earlier 
suggested fix. Ed's approach is to force the objects themselves to compute and 
cache their own extendedMetaData. Then it doesn't matter what ExtendedMetaData 
instance is used to access it.

Frank.


 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

 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 
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Oops, I just noticed one more thing. You shouldn't be calling 
ExtendedMetaData.INSTANCE.getName() in putPackage() but rather this.getName().

Frank.


 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

 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 
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Hi Ron,

Your suggestion sounds reasonable if there's no cleaner way to handle it. This 
is probably another good question to ask on the EMF newsgroup. Ed Merks often 
has clever ideas for things like this.

Frank.

 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

 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 
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Ron, I'm not sure of the answer to your question. Asking it on the EMF 
newsgroup should probably get you a quick answer.


 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

 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(SubstitutionWithExtensionValuesTestCase.java:40)

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Hi Ron, I'll try to look at it this afternoon, and append my thoughts later 
today.

 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

 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(SubstitutionWithExtensionValuesTestCase.java:40)
   at 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Hi Ron,

Well this certainly looks like a nasty oversight from the recent change we made 
to decouple SDO from the EMF global registry.

I was experimenting with another approach to fix it using an 
extendedMetaDataHolderCache, which avoids going directly to the objects. 

I added this constant in SDOXSDEcoreBuilderImpl:

  public static String SDO_ANNOTATION_URI = 
http:///org/apache/tuscany/sdo/helper/SDOExtendedMetaData;;

and then changed the constructor to call a 2 argument base constructor like 
this:

  public SDOExtendedMetaDataImpl(Registry registry) {
super(SDO_ANNOTATION_URI, registry);
ecoreFactory = new SDOEcoreFactory();
demandMetaData = new SDODemandMetaData();
  }

I also needed to change the ANNOTATION_SOURCE constant in FactoryBase:

  //private static final String ANNOTATION_SOURCE = 
http:///org/eclipse/emf/ecore/util/ExtendedMetaData;;
  private static final String ANNOTATION_SOURCE = 
SDOExtendedMetaDataImpl.SDO_ANNOTATION_URI;

With these changes, it seemed to fix the getAffiliation() problem, but it still 
has a problem with the validator.

Unfortunately, I don't have any more time to look at it right now. If you want 
to take it further, that would be great. Also, I'm not opposed to the approach 
you suggested, if that works out better. Maybe a combiniation of the two would 
be best.

Thanks,
Frank.

 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

 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
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1812:
-

Hi Ron, It looks like your myResult element is missing the substitutionGroup 
attribute:

  element name=myResult type=sv:MyResultType 
substitutionGroup=sv:result/

 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

 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. 
 Please comment if you have questions.
 - Ron
 package org.apache.tuscany.sdo.test;
 import java.io.IOException;
 import java.net.URL;
 import junit.framework.TestCase;
 import commonj.sdo.DataObject;
 import commonj.sdo.helper.HelperContext;
 import commonj.sdo.helper.XMLHelper;
 import commonj.sdo.helper.XSDHelper;
 import commonj.sdo.impl.HelperProvider;
 public final class SubstitutionWithExtensionValuesTestCase extends TestCase
 {
   public void test() throws IOException
   {
 HelperContext hc = HelperProvider.getDefaultContext();
 URL url = getClass().getResource(/SubstitutionWithExtensionValues.xsd);
 XSDHelper xsdHelper = hc.getXSDHelper();
 xsdHelper.define(url.openStream(), url.toString());
 XMLHelper xmlHelper = hc.getXMLHelper();
 DataObject loadedObject = 
 
 xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues.xml)).getRootObject();
   }
 }
 SubstitutionWithExtensionValues.xsd
 schema xmlns=http://www.w3.org/2001/XMLSchema;
 
 targetNamespace=http://www.apache.org/tuscany/SubstitutionWithExtensionValues;
  
 
 xmlns:sv=http://www.apache.org/tuscany/SubstitutionWithExtensionValues;
   !--
 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/
   
   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
 SubstitutionWithExtensionValues.xml
 ?xml version=1.0 encoding=ASCII?
 sv:results 
 xmlns:sv=http://www.apache.org/tuscany/SubstitutionWithExtensionValues;
   sv:result
 sv:namename1/sv:name
 sv:valuevalue1/sv:value
   /sv:result
   sv:myResult
 sv:namemyName1/sv:name
 sv:valuemyValue1/sv:value
   /sv:myResult
   sv:commentcomment1/sv:comment
 /sv:results
 STACKTRACE
 org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 
 'myResult' not found. (http:///temp.xml, 7, 16)
   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 
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1811:
-

Is the general problem that we need a notify() method in DataObjectBase for 
every Java primitive type - boolean, byte, char, double, float, int, long, 
short? Jjust like ENotificationImpl has a constructor for each of them?

 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

 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 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1780:


Attachment: Address2.xsd

The Address.xsd schema has a few errors. I'm attaching Address2.xsd, which is a 
valid schema illustrating the problem.

 [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
 Attachments: Address.xsd, Address2.xsd


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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1780:
-

This seems to be a part of the Class.javajet template that was overlooked when 
we changed to generate the new noEMF pattern.

The template needs to be changed to generate the following:

protected static final List CATEGORY_TYPE_DEFAULT_ = 
(List)((AddressFactoryImpl)AddressFactory.INSTANCE).createCategoryTypeFromString(myCat);

instead of what it's currently generating:

protected static final List CATEGORY_TYPE_DEFAULT_ = 
(List)((EFactory)AddressFactory.INSTANCE).createFromString(AddressPackageImpl.eINSTANCE.getCategoryType(),
 myCat);

A temporary workagound is to change it by hand after generating.

 [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
 Attachments: Address.xsd, Address2.xsd


 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] Commented: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1505:
-

The way the register method is using a boolean to guard against cycles is no 
good:

  private boolean registered = false;
  public void register(HelperContext scope) 
  {
if( registered ) return; else registered = true;
if(scope == null) {
  throw new IllegalArgumentException(Scope can not be null);
}

//Register dependent packages with provided scope
ModelFactory.INSTANCE.register(scope);
tuscany.jira.test1505.base.base.BaseFactory.INSTANCE.register(scope);

// Initialize this package   
TypeHelperImpl th = (TypeHelperImpl)scope.getTypeHelper();
th.getExtendedMetaData().putPackage(NAMESPACE_URI, this);
  }

The problem is that it needs to check if the model is already registered in the 
given scope, but this is checking if it's been registered in any scope.

Here is how I suggest the method should be generated:

  public void register(HelperContext scope) 
  {
if (scope == null) throw new IllegalArgumentException(Scope can not be 
null);

TypeHelperImpl th = (TypeHelperImpl)scope.getTypeHelper();
if (th.getExtendedMetaData().getPackage(NAMESPACE_URI) != null) return;
th.getExtendedMetaData().putPackage(NAMESPACE_URI, this);

//Register dependent packages with provided scope
ModelFactory.INSTANCE.register(scope);
tuscany.jira.test1505.base.base.BaseFactory.INSTANCE.register(scope);
  }


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

 Attachments: 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] Resolved: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1565.
-

Resolution: Invalid

Hi Chris,

This is working as expected. This line:

person2.getList(addressProperty).add(address);

is adding to person2 the same address object from person1. Since it's a 
contained DataObject, SDO removes the object from it's old container (person1). 
See the last paragraph of section 3.1.6 in the spec 
(http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1).

The exception you were seeing sounds like a generated code compatibility issue. 
Make sure you regenerate the classes with the version of SDO that you will run 
them with. If you do that and still see the problem (in the latest from HEAD - 
bug may have been fixed) please reopen the JIRA for it.

Thanks,
Frank.

 CopyHelper.copy() fails to copy schema extensions
 -

 Key: TUSCANY-1565
 URL: https://issues.apache.org/jira/browse/TUSCANY-1565
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: Win XP, IBM JRE 1.4.2  IBM JRE 1.5.0
Reporter: Chris Mildebrandt
 Attachments: Address.xsd, CopyTest.java, Person.xsd


 Hello,
 I've been seeing some weird behavior with the copy implementation. I have two 
 schemas, one with the following line:
 xsd:any namespace=##other processContents=lax minOccurs=0 
 maxOccurs=unbounded/
 I'm inserting the second schema into the first as a part of this extension. 
 When I run the CopyHelper.INSTANCE.copy() method against it, weird things 
 start to happen. 
 The first case:
 Both schema files are defined dynamically. The data objects are created and 
 one is added to the other. That looks like this:
 HelperContext context = HelperProvider.getDefaultContext();
 {
 InputStream in = new File(Person.xsd).toURL().openStream();
 context.getXSDHelper().define(in, null);
 }
 {
 InputStream in = new File(Address.xsd).toURL().openStream();
 context.getXSDHelper().define(in, null);
 }
 DataObject person1 = 
 context.getDataFactory().create(http://www.example.org/Person;, 
 PersonType);
 DataObject address = 
 context.getDataFactory().create(http://www.example.org/Address;, 
 AddressType);
 person1.set(Age, 30);
 person1.set(Name, Jim);
 address.set(Street, 123 Fake St.);
 address.set(City, Springfield);
 address.set(Zip, 46392);
 Property addressProperty = 
 context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, 
 Address, true);
 (person1).getList(addressProperty).add(address);
 
 DataObject person2 = CopyHelper.INSTANCE.copy(person1);
 
 person2.getList(addressProperty).clear();
 person2.getList(addressProperty).add(address);
 When I save the data objects to files, the person1 data object doesn't 
 contain the address data object, but person2 does. When I remove the last 
 line that adds the address to person2, then the person1 data object correctly 
 contains the address data object. I would think the person1 data object 
 shouldn't be affected by changes to the person2 (copy of person1) data object.
 The second case:
 Static classes are generated for the first schema, the second is defined 
 dynamically. Data objects are created for both, and the second is added to 
 the first. That looks like this:
 HelperContext context = HelperProvider.getDefaultContext();
 PersonFactory.INSTANCE.register(context);
 PersonType person1 = PersonFactory.INSTANCE.createPersonType();
 person1.setAge(30);
 person1.setName(Jim);
 InputStream in = new File(Address.xsd).toURL().openStream();
 context.getXSDHelper().define(in, null);
 DataObject address = 
 context.getDataFactory().create(http://www.example.org/Address;, 
 AddressType);
 address.set(Street, 123 Fake St.);
 address.set(City, Springfield);
 address.set(Zip, 46392);
 Property addressProperty = 
 context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, 
 Address, true);
 ((DataObject) person1).getList(addressProperty).add(address);
 
 PersonType person2 = (PersonType) 
 CopyHelper.INSTANCE.copy((DataObject) person1);
 
 ((DataObject) person2).getList(addressProperty).clear();
 ((DataObject) person2).getList(addressProperty).add(address);
 When I run with this, I get the following exception:
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: Array 
 index out of range: -2
   at 
 

[jira] Resolved: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1565.
-

Resolution: Cannot Reproduce

I tried it with the latest from HEAD, and there was no exception. I guess it's 
a bug in the 1.0 release that has since been fixed.


 CopyHelper.copy() fails to copy schema extensions
 -

 Key: TUSCANY-1565
 URL: https://issues.apache.org/jira/browse/TUSCANY-1565
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: Win XP, IBM JRE 1.4.2  IBM JRE 1.5.0
Reporter: Chris Mildebrandt
 Attachments: Address.xsd, CopyTest.java, Person.xsd


 Hello,
 I've been seeing some weird behavior with the copy implementation. I have two 
 schemas, one with the following line:
 xsd:any namespace=##other processContents=lax minOccurs=0 
 maxOccurs=unbounded/
 I'm inserting the second schema into the first as a part of this extension. 
 When I run the CopyHelper.INSTANCE.copy() method against it, weird things 
 start to happen. 
 The first case:
 Both schema files are defined dynamically. The data objects are created and 
 one is added to the other. That looks like this:
 HelperContext context = HelperProvider.getDefaultContext();
 {
 InputStream in = new File(Person.xsd).toURL().openStream();
 context.getXSDHelper().define(in, null);
 }
 {
 InputStream in = new File(Address.xsd).toURL().openStream();
 context.getXSDHelper().define(in, null);
 }
 DataObject person1 = 
 context.getDataFactory().create(http://www.example.org/Person;, 
 PersonType);
 DataObject address = 
 context.getDataFactory().create(http://www.example.org/Address;, 
 AddressType);
 person1.set(Age, 30);
 person1.set(Name, Jim);
 address.set(Street, 123 Fake St.);
 address.set(City, Springfield);
 address.set(Zip, 46392);
 Property addressProperty = 
 context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, 
 Address, true);
 (person1).getList(addressProperty).add(address);
 
 DataObject person2 = CopyHelper.INSTANCE.copy(person1);
 
 person2.getList(addressProperty).clear();
 person2.getList(addressProperty).add(address);
 When I save the data objects to files, the person1 data object doesn't 
 contain the address data object, but person2 does. When I remove the last 
 line that adds the address to person2, then the person1 data object correctly 
 contains the address data object. I would think the person1 data object 
 shouldn't be affected by changes to the person2 (copy of person1) data object.
 The second case:
 Static classes are generated for the first schema, the second is defined 
 dynamically. Data objects are created for both, and the second is added to 
 the first. That looks like this:
 HelperContext context = HelperProvider.getDefaultContext();
 PersonFactory.INSTANCE.register(context);
 PersonType person1 = PersonFactory.INSTANCE.createPersonType();
 person1.setAge(30);
 person1.setName(Jim);
 InputStream in = new File(Address.xsd).toURL().openStream();
 context.getXSDHelper().define(in, null);
 DataObject address = 
 context.getDataFactory().create(http://www.example.org/Address;, 
 AddressType);
 address.set(Street, 123 Fake St.);
 address.set(City, Springfield);
 address.set(Zip, 46392);
 Property addressProperty = 
 context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, 
 Address, true);
 ((DataObject) person1).getList(addressProperty).add(address);
 
 PersonType person2 = (PersonType) 
 CopyHelper.INSTANCE.copy((DataObject) person1);
 
 ((DataObject) person2).getList(addressProperty).clear();
 ((DataObject) person2).getList(addressProperty).add(address);
 When I run with this, I get the following exception:
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: Array 
 index out of range: -2
   at 
 org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
   at 
 org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
   at 
 org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
   at 
 org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1027)
   at 
 org.apache.tuscany.sdo.impl.DataObjectBase.inverseRemove(DataObjectBase.java:307)
   at 
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky reopened TUSCANY-1540:
-


Reopening this issue until the test case is added.

Murtaza, thanks for providing the patch.

 Abstract Static Base Types mixed with Dynamic Extended Types
 

 Key: TUSCANY-1540
 URL: https://issues.apache.org/jira/browse/TUSCANY-1540
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Murtaza Goga
 Fix For: Java-SDO-Next

 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-1541) XMLStreamException in when calling XMLHelper.load() with a large XML

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1541:


Component/s: (was: Java SDO Implementation)
 Java SCA Problem Determination

Seems to be an SCA transformation problem.

 XMLStreamException in when calling XMLHelper.load() with a large XML
 

 Key: TUSCANY-1541
 URL: https://issues.apache.org/jira/browse/TUSCANY-1541
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Problem Determination
Affects Versions: Java-SDO-Next
 Environment: Tomcat
Reporter: Sunny Ip
Priority: Critical
 Fix For: Java-SDO-Next


 When XMLHelper.load() is called with a very long XML string, OMStAXWrapper 
 throws an XMLStreamException. I get this problem when I'm receiving a WS 
 response with an SDO object containing a collection of records, leading to a 
 TransformationException when databinding. 

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


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

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1528.
-

Resolution: Fixed

Committed revision 567056.

Fuhwei's patch broke some of the CTS tests which I also fixed against this 
JIRA. The tests were not expecting a DocumentRoot Type to be included in the 
list returned from XSDHelper.define(). Those tests should not have been making 
any assumptions about DocumentRoot anyway, since it's implentation dependent.

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

 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] Commented: (TUSCANY-1498) Improve SubstitutionValuesTestCase

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1498:
-

This test is failing for me:

assertTrue(hc.getEqualityHelper().equal(loadedObject, createdObject));

Not sure if it's a bug in the test or the impl.

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

 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] Created: (TUSCANY-1545) Change default XML encoding to UTF-8.

[Frank Budinsky (JIRA)]

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


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] Resolved: (TUSCANY-1498) Improve SubstitutionValuesTestCase

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1498.
-

Resolution: Fixed

I changed the test to set the local groupHead property (instead of the global 
one) and committed in revision 567093.

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

 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] Commented: (TUSCANY-1498) Improve SubstitutionValuesTestCase

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1498:
-

Problem is that when loading substitutionValues2.xml, the effect is like 
setting the local groupHead property - i.e., dataObject.set(groupHead, ...) - 
which is different from dataObject.set(groupHeadGlobalProperty, ...), even 
though they look the same. EqualityHelper checks that the settings are using 
the exact same property, but since one is the local property of the type while 
the other is the global property, the test fails.

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

 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] Resolved: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1540.
-

Resolution: Fixed

Fixed in revision 566876.

I changed the generator to generate a concrete inner subclass for abstract Impl 
classes:

public abstract class AbstractTestImpl extends DataObjectBase implements 
AbstractTest
{
  public static class ConcreteBase extends AbstractTestImpl
  {
public ConcreteBase()
{
  super();
}
  }
  ...
}

and  then added code in FactoryBase$SDOEFactoryImpl.create() to use it if the 
type is abstract.

I've tested it with the following simple program:

  public static void main(String[] args) throws IOException
  {
HelperContext context = SDOUtil.createHelperContext();
Junk3Factory.INSTANCE.register(context);

TypeHelper typeHelper = context.getTypeHelper();
DataFactory factory = context.getDataFactory();
Type abstractType = typeHelper.getType(http://www.example.org/junk/;, 
AbstractTest);

//DataObject testObject = factory.create(abstractType); // should fail

// Create an subtype
DataObject exampleType = DataFactory.INSTANCE.create(commonj.sdo, Type);
exampleType.set(uri, NSURI);
exampleType.set(name, Example);
exampleType.getList(baseType).add(abstractType);
Type type = TypeHelper.INSTANCE.define(exampleType);

DataObject testObject2 = factory.create(type);

if (testObject2.getClass() == AbstractTestImpl.ConcreteBase.class)
  System.out.println(SUCCESS);
else
  System.out.println(FAIL);
  }

It would be good to get a proper JUnit for it. Any volunteers?


 Abstract Static Base Types mixed with Dynamic Extended Types
 

 Key: TUSCANY-1540
 URL: https://issues.apache.org/jira/browse/TUSCANY-1540
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Murtaza Goga
 Fix For: Java-SDO-Next


 Setting a property on a static data object with an object of a type extended 
 in a dynamic model results in a ClassCastException.
 Scenario:
 Static schema-
   xsd:complexType name=CustomerType
 xsd:all
   xsd:element name=number type=xsd:integer /
   xsd:element form=unqualified name=info type=InfoType /
 /xsd:all
   /xsd:complexType
   
   xsd:complexType name=InfoType abstract=true/
 Dynamic Schema
 xsd:complexType name=InfoType
   xsd:complexContent
 xsd:extension base=staticNS:InfoType
   xsd:sequence
 xsd:element name=zipcode type=xsd:string /
   /xsd:sequence
 /xsd:extension
   /xsd:complexContent
 /xsd:complexType
 The following will fail:
 DataFactory factory = scope.getDataFactory();
 factory.create(CustomerType.class).setDataObject(info, 
 factory.create(dynamicNS, InfoType));
 It should be legal to assign a property to an object if they are in the same 
 hierachy.
 Steps to reproduce within Tuscany:
 Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 
 'InfoType' defined in extensible/customer.xsd  is marked as abstract.

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


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

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1505:
-

This code doesn't make any sense.  Why are you generating a variable at all, 
which then isn't even used? You should just call the init() methods of the 
dependent packages.

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

 Attachments: 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-1527) Allow for custom data binding of DataObjects in a Swing UI

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1527:


  Component/s: Java SDO Implementation
Fix Version/s: Java-SDO-Next

 Allow for custom data binding of DataObjects in a Swing UI
 --

 Key: TUSCANY-1527
 URL: https://issues.apache.org/jira/browse/TUSCANY-1527
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: bert.robben
 Fix For: Java-SDO-Next

 Attachments: com.zip


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

[jira] Resolved: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1490.
-

Resolution: Duplicate

This is covered by https://issues.apache.org/jira/browse/TUSCANY-1505

 Compile error when generating a schema with a dependency on another schema 
 with the same leaf element name
 --

 Key: TUSCANY-1490
 URL: https://issues.apache.org/jira/browse/TUSCANY-1490
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-SDO-Next
Reporter: Sunny Ip
Priority: Minor
 Attachments: helloworld.wsdl, helloworld.xsd, SDOFactoryClass.java


 When generating SDO classes using XSD2JavaGenerator, the FactoryImpl 
 generated from a schema with a dependency on another schema with the same 
 leaf element name (e.g. http://sample/helloworld and 
 http://sample/type/helloworld) results in a compile error in the init() 
 method, where the full package name (including .) is used as part of 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] Commented: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1505:
-

Looking at this more closely, I wonder if this is needed at all, since it looks 
like initializeMetaData() also does the same thing.

I think you should look at this whole pattern more carefully. I would suggest a 
test case that has cyclic dependenices, e.g., A.xsd (with an element of a type 
in B.xsd) and B.xsd (with an element of a type in A.xsd).

The key to this is to make sure that all dependent metaobjects are available 
(have been created) by the time they're needed in initializeMetaData().



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

 Attachments: 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] Commented: (TUSCANY-1479) The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535 bytes limit

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516038
 ] 

Frank Budinsky commented on TUSCANY-1479:
-

The SDO generator in RAD is the Eclipse EMF generator supporting SDO 1.0. The 
EMF codegenerator supports a large model pattern, whereby if a model is very 
large, instead of generating code to initialize the metadata, it generates a 
call to load the metadata from a file. The Tuscany SDO generator does not 
currently have a similar feature, although it would be good to add one. Perhaps 
you'd like to open a JIRA feature request for that.

In the meantime, the workaround is to manually break up the createXSDMetaData() 
method into several smaller methods.

 The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535 
 bytes limit
 -

 Key: TUSCANY-1479
 URL: https://issues.apache.org/jira/browse/TUSCANY-1479
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
 Environment: Rational 7.0.0.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 
 j9vmxi3223ifx-20070323 (JIT enabled)
Reporter: Eric Coolman

 I am attempting to have a number of root objects creatable from a single 
 factory, ie. my main xsd contains a number of imports:
 xsd:include schemaLocation=SyncItemClass.xsd/
 xsd:include schemaLocation=SyncCatalog.xsd/
 xsd:include schemaLocation=AddRFQ.xsd/
 xsd:include schemaLocation=CancelRFQ.xsd/
 xsd:include schemaLocation=ProcessPO.xsd/
 ... etc.
 This works well for me with the SDO Generator in RAD, but tuscany is 
 generating a very large createXSDMetaData() method that will not compile:
 java.lang.Error: Unresolved compilation problem: 
   The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 
 65535 bytes limit
   at 
 com.ibm.ocs.sdo.impl.SdoFactoryImpl.createXSDMetaData(SdoFactoryImpl.java:10695)
   at 
 com.ibm.ocs.sdo.impl.SdoFactoryImpl.initializeMetaData(SdoFactoryImpl.java:10692)
   at com.ibm.ocs.sdo.impl.SdoFactoryImpl.init(SdoFactoryImpl.java:3455)
   at com.ibm.ocs.sdo.SdoFactory.clinit(SdoFactory.java:28)
   at java.lang.J9VMInternals.initializeImpl(Native Method)
   at java.lang.J9VMInternals.initialize(J9VMInternals.java:187)
   at 
 com.ibm.ocs.sdo.test.ProcessPOTestCase.testSerializePO(ProcessPOTestCase.java:42)
   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)
 The createXSDMetaData method looks like this fragment:
   protected void createXSDMetaData(ModelFactoryImpl theModelPackageImpl)
   {
 super.initXSD();
 
 Property property = null;
 
 addXSDMapping
   (acknowledgeCompanyType,
new String[] 
{
name, AcknowledgeCompany,
kind, elementOnly
});
 addXSDMapping
   (getProperty(acknowledgeCompanyType, 
 AcknowledgeCompanyImpl.INTERNAL_HEADER),
new String[]
{
kind, element,
name, header
});
 addXSDMapping
   (controlVerbType,
new String[] 
{
name, ControlVerb,
baseType, commonj.sdo#String,
enumeration, GET GETLIST SHOW LIST VALIDATE ACKNOWLEDGE ADD CHANGE 
 CANCEL PROCESS REGISTER RESPOND SYNC
});
 addXSDMapping
   (countryCodeType,
new String[] 
{
name, countryCode,
baseType, commonj.sdo#String,
enumeration, AD AE AF AG 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1483:
-

I think that all that's necessary to make this change is globally replace 
INTERNAL_ with _INTERNAL_ in SDOClass.javajet and SDOFactory.javajet.

 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


 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] Commented: (TUSCANY-1470) Generated SDO APIs have compilation errors when sub-type has the same name as super-type

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514621
 ] 

Frank Budinsky commented on TUSCANY-1470:
-

The bug is in SDOClass.javajet. The calls to base.getClassName() should be 
base.getImportedName() (in 9 places). Please make the change and confirm that 
it fixes the problem. Thanks.


 Generated SDO APIs have compilation errors when sub-type has the same name as 
 super-type
 

 Key: TUSCANY-1470
 URL: https://issues.apache.org/jira/browse/TUSCANY-1470
 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.0


 Run the codegen tool on src/test/resources/extensible/infostreet.xsd. The 
 generated code like the one below cannot be compiled because 
 SDO_PROPERTY_COUNT becomes ambiguous.
 *infostreet.xsd*
 xsd:complexType name=InfoType
   xsd:complexContent
   xsd:extension base=customer:InfoType
   xsd:sequence
   xsd:element name=street 
 type=xsd:string /
   /xsd:sequence
   /xsd:extension
   /xsd:complexContent
   /xsd:complexType
 public class InfoTypeImpl extends InfoTypeImpl implements InfoType
 {
   public final static int STREET = InfoTypeImpl.SDO_PROPERTY_COUNT + 0;
   public final static int SDO_PROPERTY_COUNT = 
 InfoTypeImpl.SDO_PROPERTY_COUNT + 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] Commented: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514240
 ] 

Frank Budinsky commented on TUSCANY-1143:
-

I tracked down two places that the global EMF registry was being used. Fixes 
are needed in TypeImpl.getInstanceClassName() and 
DataObjectBase.resolveProxy(). Here are my fixed versions of the two methods:

  public String getInstanceClassName()
  {
if (javaClassFeature == null)
{
  //FB TODO figure out what helper to use
  javaClassFeature = 
(EStructuralFeature)TypeHelper.INSTANCE.getOpenContentProperty(commonj.sdo/java,
 javaClass);
}

Sequence anyAttribute = getAnyAttribute();
int count = anyAttribute.size();
for (int i = 0; i  count; i++)
{
  EStructuralFeature eFeature = 
(EStructuralFeature)anyAttribute.getProperty(i);
  if (eFeature == javaClassFeature)
  {
return (String)anyAttribute.getValue(i);
  }
}
return null;
  }

  protected Object resolveProxy(Object proxy)
  {
Resource resource = this.eResource();
ResourceSet resourceSet = resource != null ? resource.getResourceSet() : 
null;
if (resourceSet != null) return EcoreUtil.resolve((EObject)proxy, 
resourceSet);

URI proxyURI = ((InternalEObject)proxy).eProxyURI();
if (proxyURI != null)
{
  EPackage ePackage = 
HelperContextImpl.getBuiltInModelRegistry().getEPackage(proxyURI.trimFragment().toString());
  if (ePackage != null)
  {
resource = ePackage.eResource();
if (resource != null)
{
  return resource.getEObject(proxyURI.fragment().toString());
}
  }
}


 Generated code should separate metadata creation from registration to permit 
 proper scoping
 ---

 Key: TUSCANY-1143
 URL: https://issues.apache.org/jira/browse/TUSCANY-1143
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson
 Fix For: Java-SDO-1.0

 Attachments: 1143.patch, 1143.patch, 1143.patch


 The switch to registration of metadata from the global scope to selected 
 scopes is not complete yet, although for all current test cases there are no 
 failures.
 Currently the generated init() method for a factory calls the deprecated 
 SDOUtil.registerStaticTypes for its simple dependencies.
 In the simple case this is just ModelFactory and SDOFactory,  but could 
 contain other user generated dependencies if for example
 there were to be an xsd import of another namespace (exposed a gap in our 
 test case set).  This would mean that the user generated model dependency
 would also be registered against the global registry.
 It is proposed that all registrations, including the built in models, are 
 made against the helper context provided to the Factory's register method.
 I.e. a state invariant that no models are ever registered against the global 
 registry.
 The pattern of looking up models from within packages is not required, since 
 the code can just refer to each model's singleton INSTANCE (see below for the 
 exception SDOFactoryImpl).  Creation of the metadata should be done in the 
 init
 method, and the registration of all metadata (built-in or otherwise) should 
 be done in the register method. It would appear on inspection that no 
 reference to the simple dependencies of a factory need be made in its init 
 method,  and simple reference to the dependencies INSTANCE in the register 
 will be enough to ensure that those dependencies are initialised before being 
 registered against the provided scope. 
 SDOFactoryImpl does not have an INSTANCE currently.  The current proposed 
 solution is to modify SDOFactory to have an INSTANCE, in order that it can 
 behave like an ordinary generated dependency in this new approach.

-- 
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-1457) Unable to code gen SDOModel.xsd

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513997
 ] 

Frank Budinsky commented on TUSCANY-1457:
-

The problem is that sdoModel.xsd includes datagraph.xsd. The SchemaLocator 
class in SDOXSDEcoreBuilder needs to avoid looking up the model in the package 
registry if locateSchema is being called for an include. I'll attach a patch.
 

 Unable to code gen SDOModel.xsd
 ---

 Key: TUSCANY-1457
 URL: https://issues.apache.org/jira/browse/TUSCANY-1457
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-1.0


 When I attempt to generate the java source files representing the SDOModel, I 
 am seeing a NPE thrown in SDOXSDEcoreBuilder.java.  Here is the stack trace:
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104)
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96)
 I've tracked the issue down to some code changes made for T-513.  A change 
 was made in XSDHelperImpl in the define method to change how the ResourceSet 
 is constructed prior to loading the schema.  Additional changes were made in 
 SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet.  
 These combined changes seem to be precipitating the issue.  The 
 XSDSchemaAdapterFactoryImpl inner class contains a method 
 isFactoryForType(Object) that appears to be setting up conditions such that 
 more elementDeclarations than should be expected is being created, later 
 leading to the NPE.

-- 
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-1457) Unable to code gen SDOModel.xsd

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1457:


Attachment: 1457.patch

 Unable to code gen SDOModel.xsd
 ---

 Key: TUSCANY-1457
 URL: https://issues.apache.org/jira/browse/TUSCANY-1457
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-1.0

 Attachments: 1457.patch


 When I attempt to generate the java source files representing the SDOModel, I 
 am seeing a NPE thrown in SDOXSDEcoreBuilder.java.  Here is the stack trace:
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104)
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96)
 I've tracked the issue down to some code changes made for T-513.  A change 
 was made in XSDHelperImpl in the define method to change how the ResourceSet 
 is constructed prior to loading the schema.  Additional changes were made in 
 SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet.  
 These combined changes seem to be precipitating the issue.  The 
 XSDSchemaAdapterFactoryImpl inner class contains a method 
 isFactoryForType(Object) that appears to be setting up conditions such that 
 more elementDeclarations than should be expected is being created, later 
 leading to the NPE.

-- 
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-1457) Unable to code gen SDOModel.xsd

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1457:


Attachment: 1457.patch

 Unable to code gen SDOModel.xsd
 ---

 Key: TUSCANY-1457
 URL: https://issues.apache.org/jira/browse/TUSCANY-1457
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-1.0

 Attachments: 1457.patch


 When I attempt to generate the java source files representing the SDOModel, I 
 am seeing a NPE thrown in SDOXSDEcoreBuilder.java.  Here is the stack trace:
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104)
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96)
 I've tracked the issue down to some code changes made for T-513.  A change 
 was made in XSDHelperImpl in the define method to change how the ResourceSet 
 is constructed prior to loading the schema.  Additional changes were made in 
 SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet.  
 These combined changes seem to be precipitating the issue.  The 
 XSDSchemaAdapterFactoryImpl inner class contains a method 
 isFactoryForType(Object) that appears to be setting up conditions such that 
 more elementDeclarations than should be expected is being created, later 
 leading to the NPE.

-- 
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-1457) Unable to code gen SDOModel.xsd

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1457:


Attachment: (was: 1457.patch)

 Unable to code gen SDOModel.xsd
 ---

 Key: TUSCANY-1457
 URL: https://issues.apache.org/jira/browse/TUSCANY-1457
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-1.0

 Attachments: 1457.patch


 When I attempt to generate the java source files representing the SDOModel, I 
 am seeing a NPE thrown in SDOXSDEcoreBuilder.java.  Here is the stack trace:
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104)
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96)
 I've tracked the issue down to some code changes made for T-513.  A change 
 was made in XSDHelperImpl in the define method to change how the ResourceSet 
 is constructed prior to loading the schema.  Additional changes were made in 
 SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet.  
 These combined changes seem to be precipitating the issue.  The 
 XSDSchemaAdapterFactoryImpl inner class contains a method 
 isFactoryForType(Object) that appears to be setting up conditions such that 
 more elementDeclarations than should be expected is being created, later 
 leading to the NPE.

-- 
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-1457) Unable to code gen SDOModel.xsd

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1457.
-

Resolution: Fixed

Fixed in revision 557781.

 Unable to code gen SDOModel.xsd
 ---

 Key: TUSCANY-1457
 URL: https://issues.apache.org/jira/browse/TUSCANY-1457
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-1.0

 Attachments: 1457.patch


 When I attempt to generate the java source files representing the SDOModel, I 
 am seeing a NPE thrown in SDOXSDEcoreBuilder.java.  Here is the stack trace:
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104)
   at 
 org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413)
   at 
 org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146)
   at 
 org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96)
 I've tracked the issue down to some code changes made for T-513.  A change 
 was made in XSDHelperImpl in the define method to change how the ResourceSet 
 is constructed prior to loading the schema.  Additional changes were made in 
 SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet.  
 These combined changes seem to be precipitating the issue.  The 
 XSDSchemaAdapterFactoryImpl inner class contains a method 
 isFactoryForType(Object) that appears to be setting up conditions such that 
 more elementDeclarations than should be expected is being created, later 
 leading to the NPE.

-- 
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-1459) Remove package registry delegation to EPackage.Registry.INSTANCE

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514015
 ] 

Frank Budinsky commented on TUSCANY-1459:
-

Patch looks perfect!

Can we apply it or does it cause breakage if not syncronized with TUSCANY-1143?


 Remove package registry delegation to EPackage.Registry.INSTANCE
 

 Key: TUSCANY-1459
 URL: https://issues.apache.org/jira/browse/TUSCANY-1459
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
Priority: Critical
 Fix For: Java-SDO-1.0

 Attachments: 1459.patch


 This improvement is to reduce today's 3 tier registry delegation mechanism to 
 2 tier's so we won't rely on EPackage.Registry.INSTANCE.
 Current design:
 The default HelperContext created by using HelperProvider.getDefaultContext() 
 is using the EPackage.Registry.INSTANCE as its package registry that can be 
 delegated to the TCCL's registry. The local HelperContext created by using 
 api.SDOUtil.createHelperContext() is creating a local package registry that 
 can delegate to the builtInModelRegistry that potentially delegates to the 
 EPackage.Registry.INSTANCE.
 default HelperContext (EPackage.Registry.INSTANCE/TCCL based)
 local HelperContext (local package registry) --delegate-- 
 builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE
 EMF, SDO runtime models, SDO type models are resided in the 
 EPackage.Registry.INSTANCE
 SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) 
 are resided in both builtInModelRegistry and
 EPackage.Registry.INSTANCE (registered in the FactoryBase.java)
 User models will reside either in the EPackage.Registry.INSTANCE or local 
 package registry
 New design:
 The builtInModelRegistry will become the end of registry delegation chain 
 that would contain all required EMF and SDO runtime models and type models. 
 The user models will reside at the local registry created for the helper 
 context. If it's the default helper context, the special registry will be the 
 SDOPackageRegistryDelegator that is similar to 
 EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and 
 at the end of chain delegates to the builtInModelRegistry. If it's the local 
 HelperContext, a regular Hashmap registry will be used then delegates to the 
 builtInModelRegistry.
 default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- 
 builtInModelRegistry
 local HelperContext (local package registry) --delegate-- 
 builtInModelRegistry
 EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry
 User models will reside either in the SDOPackageRegistryDelegator(TCCL based) 
 or local package registry

-- 
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-1459) Remove package registry delegation to EPackage.Registry.INSTANCE

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1459.
-

Resolution: Fixed

Committed revision 557838.

 Remove package registry delegation to EPackage.Registry.INSTANCE
 

 Key: TUSCANY-1459
 URL: https://issues.apache.org/jira/browse/TUSCANY-1459
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
Priority: Critical
 Fix For: Java-SDO-1.0

 Attachments: 1459.patch


 This improvement is to reduce today's 3 tier registry delegation mechanism to 
 2 tier's so we won't rely on EPackage.Registry.INSTANCE.
 Current design:
 The default HelperContext created by using HelperProvider.getDefaultContext() 
 is using the EPackage.Registry.INSTANCE as its package registry that can be 
 delegated to the TCCL's registry. The local HelperContext created by using 
 api.SDOUtil.createHelperContext() is creating a local package registry that 
 can delegate to the builtInModelRegistry that potentially delegates to the 
 EPackage.Registry.INSTANCE.
 default HelperContext (EPackage.Registry.INSTANCE/TCCL based)
 local HelperContext (local package registry) --delegate-- 
 builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE
 EMF, SDO runtime models, SDO type models are resided in the 
 EPackage.Registry.INSTANCE
 SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) 
 are resided in both builtInModelRegistry and
 EPackage.Registry.INSTANCE (registered in the FactoryBase.java)
 User models will reside either in the EPackage.Registry.INSTANCE or local 
 package registry
 New design:
 The builtInModelRegistry will become the end of registry delegation chain 
 that would contain all required EMF and SDO runtime models and type models. 
 The user models will reside at the local registry created for the helper 
 context. If it's the default helper context, the special registry will be the 
 SDOPackageRegistryDelegator that is similar to 
 EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and 
 at the end of chain delegates to the builtInModelRegistry. If it's the local 
 HelperContext, a regular Hashmap registry will be used then delegates to the 
 builtInModelRegistry.
 default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- 
 builtInModelRegistry
 local HelperContext (local package registry) --delegate-- 
 builtInModelRegistry
 EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry
 User models will reside either in the SDOPackageRegistryDelegator(TCCL based) 
 or local package registry

-- 
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-1110) Improve the performance of TypeHelperImpl.getType(Class)

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513250
 ] 

Frank Budinsky commented on TUSCANY-1110:
-

I don't think this looks right:

sdoTypeImplClass = Class.forName(sdoTypeImplClassName);

Doesn't it need to use the ClassLoader of the interfaceClass to do this?

Frank.

 Improve the performance of TypeHelperImpl.getType(Class)
 

 Key: TUSCANY-1110
 URL: https://issues.apache.org/jira/browse/TUSCANY-1110
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Raymond Feng
 Fix For: Java-SDO-1.0

 Attachments: 1110.patch


 In the SDO databinding for SCA, we need to introspect a java class/interface 
 to figure out the corresponding SDO type. Looking into the code, there is a 
 TODO comment:
 //TODO more efficient implementation ... this is a really bad one!
 Do you plan to provide a more efficient impl :-)?
 Thanks,
 Raymond

-- 
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-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1380.
-

Resolution: Fixed

I changed aaa[1] to nonexistentProperty in revision 556085.

 DataObjectListTest.testGetInvalidInstanceProperty is invalid
 

 Key: TUSCANY-1380
 URL: https://issues.apache.org/jira/browse/TUSCANY-1380
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Fix For: Java-SDO-CTS-Next


 The following callin DataObjectListTest.testGetInvalidInstanceProperty  is 
 invalid because getInstanceProperty() is not intended to work with xpath 
 expressions, just property names.
 testObj.getInstanceProperty(aaa[1]);
 I don't have committer rights yet. Could someone please mark this test 
 @Ignore for the moment.
 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] Resolved: (TUSCANY-1421) XMLHelper.save on root object of DataGraph gives serialization of href=root.xml#/

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1421.
-

Resolution: Fixed

Fixed in revision 556147.

 XMLHelper.save on root object of DataGraph gives serialization of 
 href=root.xml#/
 ---

 Key: TUSCANY-1421
 URL: https://issues.apache.org/jira/browse/TUSCANY-1421
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson

 There's an issue reported on the user list ...
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200707.mbox/[EMAIL 
 PROTECTED]
 which relates to a some missing logic in XMLDocumentImpl's save method
 The precondition for hitting this issue is when the data object is the root 
 data object of a DataGraph.  In this case the eContainer of the root object 
 is null,  but the root object is contained in a resource.  We need to 
 replicate the unhooking and replacing behaviour that exists for the container 
 of the data object for the case where the data object is directly contained 
 in a resource.

-- 
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-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls

[Frank Budinsky (JIRA)]

SDO codegen is needs to use internal property numbers for inverseAdd, 
inverseRemove, and notify calls
-

 Key: TUSCANY-1430
 URL: https://issues.apache.org/jira/browse/TUSCANY-1430
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Frank Budinsky
 Fix For: Java-SDO-1.0


The SDOClass.javajet needs to use INTERNAL_ features when calling inverseAdd(), 
inverseRemove(), and notify() methods. ChangeSummary doesn't work properly 
otherwise.

-- 
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-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512278
 ] 

Frank Budinsky commented on TUSCANY-1430:
-

Test case that illustrates the problem:

The XSD:

xsd:schema xmlns=http://www.w3.org/2001/XMLSchema;
 targetNamespace=http://abc.com/services;
 xmlns:tns=http://abc.com/services;
 xmlns:sdo=commonj.sdo xmlns:sdoJava=commonj.sdo/java 
xmlns:sdoXml=commonj.sdo/xml
 sdoJava:package=com.abc.services
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;

 xsd:import namespace=commonj.sdo schemaLocation=datagraph.xsd /

 xsd:complexType name=NestedType
 xsd:sequence
 xsd:element name=test1 
type=xsd:string /
 xsd:element name=test2 
type=xsd:string /
 /xsd:sequence
 /xsd:complexType

 xsd:complexType name=MyDataGraph
 complexContent
 extension base=sdo:BaseDataGraphType
 xsd:sequence
 xsd:element name=NestedType 
type=tns:NestedType /
 /xsd:sequence
 /extension
 /complexContent
 /xsd:complexType

 xsd:complexType name=Input
 xsd:sequence
   xsd:element name=MyDataGraph type=tns:MyDataGraph/
 /xsd:sequence
 /xsd:complexType
/xsd:schema

The Java Test:
==

package com.abc.services;

import java.io.ByteArrayOutputStream;
import java.io.IOException;

import org.apache.tuscany.sdo.util.SDOUtil;

import com.abc.services.impl.TestFactoryImpl;
import commonj.sdo.DataGraph;
import commonj.sdo.DataObject;
import commonj.sdo.Type;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;


public class TestABC {

public static void main(String[] args) {

TestFactory.INSTANCE.register(HelperProvider.getDefaultContext());
NestedType nested;

System.out.println( static graph 
**\n);

Input input = TestFactory.INSTANCE.createInput();

MyDataGraph staticGraph = TestFactory.INSTANCE.createMyDataGraph();
nested = TestFactory.INSTANCE.createNestedType();
staticGraph.setNestedType(nested);
((DataObject)nested).set(test1, test1);
((DataObject)nested).set(test2, test2);
staticGraph.getChangeSummary().beginLogging();
((DataObject)nested).set(test2, test2_modified);
nested.setTest1(test1_modified);

input.setMyDataGraph(staticGraph);

saveGraph(staticGraph);

System.out.println(\n\n);

System.out.println( dynamic graph 
**\n);

DataGraph dynamicGraph = SDOUtil.createDataGraph();

Type type = ((TestFactoryImpl)TestFactory.INSTANCE).getNestedType();
nested = (NestedType)dynamicGraph.createRootObject(type);
((DataObject)nested).set(test1, test1);
((DataObject)nested).set(test2, test2);
   
dynamicGraph.getChangeSummary().beginLogging();
((DataObject)nested).set(test2, test2_modified);
nested.setTest1(test1_modified);

saveGraph(dynamicGraph);
}

/**
 * @param dataobject
 */
private static void saveGraph(MyDataGraph dataobject) {
ByteArrayOutputStream os = new ByteArrayOutputStream();
try {
XMLHelper.INSTANCE.save((DataObject)dataobject, null, datagraph, 
os);
System.out.println(os.toString());
} catch (IOException e) {
e.printStackTrace();
}
}

/**
 * @param datagraph
 */
private static void saveGraph(DataGraph datagraph) {
try {
ByteArrayOutputStream os = new ByteArrayOutputStream();
SDOUtil.saveDataGraph(datagraph, os, null);
System.out.println(os.toString());
} catch (IOException e1) {
e1.printStackTrace();
}
}
}


 SDO codegen is needs to use internal property numbers for inverseAdd, 
 inverseRemove, and notify calls
 -

 Key: TUSCANY-1430
 URL: https://issues.apache.org/jira/browse/TUSCANY-1430
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Frank Budinsky
 Fix For: Java-SDO-1.0


 The SDOClass.javajet needs to use INTERNAL_ features when calling 
 inverseAdd(), inverseRemove(), and notify() methods. ChangeSummary doesn't 
 work properly otherwise.

-- 
This 

[jira] Resolved: (TUSCANY-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1430.
-

Resolution: Fixed

Fixed in revision 555790.

 SDO codegen is needs to use internal property numbers for inverseAdd, 
 inverseRemove, and notify calls
 -

 Key: TUSCANY-1430
 URL: https://issues.apache.org/jira/browse/TUSCANY-1430
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Frank Budinsky
 Fix For: Java-SDO-1.0


 The SDOClass.javajet needs to use INTERNAL_ features when calling 
 inverseAdd(), inverseRemove(), and notify() methods. ChangeSummary doesn't 
 work properly otherwise.

-- 
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-1408) Cannot programmatically define a SDO property matching to XSD element

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510683
 ] 

Frank Budinsky commented on TUSCANY-1408:
-

The spec says this in section 7.1.3:

The xmlElement property is set to true on Properties that are represented as 
XML elements.  If no value is present there is no information about the 
mapping.  If the value is false, it indicates that it is not an element, but it 
does not guarantee that there is mapping to an XML attribute. Only if the 
property was defined using an XML Schema will a value of false indicate that 
the property maps to an attribute. If the property was defined using other 
means, for example, TypeHelper.define(), then a value of false indicates a 
desire to represent the property as an attribute, but it may not be possible. 
For example, a containment or nullable property must be serialized as an XML 
element.

So, what I think is the simplest approach that is compliant and also works is 
to simply make Element the default. If we want to also add support for 
xmlElement=False, we need to make sure that we set it back to Element in 
setContainment and setNullable (any where else?) methods.

I'm also not sure if we should be adding the xmlElment argument to the 
createProperty method, since it's an XML specific thing. It would probably be 
better to have a setPropertyXMLKind(Property, boolean) method instead, which is 
called after createProperty().

 Cannot programmatically define a SDO property matching to XSD element
 -

 Key: TUSCANY-1408
 URL: https://issues.apache.org/jira/browse/TUSCANY-1408
 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.0

 Attachments: 1408.patch


 The following code will define XSD attributes for name and address 
 properties. I cannot find a way to define them as XSD elements.
 HelperContext hc = HelperProvider.getDefaultContext();
 DataFactory dataFactory = hc.getDataFactory();
 TypeHelper types = hc.getTypeHelper();
 Type stringType = types.getType(commonj.sdo, String);
 
 DataObject customerType = dataFactory.create(commonj.sdo,Type);
 customerType.set(uri, http://sample.data/customer;);
 customerType.set(name, Customer);
 //create customer name property
 DataObject custNameProperty = customerType.createDataObject(property);
 custNameProperty.set(name, name);
 custNameProperty.set(type, stringType);
 //create address property
 DataObject addressProperty = customerType.createDataObject(property);
 addressProperty.set(name, address);
 addressProperty.set(type, stringType);
 //now define the Customer type so that customers can be made
 Type typeDefined = types.define(customerType);

-- 
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-1410) DataHelperImpl.toCalendar() with null locale should use default locale

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1410.
-

Resolution: Fixed

Fixed in revision 553921.

 DataHelperImpl.toCalendar() with null locale should use default locale
 --

 Key: TUSCANY-1410
 URL: https://issues.apache.org/jira/browse/TUSCANY-1410
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Andy Grove
Priority: Minor

 DataHelperImpl.toCalendar() currently returns null if the locale parameter is 
 null. However, according to the published SDO API javadoc comments, if locale 
 is null then the default locale should be used. To resolve this, the 
 following code can be added at the start of the method.
 if (locale == null) {
   locale = Locale.getDefault();
 }

-- 
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-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-1364:


  Component/s: Java SDO Implementation
Fix Version/s: Java-SDO-1.0
Affects Version/s: Java-SDO-beta1

 sdo-impl should export org.apache.tuscany.sdo.model.internal
 

 Key: TUSCANY-1364
 URL: https://issues.apache.org/jira/browse/TUSCANY-1364
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Reporter: Brian Murray
 Fix For: Java-SDO-1.0

 Attachments: 1364.patch


 The org.apache.tuscany.sdo.model.internal package was introduced somewhat 
 recently, and is visible in a statically generated class.  The problem is 
 that the impl project does not export this package.  
 For example, I ran the XSD2JavaGenerator tool on 
 sdo\impl\src\test\resources\bank.xsd and here are some snippets from the 
 resulting MybankFactory.impl:
 import org.apache.tuscany.sdo.model.internal.InternalFactory;
 ...
   public static MybankFactoryImpl init()
   {
 if (isInited) return 
 (MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
 MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
 isInited = true;
 // Initialize dependencies
 SDOUtil.registerStaticTypes(SDOFactory.class);
 SDOUtil.registerStaticTypes(ModelFactory.class);
 SDOUtil.registerStaticTypes(InternalFactory.class);
 I am providing a patch to the sdo/impl/pom.xml which will export this package.

-- 
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-513) Implement support for dynamic subclasses of statically generated types

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503542
 ] 

Frank Budinsky commented on TUSCANY-513:


Hi Ron,

If I understand this, the only template change you made was to rename the 
getType() method in the generated impl classes to getStaticType(). If that's 
true, I wounldn't go through all the trouble of regening all the generated 
models, but instead I would just manually rename the methods in the necessary 
classes. If we had a better regen story in Tuscany (like EMF has auto merge) 
that would be a different story.

Frank.

 Implement support for dynamic subclasses of statically generated types
 --

 Key: TUSCANY-513
 URL: https://issues.apache.org/jira/browse/TUSCANY-513
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Reporter: Ron Gavlin
 Fix For: Java-SDO-1.0

 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, 
 tuscany-sdo-tools.TUSCANY-513.patch


 Implement support for dynamic subclasses of statically generated types. See 
 below exerpt from tuscany-user mailing list for details.
 Hi Ron,
 Looking at this, it looks like the problem is that you're trying to create 
 dynamic subclasses of statically generated types. The bad news is that 
 Tuscany doesn't currently support that. The good news is that it's not too 
 hard to add the support.
 The problem is that currently Tuscany only has these two primary 
 DataObject implementation classes:
 1. DataObjectImpl - is the base class used for statically generated types. 
 It is highly tuned for performance and footprint, so, unlike the base 
 class in SDO1 (actually EMF) it doesn't support dynamic extensions.
 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
 designed for pure dynamic types, not a mixture of static and dynamic.
 To support what you want, we will need another base class, say 
 ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
 but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
 is that there are only a few simple method overrides needed in this class. 
 Maybe you would like to try to prototype such a class yourself and hand 
 modify your generated classes to extend from it? If you did that and 
 tested it, you could submit a patch and we could then very quickly add a 
 generator option to use it (maybe even make it the default). If you'd like 
 to help with this, it would be very much appreciated!
 At any rate, you should probably open a JIRA feature request for this.
 Thanks,
 Frank
  Frank,
  
  I am working with a mixed static/dynamic model similar to the one 
  listed at the bottom of this post. The http://example.org/ord 
  namespace is statically registered and has code-generated classes. The 
  http://example.org/info/zipcode and http://example.org/info/street 
  namespaces are dynamically registered with no code-generated 
  classes. When I attempt to load the Sample Instance (chapter04.xml),
  I receive an UnsupportedOperationException thrown from 
  DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
  exception is an instance of InfoTypeImpl from the ord 
  namespace/ePackage. The EClass parameter is InfoType from the 
  zipcode namespace. This instance document loads fine using EMF/SDO
  1.0. Any suggestions I can try to work-around this problem?
  
  - Ron
  
  
  Sample Instance (chapter04.xml)
  ord:order xmlns:ord=http://example.org/ord;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://example.org/ord chapter04ord1.xsd
  ord:number123ABBCC123/ord:number
  ord:customer
  ord:namePat Walmsley/ord:name
  ord:number15465/ord:number
  info xsi:type=ns1:InfoType xmlns=
  xmlns:ns1=http://example.org/info/zipcode;
  zipcode21043/zipcode
  /info
  /ord:customer
  ord:customer
  ord:namePriscilla Walmsley/ord:name
  ord:number15466/ord:number
  info xsi:type=ns1:InfoType xmlns=
  xmlns:ns1=http://example.org/info/street;
  street341 Duckworth Way/street
  /info
  /ord:customer
  ord:items
  product
  number557/number
  nameShort-Sleeved Linen Blouse/name
  size system=US-DRESS10/size
  color value=blue/
  /product
  /ord:items
  /ord:order
  Schema Document 1 (chapter04ord1.xsd)
  xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;;
 targetNamespace=http://example.org/ord;;
 xmlns=http://example.org/ord;;
 xmlns:prod=http://example.org/prod;;
 elementFormDefault=qualified
  xsd:import namespace=http://example.org/prod;;
  schemaLocation=chapter04prod.xsd/
   xsd:simpleType name=OrderNumType
 xsd:restriction base=xsd:string/
   /xsd:simpleType
   xsd:complexType name=InfoType/
   xsd:complexType name=CustomerType
 xsd:sequence
   

[jira] Resolved: (TUSCANY-1333) [Java SDO] ClassCastException when defining schema file without .xsd extension

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1333.
-

Resolution: Fixed

I checked in a simple fix in revision 545346. Please test and reopen if it's 
not working. Thanks.

 [Java SDO] ClassCastException when defining schema file without .xsd extension
 --

 Key: TUSCANY-1333
 URL: https://issues.apache.org/jira/browse/TUSCANY-1333
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
 Environment: IBM JDK 1.4.2
Reporter: Chris Mildebrandt

 With the following code:
 HelperContext context = SDOUtil.createHelperContext();
 context.getXSDHelper().define(new FileInputStream(./Person.xsd.tmp), (new 
 File(./Person.xsd.tmp)).toURI().toString());
 I get the following exception:
 java.lang.ClassCastException: 
 org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:245)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:236)
   at Test.doubleContextTest(Test.java:193)
   at Test.main(Test.java:214)
 Exception in thread main java.lang.IllegalArgumentException: 
 org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:278)
   at 
 org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:236)
   at Test.doubleContextTest(Test.java:193)
   at Test.main(Test.java:214)
 If I remove the .tmp from the schema file name, the exception goes away. 

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


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

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1327:
-

If I remember correctly, types defined in wsdl files cannot be imported or 
included in anther schema (they are effectively private local types). The XSD 
spec says that the schemaLocation for an import must have a schema element at 
the root, which says that it can't be a wsdl file).

 Generate static SDO APIs from wsdl files with type definition from 
 wsdl:import and wsdl:include
 ---

 Key: TUSCANY-1327
 URL: https://issues.apache.org/jira/browse/TUSCANY-1327
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Tools
Affects Versions: Java-SDO-M2
 Environment: WinXP
Reporter: Fuhwei Lwo

 Today, SDO codegen tool can recognize and parse wsdl:types content to 
 generate static SDO APIs. However, it ignores wsdl:import and 
 wsdl:include. This means if I have types defined in other wsdl files and 
 they are imported or included by wsdl:import or wsdl:include elements, 
 they won't never get generated.

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


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

[jira] Resolved: (TUSCANY-1322) Static code gen objects not deleting contained children successfully

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1322.
-

Resolution: Duplicate

This sounds like the same problem as in TUSCANY-1305, which was fixed earlier 
this week. Please try to regen and run using the latest from HEAD and reopen if 
you still see a problem.

 Static code gen objects not deleting contained children successfully
 

 Key: TUSCANY-1322
 URL: https://issues.apache.org/jira/browse/TUSCANY-1322
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
Priority: Minor
 Fix For: Java-SDO-1.0


 The SDO 2.1 specification states the following on page 17:
 The delete() method unsets all the DataObject's non-readonly properties. The 
 delete()
 method will also remove the DataObject from its containing DataObject if the
 containment Property is not read-only. All DataObjects recursively contained 
 by
 containment properties will also be deleted.
 So, it is expected that the contained DOs will delete their contained DOs, 
 and so on, until all DOs have been released under the DO where the delete() 
 method was called.  This behavior seems to be working correctly in the case 
 of dynamic DOs, but statically generated DOs are not functioning properly.  
 The contained DOs are still held by their containing DOs.  
 This fault seems to be caused by a failure in how containment is being 
 tracked in how the underlying EMF code was initialized.  The root cause of 
 the failure is a combination of how EMF manages the 
 EClassImpl.eAllStructuralFeatures and how SDO static object types are 
 initialized.  In the EClassImpl object, the eAllStructuralFeatures tracks 
 containment properties via a sub-list.  This sub-list is created ONLY one 
 time.  eAllStructuralFeatures is created the first time, when it is first 
 requested.  For static SDO-based applications, this first time is somewhat 
 random depending on the property types being created.  During static SDO init 
 there are two key functions of note; the createMetaData() method and the 
 intializeMetaData() method.  The createMetaData() method is called first, and 
 all DO properties have an 'empty' properties object created and attached to 
 the DO type.  Then, the initializeMetaData() method is called.  This method 
 'configures' each of the blank property objects.  The problem is that the 
 eAllStructuralFeatures containment list is constructed early in the 
 initializeMetaData() method, before all the properties have been initialized. 
  So, not all containment properties are recognized and therefore placed into 
 the eAllStructuralFeatures containment list.  This then affects the behavior 
 of the DataObjectUtil.delete(DataObject), such that it doesn't properly pull 
 all the contained DOs.
 Attached is a zip file with source code and a test schema.  In the zip is the 
 test client and associated static code gen 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-1322) Static code gen objects not deleting contained children successfully

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500836
 ] 

Frank Budinsky commented on TUSCANY-1322:
-

I can see that the generated Test1322FactoryImpl class has not been regenerated 
with the latest template. If you look at the generated initializeMetaData 
method you'll see that it's calling FactoryBase.getProperty() which has been 
deprecated as part of TUSCANY-1305. If you regen, you'll see that it should now 
be calling a new method, getLocalProperty().

Like I said in my first comment, this problem has already been fixed. Please 
regen your model and try again.


 Static code gen objects not deleting contained children successfully
 

 Key: TUSCANY-1322
 URL: https://issues.apache.org/jira/browse/TUSCANY-1322
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
 Environment: n/a
Reporter: David T. Adcox
Priority: Minor
 Fix For: Java-SDO-1.0

 Attachments: Tuscany1322.patch, Tuscany1322.zip


 The SDO 2.1 specification states the following on page 17:
 The delete() method unsets all the DataObject's non-readonly properties. The 
 delete()
 method will also remove the DataObject from its containing DataObject if the
 containment Property is not read-only. All DataObjects recursively contained 
 by
 containment properties will also be deleted.
 So, it is expected that the contained DOs will delete their contained DOs, 
 and so on, until all DOs have been released under the DO where the delete() 
 method was called.  This behavior seems to be working correctly in the case 
 of dynamic DOs, but statically generated DOs are not functioning properly.  
 The contained DOs are still held by their containing DOs.  
 This fault seems to be caused by a failure in how containment is being 
 tracked in how the underlying EMF code was initialized.  The root cause of 
 the failure is a combination of how EMF manages the 
 EClassImpl.eAllStructuralFeatures and how SDO static object types are 
 initialized.  In the EClassImpl object, the eAllStructuralFeatures tracks 
 containment properties via a sub-list.  This sub-list is created ONLY one 
 time.  eAllStructuralFeatures is created the first time, when it is first 
 requested.  For static SDO-based applications, this first time is somewhat 
 random depending on the property types being created.  During static SDO init 
 there are two key functions of note; the createMetaData() method and the 
 intializeMetaData() method.  The createMetaData() method is called first, and 
 all DO properties have an 'empty' properties object created and attached to 
 the DO type.  Then, the initializeMetaData() method is called.  This method 
 'configures' each of the blank property objects.  The problem is that the 
 eAllStructuralFeatures containment list is constructed early in the 
 initializeMetaData() method, before all the properties have been initialized. 
  So, not all containment properties are recognized and therefore placed into 
 the eAllStructuralFeatures containment list.  This then affects the behavior 
 of the DataObjectUtil.delete(DataObject), such that it doesn't properly pull 
 all the contained DOs.
 Attached is a zip file with source code and a test schema.  In the zip is the 
 test client and associated static code gen classes.  

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


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

[jira] Resolved: (TUSCANY-1302) Changesummary of datagraph does not log changes for dataobject contained by the rootObject

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1302.
-

   Resolution: Invalid
Fix Version/s: Java-M1

The problem is in the test program. It needs to make the accountProperty a 
containment reference:

accountProperty.set(containment, Boolean.TRUE);


 Changesummary of datagraph does not log changes for dataobject contained by 
 the rootObject
 --

 Key: TUSCANY-1302
 URL: https://issues.apache.org/jira/browse/TUSCANY-1302
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Steffen Glomb
 Fix For: Java-M1


 Changesummary on a datagraph, 
 begin logging, 
 changes on the rootObject are logged in the changesummary, but changes on 
 objects contained by the rootobject do not get logged.
 Here is the testcase for the bug:
   public void testDataGraphChangeInNestedObjects() throws IOException {
   
   HelperContext hc = SDOUtil.createHelperContext();
   TypeHelper types = hc.getTypeHelper();
   DataFactory factory = hc.getDataFactory();
   
   Type intType = types.getType(commonj.sdo, Int);
   Type stringType = types.getType(commonj.sdo, String);
   
   // create a new Type for Account
   DataObject accountType = factory.create(commonj.sdo, Type);
   accountType.set(uri, http://example.com/customer;);
   accountType.set(name, Account);
   // create an account number property
   DataObject custNumProperty = 
 accountType.createDataObject(property);
   custNumProperty.set(name, accountNum);
   custNumProperty.set(type, intType);
   types.define(accountType);
   
   // create a new Type for Customers
   DataObject customerType = factory.create(commonj.sdo, Type);
   customerType.set(uri, http://example.com/customer;);
   customerType.set(name, Customer);
   
   // create a first name property
   DataObject firstNameProperty =
   customerType.createDataObject(property);
   firstNameProperty.set(name, firstName);
   firstNameProperty.set(type, stringType);
   // create a account property
   DataObject accountProperty = 
 customerType.createDataObject(property);
   accountProperty.set(name, account);
   accountProperty.set(type, accountType);
   // now define the Customer type so that customers can be made
   types.define(customerType);
   
   Type customerTypeType = 
 types.getType(http://example.com/customer;, Customer);
   Type accountTypeType = types.getType(http://example.com/customer;, 
 Account);
   
   DataGraph datagraph = 
 org.apache.tuscany.sdo.api.SDOUtil.createDataGraph();
   
   DataObject account = factory.create(accountTypeType);
   account.setInt(accountNum, 2);
   
   DataObject customer1 = datagraph.createRootObject(customerTypeType);
   customer1.setString(firstName, Steffen);
   customer1.set(account, account);
   
   datagraph.getChangeSummary().beginLogging();
 
 DataObject loadedCustomer = datagraph.getRootObject();
 DataObject loadedAccount = (DataObject) loadedCustomer.get(account);
 loadedAccount.setInt(accountNum, 5);
 
 datagraph.getChangeSummary().endLogging();
 List changedDataObjects = 
 datagraph.getChangeSummary().getChangedDataObjects();
 
 assertEquals(1 Object is changed by the code, 1, 
 changedDataObjects.size());
 }

-- 
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-1305) Changesummary of datagraph using static interfaces.

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499631
 ] 

Frank Budinsky commented on TUSCANY-1305:
-

Hi Steffen,

What version of the SDO code are you using? I vaguely remember fixing a bug 
that sounded something like this a couple of weeks ago. If you try the latest 
code from HEAD, it may be fixed already.

If not, can you please attach a zip file containing the test program and the 
generated classes, to save us some time reproducing the problem.

Thanks,
Frank.

 Changesummary of datagraph using static interfaces.
 ---

 Key: TUSCANY-1305
 URL: https://issues.apache.org/jira/browse/TUSCANY-1305
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Steffen Glomb

 I cant get Changesummary on a datagraph working correctly with the following 
 contents: (hope this is a realy a bug this time)
 Schema, generated by the xsdhelper:
 xs:schema 
   xmlns:sdo=commonj.sdo xmlns:sdoJava=commonj.sdo/java
 xmlns:stn_1=http://example.com/customer;   
 xmlns:xs=http://www.w3.org/2001/XMLSchema; 
   attributeFormDefault=qualifiedelementFormDefault=qualified  
 targetNamespace=http://example.com/customer;
   xs:complexType abstract=false name=Account
   xs:sequence/
   xs:attribute default=0 name=accountNum type=xs:int/
   /xs:complexType
   xs:element name=account type=stn_1:Account/
   xs:complexType abstract=false name=Customer
   xs:sequence
   xs:element name=account type=stn_1:Account/
   /xs:sequence
   xs:attribute name=firstName type=xs:string/
   /xs:complexType
   xs:element name=customer type=stn_1:Customer/
 /xs:schema
 After generation of interfaces the following code fails to work as I would 
 expect, because the changesummary does not contain the changed dataobject in 
 the graph.
 
 import org.apache.tuscany.sdo.api.SDOUtil;
 import com.example.customer.Account;
 import com.example.customer.Customer;
 import com.example.customer.CustomerFactory;
 import commonj.sdo.DataGraph;
 import commonj.sdo.Type;
 import commonj.sdo.helper.HelperContext;
 import commonj.sdo.impl.HelperProvider;
 public class TestChangesummary extends TestCase {
   public void testChangeSummaryOnDatagraphWithContainmentStatic() throws 
 Exception {
   
   HelperContext hc = HelperProvider.getDefaultContext();
   CustomerFactory.INSTANCE.register(hc);  
   
   Type customerType = hc.getTypeHelper().getType(Customer.class); 
 
   DataGraph dataGraph = SDOUtil.createDataGraph();
   Customer customer = (Customer) 
 dataGraph.createRootObject(customerType);
   
   Account account = CustomerFactory.INSTANCE.createAccount();
   customer.setAccount(account);
   customer.setFirstName(John);
   customer.getAccount().setAccountNum(1234);
   
   ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
   SDOUtil.saveDataGraph(dataGraph, outputStream, null);
   DataGraph loadDataGraph = SDOUtil.loadDataGraph(new 
 ByteArrayInputStream(outputStream.toByteArray()), null);
   
   loadDataGraph.getChangeSummary().beginLogging();
   
   customer = (Customer) loadDataGraph.getRootObject();
   customer.getAccount().setAccountNum(987);   
   
   loadDataGraph.getChangeSummary().endLogging();
   
   List changedDataObjects = 
 loadDataGraph.getChangeSummary().getChangedDataObjects(); 
assertEquals(in fact 1 Object was changed in the code, 1, 
 changedDataObjects.size());
   }
 }

-- 
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-513) Implement support for dynamic subclasses of statically generated types

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497879
 ] 

Frank Budinsky commented on TUSCANY-513:


Hi Ron,

You're right that the getStaticType() method should look like the getType() 
method currently. There should be no generated override of getType(), there 
should just be a generated getStaticType() mehtod. In DataObjectBase, there 
will need to be an implementation of getType() that checks if there is a 
dynamic type associated with the instance and return it if so. If not, call 
getStaticType() and return it. This is the same pattern that EMF uses to 
implement the eClass() method by delegating to eStaticClass().

Frank.

 Implement support for dynamic subclasses of statically generated types
 --

 Key: TUSCANY-513
 URL: https://issues.apache.org/jira/browse/TUSCANY-513
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Reporter: Ron Gavlin
 Fix For: Java-SDO-Mx


 Implement support for dynamic subclasses of statically generated types. See 
 below exerpt from tuscany-user mailing list for details.
 Hi Ron,
 Looking at this, it looks like the problem is that you're trying to create 
 dynamic subclasses of statically generated types. The bad news is that 
 Tuscany doesn't currently support that. The good news is that it's not too 
 hard to add the support.
 The problem is that currently Tuscany only has these two primary 
 DataObject implementation classes:
 1. DataObjectImpl - is the base class used for statically generated types. 
 It is highly tuned for performance and footprint, so, unlike the base 
 class in SDO1 (actually EMF) it doesn't support dynamic extensions.
 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
 designed for pure dynamic types, not a mixture of static and dynamic.
 To support what you want, we will need another base class, say 
 ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
 but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
 is that there are only a few simple method overrides needed in this class. 
 Maybe you would like to try to prototype such a class yourself and hand 
 modify your generated classes to extend from it? If you did that and 
 tested it, you could submit a patch and we could then very quickly add a 
 generator option to use it (maybe even make it the default). If you'd like 
 to help with this, it would be very much appreciated!
 At any rate, you should probably open a JIRA feature request for this.
 Thanks,
 Frank
  Frank,
  
  I am working with a mixed static/dynamic model similar to the one 
  listed at the bottom of this post. The http://example.org/ord 
  namespace is statically registered and has code-generated classes. The 
  http://example.org/info/zipcode and http://example.org/info/street 
  namespaces are dynamically registered with no code-generated 
  classes. When I attempt to load the Sample Instance (chapter04.xml),
  I receive an UnsupportedOperationException thrown from 
  DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
  exception is an instance of InfoTypeImpl from the ord 
  namespace/ePackage. The EClass parameter is InfoType from the 
  zipcode namespace. This instance document loads fine using EMF/SDO
  1.0. Any suggestions I can try to work-around this problem?
  
  - Ron
  
  
  Sample Instance (chapter04.xml)
  ord:order xmlns:ord=http://example.org/ord;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://example.org/ord chapter04ord1.xsd
  ord:number123ABBCC123/ord:number
  ord:customer
  ord:namePat Walmsley/ord:name
  ord:number15465/ord:number
  info xsi:type=ns1:InfoType xmlns=
  xmlns:ns1=http://example.org/info/zipcode;
  zipcode21043/zipcode
  /info
  /ord:customer
  ord:customer
  ord:namePriscilla Walmsley/ord:name
  ord:number15466/ord:number
  info xsi:type=ns1:InfoType xmlns=
  xmlns:ns1=http://example.org/info/street;
  street341 Duckworth Way/street
  /info
  /ord:customer
  ord:items
  product
  number557/number
  nameShort-Sleeved Linen Blouse/name
  size system=US-DRESS10/size
  color value=blue/
  /product
  /ord:items
  /ord:order
  Schema Document 1 (chapter04ord1.xsd)
  xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;;
 targetNamespace=http://example.org/ord;;
 xmlns=http://example.org/ord;;
 xmlns:prod=http://example.org/prod;;
 elementFormDefault=qualified
  xsd:import namespace=http://example.org/prod;;
  schemaLocation=chapter04prod.xsd/
   xsd:simpleType name=OrderNumType
 xsd:restriction base=xsd:string/
   /xsd:simpleType
   xsd:complexType name=InfoType/
   xsd:complexType name=CustomerType
 xsd:sequence
 

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1293:
-

Hi Bryan,

Like I said before, I don't know much about OSGi, but my guess is something 
must be missing from in the MANIFEST.MF file (some kind of 
extension/extension_point information) that would make the impl bundle visible 
to the api bundle. This is just my guess anyway :-) 

Can you, or anyone with some OSGi expertise, please investigate and/or suggest 
a sollution, or better yet provide a patch?

Thanks,
Frank.

 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

 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 

[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496332
 ] 

Frank Budinsky commented on TUSCANY-513:


Hi Ron,

I think that maybe we should start without an option - i.e., just make 
DataObjectBase support extensibility. I would suggest adding a new subclass of 
DataObjectImpl, ExtensibleDataObjectImpl, and then change DataObjectBase to 
subclass from it (instead of DataObjectImpl). No generator option needed at 
this point.

If we decide that we later want the higher performance non extensible 
DataObject, we can add an option in the future.

Note: I think we have a problem with the noEMF pattern, related to 
extensibility: we generate an override of the getType() method in the generated 
classes. The generator template will need to be changed to generate a 
getStaticType() method, similar to EMF's eStaticClass() method,  to fix this 
problem. Otherwise, I don't see any complications with the noEMF pattern.

Frank.

 Implement support for dynamic subclasses of statically generated types
 --

 Key: TUSCANY-513
 URL: https://issues.apache.org/jira/browse/TUSCANY-513
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Reporter: Ron Gavlin
 Fix For: Java-SDO-Mx


 Implement support for dynamic subclasses of statically generated types. See 
 below exerpt from tuscany-user mailing list for details.
 Hi Ron,
 Looking at this, it looks like the problem is that you're trying to create 
 dynamic subclasses of statically generated types. The bad news is that 
 Tuscany doesn't currently support that. The good news is that it's not too 
 hard to add the support.
 The problem is that currently Tuscany only has these two primary 
 DataObject implementation classes:
 1. DataObjectImpl - is the base class used for statically generated types. 
 It is highly tuned for performance and footprint, so, unlike the base 
 class in SDO1 (actually EMF) it doesn't support dynamic extensions.
 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is 
 designed for pure dynamic types, not a mixture of static and dynamic.
 To support what you want, we will need another base class, say 
 ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, 
 but doesn't make the assumption that eStaticFeatureCount() is 0. My guess 
 is that there are only a few simple method overrides needed in this class. 
 Maybe you would like to try to prototype such a class yourself and hand 
 modify your generated classes to extend from it? If you did that and 
 tested it, you could submit a patch and we could then very quickly add a 
 generator option to use it (maybe even make it the default). If you'd like 
 to help with this, it would be very much appreciated!
 At any rate, you should probably open a JIRA feature request for this.
 Thanks,
 Frank
  Frank,
  
  I am working with a mixed static/dynamic model similar to the one 
  listed at the bottom of this post. The http://example.org/ord 
  namespace is statically registered and has code-generated classes. The 
  http://example.org/info/zipcode and http://example.org/info/street 
  namespaces are dynamically registered with no code-generated 
  classes. When I attempt to load the Sample Instance (chapter04.xml),
  I receive an UnsupportedOperationException thrown from 
  DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the 
  exception is an instance of InfoTypeImpl from the ord 
  namespace/ePackage. The EClass parameter is InfoType from the 
  zipcode namespace. This instance document loads fine using EMF/SDO
  1.0. Any suggestions I can try to work-around this problem?
  
  - Ron
  
  
  Sample Instance (chapter04.xml)
  ord:order xmlns:ord=http://example.org/ord;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://example.org/ord chapter04ord1.xsd
  ord:number123ABBCC123/ord:number
  ord:customer
  ord:namePat Walmsley/ord:name
  ord:number15465/ord:number
  info xsi:type=ns1:InfoType xmlns=
  xmlns:ns1=http://example.org/info/zipcode;
  zipcode21043/zipcode
  /info
  /ord:customer
  ord:customer
  ord:namePriscilla Walmsley/ord:name
  ord:number15466/ord:number
  info xsi:type=ns1:InfoType xmlns=
  xmlns:ns1=http://example.org/info/street;
  street341 Duckworth Way/street
  /info
  /ord:customer
  ord:items
  product
  number557/number
  nameShort-Sleeved Linen Blouse/name
  size system=US-DRESS10/size
  color value=blue/
  /product
  /ord:items
  /ord:order
  Schema Document 1 (chapter04ord1.xsd)
  xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;;
 targetNamespace=http://example.org/ord;;
 xmlns=http://example.org/ord;;
 xmlns:prod=http://example.org/prod;;
 

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

[Frank Budinsky (JIRA)]

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


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] Resolved: (TUSCANY-1254) Codegen on a type inheriting from a type in different namespace will result in mis-mapping the feature IDs

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1254.
-

Resolution: Fixed

Fixed in revision 536537. Thanks to Fuhwei for narrowing it down to such a 
simple test case.

 Codegen on a type inheriting from a type in different namespace will result 
 in mis-mapping the feature IDs
 --

 Key: TUSCANY-1254
 URL: https://issues.apache.org/jira/browse/TUSCANY-1254
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
 Environment: WinXP
Reporter: Fuhwei Lwo
 Attachments: open.xsd, open2.xsd, OpenTypeTest.java


 Based on my observation, there are two sets of feature ID were generated for 
 the Type - 1) ID numbering from EMF 2) ID numbering for SDO. This problem 
 occurs when the child type was codegened, its IDs for SDO were mapped to 
 those from EMF. So when you tried to get the property using dynamic API, 
 since the feature ID is wrong, unpredictable exception will occur. The 
 exception can be NPE or ClassCastException depending on the characteristic of 
 the wrong ID.

-- 
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-1251) Code generated from xsd:base64Binary types fail to compile

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494335
 ] 

Frank Budinsky commented on TUSCANY-1251:
-

This is a side effect of the recent fix for TUSCANY-1223. I'll try to fix it 
later today.

 Code generated from xsd:base64Binary types fail to compile
 --

 Key: TUSCANY-1251
 URL: https://issues.apache.org/jira/browse/TUSCANY-1251
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
 Environment: IBM JDK 1.4.2
Reporter: Chris Mildebrandt
Priority: Blocker

 I've compiled the latest version of the Java SDO code on the evening of 5/6. 
 When I use that to generate the code from this schema: 
 http://www.w3.org/2000/09/xmldsig
 I get compilation problems in my source. The following methods and class 
 variables are unavailable in XMLTypeFactory:
 XMLTypeFactory.getBase64Binary()
 XMLTypeFactory.INSTANCE
 XMLTypeFactoryImpl.NAMESPACE_URI
 XMLTypeFactory.createBase64BinaryFromString(String)
 XMLTypeFactory.createBase64BinaryFromString(Object)

-- 
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-1251) Code generated from xsd:base64Binary types fail to compile

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1251.
-

Resolution: Fixed

Fixed in revision 536309.

 Code generated from xsd:base64Binary types fail to compile
 --

 Key: TUSCANY-1251
 URL: https://issues.apache.org/jira/browse/TUSCANY-1251
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
 Environment: IBM JDK 1.4.2
Reporter: Chris Mildebrandt
Priority: Blocker

 I've compiled the latest version of the Java SDO code on the evening of 5/6. 
 When I use that to generate the code from this schema: 
 http://www.w3.org/2000/09/xmldsig
 I get compilation problems in my source. The following methods and class 
 variables are unavailable in XMLTypeFactory:
 XMLTypeFactory.getBase64Binary()
 XMLTypeFactory.INSTANCE
 XMLTypeFactoryImpl.NAMESPACE_URI
 XMLTypeFactory.createBase64BinaryFromString(String)
 XMLTypeFactory.createBase64BinaryFromString(Object)

-- 
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-1197) Sequence composition

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1197.
-

Resolution: Fixed

Committed revision 536331.

 Sequence composition
 

 Key: TUSCANY-1197
 URL: https://issues.apache.org/jira/browse/TUSCANY-1197
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Yang ZHONG
 Fix For: Java-SDO-Mx

 Attachments: patch.1197, Sequences.java, SequencesTestCase.java


 DataObject#getSequence() provides one single Sequence for users to access 
 properties.
 However, a DataObject can have more than one non-derived Sequences.
 The attached prototype enables DataObject#getSequence() to return a Sequence 
 composition aggregating multiple non-derived Sequences.

-- 
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-1250) Static SDO generator generates an erroneous factory class, when inheritance and different Java packages are used

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1250.
-

Resolution: Fixed

Thanks to Daniel for the suggested fix. It looks good and I committed it in 
revision 536345.

 Static SDO generator generates an erroneous factory class, when inheritance 
 and different Java packages are used
 

 Key: TUSCANY-1250
 URL: https://issues.apache.org/jira/browse/TUSCANY-1250
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SCA-M2
 Environment: WinXP (tested with Java-SDO-M2 and Java-SDO-M3-RC3)
Reporter: Daniel Peter
 Fix For: Java-SDO-beta1


 The static SDO generator generates an erroneous factory class, when 
 inheritance and different Java packages are used. 
 The initializeMetaData() method in my generated FactoryImpl class has this 
 piece of code: 
   ... 
   // Obtain other dependent packages 
   SdtFactoryImpl theSdtPackageImpl_1 = 
 
 (SdtFactoryImpl)FactoryBase.getStaticFactory(SdtFactoryImpl.NAMESPACE_URI); 
   ... 
   // Add supertypes to types 
   addSuperType(myClassType, mySuperClassType); 
   ... 
 But the variable mySuperClassType cannot be resolved at this point, because 
 it is defined in a different package. 
 The code probably should look like this: 
   addSuperType(myClassType, theSdtPackageImpl_1.getMySuperClass()); 
 I noticed this bug when using M3-RC3, where the -noEmf option is always 
 turned on. 
 The factory/package code is correctly generated with M2, if the -noEmf option 
 is NOT specified, but the same error occurs when the -noEmf option is 
 specified with M2.

-- 
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-1223) XSD base64Binary type mapping to wrong SDO type

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1223.
-

Resolution: Fixed

Fixed in revision 535315.

I found a much simpler way to do this: set the underlying EType for 
base64Binary to be the EMF Base64Binary type and then override 
AttributeImpl.getType().


 XSD base64Binary type mapping to wrong SDO type
 ---

 Key: TUSCANY-1223
 URL: https://issues.apache.org/jira/browse/TUSCANY-1223
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Andy Grove
Priority: Minor
 Attachments: 1223.patch


 The XSD base64Binary type should map to the SDO type commonj.sdo#Bytes but 
 Tuscany is mapping it to commonj.sdo#Base64Bytes which is not mentioned in 
 the SDO specification.
 This is demonstrated in the CTS in 
 XSDComplexTypeTest.testTC297ComplexTypeContainingElementsOfAllTypes

-- 
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-1212) SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1212.
-

Resolution: Fixed

Committed revision 535331.

 SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()
 ---

 Key: TUSCANY-1212
 URL: https://issues.apache.org/jira/browse/TUSCANY-1212
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M2
Reporter: Frank Budinsky
 Fix For: Java-SDO-beta1




-- 
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-1214) SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result)

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1214.
-

Resolution: Fixed

Committed revision 535343.

 SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result)
 --

 Key: TUSCANY-1214
 URL: https://issues.apache.org/jira/browse/TUSCANY-1214
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky
 Attachments: 1214.patch




-- 
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-993) Problems with sdoModelExtended.xsd

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-993.


Resolution: Fixed

Committed revision 535350.

 Problems with sdoModelExtended.xsd
 --

 Key: TUSCANY-993
 URL: https://issues.apache.org/jira/browse/TUSCANY-993
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Frank Budinsky
Priority: Minor
 Fix For: Java-SDO-Mx


 The new schema sdoModelExtended.xsd has some problems:
 1. It includes some xmlns and xsi:schemaLocation values that aren't needed
 2. The include of sdoModel.xsd is an absolute file name, which doesn't 
 resolve (need a clean way to handle schemaLocatiions for the built-in XSDs)
 The regen instructions in the JavaDoc of SDOFactoryImpl needs to be changed 
 to say that sdoModelExtended.xsd must now be used - not just sdoMdodel.xsd.

-- 
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-1213) SDO 2.1 feature: DataHelper.convert()

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1213.
-

Resolution: Fixed

Committed revision 532839.

 SDO 2.1 feature: DataHelper.convert()
 -

 Key: TUSCANY-1213
 URL: https://issues.apache.org/jira/browse/TUSCANY-1213
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky



-- 
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-1221) Incorrect containment value when creating property from XSD

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490950
 ] 

Frank Budinsky commented on TUSCANY-1221:
-

I don't understand this. The red element  is not Complex Type. It is a Simple 
Type (xs:string) so containment is false, as expected.


 Incorrect containment value when creating property from XSD
 ---

 Key: TUSCANY-1221
 URL: https://issues.apache.org/jira/browse/TUSCANY-1221
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Andy Grove

 When creating an SDO type from the following XSD complexType, Tuscany is 
 creating the property red with containment = false instead of containment = 
 true. I have checked the specification and this contradicts the rules on page 
 90 of the SDO for Java 2.1.0 specification (see the table with the title XML 
 Elements with Complex Type). This is highlighted by the CTS test 
 XSDChoiceTest.testTC226_Choice.
   xs:complexType name=choiceType
   xs:choice
   xs:element name=red type=xs:string/
   xs:element name=green/
   xs:element name=blue/
   /xs:choice
   /xs:complexType

-- 
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-1222) Incorrect assertions in XSDChoiceTest

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1222.
-

Resolution: Fixed

Committed revision 531507.

 Incorrect assertions in XSDChoiceTest
 -

 Key: TUSCANY-1222
 URL: https://issues.apache.org/jira/browse/TUSCANY-1222
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Attachments: jira-1222-v2.patch, jira-1222.patch


 Two of the tests in XSDChoiceTest were incorrectly asserting that the types 
 were created with sequenced=false. After re-reading the specification, it is 
 clear that these particular types should have sequenced=true because the 
 choice definitions have maxOccurs  1. 
 I am attaching a patch that resolves this issue and also promotes 
 XSDChoiceTest to the AdoptedTestSuite. There is now a single test failure 
 when running against Tuscany and this is due to a bug in Tuscany (see 
 JIRA-1221).
 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] Resolved: (TUSCANY-1216) Sequence.add(index,value) is not working due to a type mismatch problem

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1216.
-

Resolution: Fixed

Fixed in revision 529735.

Note that the test program also has a bug. SDO Type Integer maps to 
java.math.BigInteger, not java.lang.Integer.


 Sequence.add(index,value) is not working due to a type mismatch problem
 ---

 Key: TUSCANY-1216
 URL: https://issues.apache.org/jira/browse/TUSCANY-1216
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
 Environment: n/a
Reporter: David T. Adcox
 Fix For: Java-SDO-M3


 The sample below demonstrates a problem found when adding properties into a 
 sequence object using the property index.  The issue seems to be related to 
 how the property index is acquired and how that index is subsequently used by 
 the BasicSequence object.  BasicSequence.add(int, Object) uses the EMF 
 eClass().getEstructuralFeature(int) method to retrieve the property, based on 
 the index.  The list of properties kept in this array, includes both 
 'explicit' properties defined by the schema or inline code, and 'implicit' 
 properties defined by the Tuscany SDO framework (in this case, I believe it 
 is actually the underlying EMF that is creating the implicit property).  Once 
 such implicit property is the 'multi' property, defined when a type is 
 identified as containing a sequence.  The core issue here is that the code 
 used to identify the index to use is based on an array of SDO properties, 
 which do not include the implicit properties.  So, the index is derived from 
 a different array than the one being used for updating, this is the root 
 cause of this problem.  A change to how the BasicSequence object obtains the 
 indexed property is probably the correct remedy for this issue.
 Sample code:
 public static void main(String[] args) 
 {
 String URI = http://example.com/test;;
 
 HelperContext scope = SDOUtil.createHelperContext();
 TypeHelper typeHelper = scope.getTypeHelper();
 Type integerType = typeHelper.getType(commonj.sdo, Integer);
 
 DataObject wrapperType = scope.getDataFactory().create(commonj.sdo, 
 Type);
 wrapperType.set(uri, URI );
 wrapperType.set(name, Wrapper);
 wrapperType.setBoolean(sequenced, true);
 
 // Create Property
 DataObject intProperty = wrapperType.createDataObject(property);
 intProperty.set(name, Value);
 intProperty.set(type, integerType);
 intProperty.setBoolean(many, true);
 
 // register the wrapper
 typeHelper.define(wrapperType);
 
 // get registered type
 Type testType = typeHelper.getType(URI,Wrapper);
 
 // Create an instance of the Wrapper Type
 DataObject testDO = scope.getDataFactory().create(testType);
 // Update the sequence using the index
 List properties = testType.getProperties();
 int index = properties.indexOf(testDO.getInstanceProperty(Value));
 Sequence sequence = testDO.getSequence();
 Integer v = new Integer(10);
 sequence.add(index,v);
 }

-- 
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-1211) SDO 2.1 feature: On-the-fly creation of open content properties

[Frank Budinsky (JIRA)]

SDO 2.1 feature: On-the-fly creation of open content properties
---

 Key: TUSCANY-1211
 URL: https://issues.apache.org/jira/browse/TUSCANY-1211
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky




-- 
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-1212) SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()

[Frank Budinsky (JIRA)]

SDO 2.1 feature: Property.isNullable() and Property.isOpenContent()
---

 Key: TUSCANY-1212
 URL: https://issues.apache.org/jira/browse/TUSCANY-1212
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky




-- 
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-1213) SDO 2.1 feature: DataHelper.convert()

[Frank Budinsky (JIRA)]

SDO 2.1 feature: DataHelper.convert()
-

 Key: TUSCANY-1213
 URL: https://issues.apache.org/jira/browse/TUSCANY-1213
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky




-- 
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-1214) SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result)

[Frank Budinsky (JIRA)]

SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result)
--

 Key: TUSCANY-1214
 URL: https://issues.apache.org/jira/browse/TUSCANY-1214
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky




-- 
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-1211) SDO 2.1 feature: On-the-fly creation of open content properties

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1211.
-

Resolution: Fixed

Committed revision 529307.

 SDO 2.1 feature: On-the-fly creation of open content properties
 ---

 Key: TUSCANY-1211
 URL: https://issues.apache.org/jira/browse/TUSCANY-1211
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Reporter: Frank Budinsky



-- 
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-1207) TCCL-specific EcoreBuilders must be used by default XSDHelper

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1207.
-

Resolution: Fixed

Fixed in revision 527494.


 TCCL-specific EcoreBuilders must be used by default XSDHelper
 -

 Key: TUSCANY-1207
 URL: https://issues.apache.org/jira/browse/TUSCANY-1207
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Frank Budinsky

 When TCCL-specific package registry delegation is used (e.g., in the default 
 HelperContext implemention), EcoreBuilder delegation is also required.

-- 
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-1205) An exception was thrown when reading a large Java object back to DataObject

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1205.
-

   Resolution: Fixed
Fix Version/s: Java-SDO-M3

Committed revision 527109.


 An exception was thrown when reading a large Java object back to DataObject
 ---

 Key: TUSCANY-1205
 URL: https://issues.apache.org/jira/browse/TUSCANY-1205
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Fuhwei Lwo
Priority: Critical
 Fix For: Java-SDO-M3

 Attachments: 1205.patch


 Here is the exception when readObject() was called.
 org.eclipse.emf.ecore.resource.Resource$IOWrappedException: The element type 
 employeeName must be terminated by the matching end-tag /employeeName.
   at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:285)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
   at 
 org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:465)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
   at 
 org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
   at 
 org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:217)
   at 
 org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:78)
   at 
 org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:72)
   at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readDataObject(HelperProviderImpl.java:221)
   at 
 org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readExternal(HelperProviderImpl.java:152)
   at 
 commonj.sdo.impl.ExternalizableDelegator.readExternal(ExternalizableDelegator.java:83)
   at 
 java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1774)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1324)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:362)
   at 
 org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase.testLargePayload(JavaSerializeDeserializeTestCase.java:110)
   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)
 Caused by: org.xml.sax.SAXParseException: The element type employeeName 
 must be terminated by the matching end-tag /employeeName.
   at 
 org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
 Source)
   at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
   at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
   at 
 org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at 

[jira] Commented: (TUSCANY-1197) Sequence composition

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486662
 ] 

Frank Budinsky commented on TUSCANY-1197:
-

Thanks Yang, I missed that. 

I found the getSequenceFeature() method hard to follow. I don't think it's 
quite right and will need some more work.


 Sequence composition
 

 Key: TUSCANY-1197
 URL: https://issues.apache.org/jira/browse/TUSCANY-1197
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Yang ZHONG
 Fix For: Java-SDO-Mx

 Attachments: patch.1197, Sequences.java, SequencesTestCase.java


 DataObject#getSequence() provides one single Sequence for users to access 
 properties.
 However, a DataObject can have more than one non-derived Sequences.
 The attached prototype enables DataObject#getSequence() to return a Sequence 
 composition aggregating multiple non-derived Sequences.

-- 
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-1144) Type Schema Location

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486356
 ] 

Frank Budinsky commented on TUSCANY-1144:
-

I'm not in favour of storing schemaLocation directly in SDO metaobjects. The 
SDO specification workgroup has an open issue for SDO 3 to provide support for 
More Granular XML Schema Generation. The solution to this problem should be 
consistent with the direction the spec takes.


 Type Schema Location
 

 Key: TUSCANY-1144
 URL: https://issues.apache.org/jira/browse/TUSCANY-1144
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Yang ZHONG
 Fix For: Java-SDO-Mx

 Attachments: 1144.patch


 SCA Java2WSDL has an option not to regenerate XSD if a static SDO comes from 
 XSD,
 therefore the originating XSD location info is required for a (static) SDO 
 Type.

-- 
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-1128) Support attribute and element with same name

[Frank Budinsky (JIRA)]

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

Frank Budinsky commented on TUSCANY-1128:
-

The attached patch doesn't provide the correct semantics if there are 
duplicates of the same kind (i.e., 2 elements with the same name). In that 
case, the spec says that the first one hides the second, but this 
implementation will return the last one. Actually, it looks like that's a bug 
in the current implementation (before this patch) as well.


 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-Mx
Reporter: Yang ZHONG
Priority: Minor
 Fix For: Java-SDO-Mx

 Attachments: 1128.patch, 1128.patch, 
 DifferAttrFromElementTestCase.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] Commented: (TUSCANY-1197) Sequence composition

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486389
 ] 

Frank Budinsky commented on TUSCANY-1197:
-

The attached class Sequences is a good start (a better name would be 
VirtualSequence), but has some problems. It needs to filter derived fetures, so 
they don't result in duplicates. Also if all properties are derived from a 
single featureMap (e.g., mixed), it can servie as the composed Sequence. The 
test case should not be accessing hidden properties (like choice, any, etc.), 
it shoud just confirm that the composed Sequence() contains the right 
properties in the right positions.

 Sequence composition
 

 Key: TUSCANY-1197
 URL: https://issues.apache.org/jira/browse/TUSCANY-1197
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Yang ZHONG
 Fix For: Java-SDO-Mx

 Attachments: patch.1197, Sequences.java, SequencesTestCase.java


 DataObject#getSequence() provides one single Sequence for users to access 
 properties.
 However, a DataObject can have more than one non-derived Sequences.
 The attached prototype enables DataObject#getSequence() to return a Sequence 
 composition aggregating multiple non-derived Sequences.

-- 
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-1189) Remove workarounds after switching to EMF 2.3

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1189.
-

Resolution: Fixed

We may never move to EMF 2.3, so keeping JIRAs like this open is not a good 
idea. The comment in the code is good enough.

 Remove workarounds after switching to EMF 2.3
 -

 Key: TUSCANY-1189
 URL: https://issues.apache.org/jira/browse/TUSCANY-1189
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Kelvin Goodson
Priority: Minor
 Fix For: Java-SDO-Mx


 A bucket defect for keeping handles on workarounds for EMF issues until we 
 take the proper fixes by switching to EMF 2.3
 Starting with the workaround fix for TUSCANY-1164 committed in revision 
 520824 (http://svn.apache.org/viewvc?view=revrevision=520824)

-- 
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-1109) TypeHelperImpl#getType(Class) queries wrong scope (EPackage.Registry.INSTANCE) and misses delegate scopes

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1109.
-

Resolution: Duplicate

I'm resolving this as a duplicate of TUSCANY-1110, since it will completely 
replace the current implementation of getType(). 

 TypeHelperImpl#getType(Class) queries wrong scope 
 (EPackage.Registry.INSTANCE) and misses delegate scopes
 -

 Key: TUSCANY-1109
 URL: https://issues.apache.org/jira/browse/TUSCANY-1109
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Yang ZHONG
 Fix For: Java-SDO-Mx


 TypeHelperImpl#getType(Class) queries wrong scope: EPackage.Registry.INSTANCE.
 And TypeHelperImpl#getType(Class) misses delegate scopes, because 
 getRegistry().values() doesn't include delegateRegistry.values().

-- 
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-1060) SDO Serialzation Failing in BigBank.

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1060.
-

Resolution: Invalid

Resolving because this is old, and doesn't appear to be identifying an actual 
SDO problem.

 SDO Serialzation Failing in BigBank.
 

 Key: TUSCANY-1060
 URL: https://issues.apache.org/jira/browse/TUSCANY-1060
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SCA-Future
Reporter: Rick Rineholt
 Fix For: Java-SDO-Mx


 BigBank is failing cause it's now using the PassByValueInterceptor which is 
 detects com.bigbank.account.impl.CustomerProfileDataImpl SDO generated class 
 is Java Serializable;  however during serialization it receives a 
 ClassCastException.  To reproduce run BigBank see readme.html in directory 
 java\sampleapps\bigbank
 Stack trace :
 Daemon Thread [http-8090-Processor25] (Suspended) 
   
 org.apache.tuscany.databinding.sdo.SDODataBinding(org.apache.tuscany.spi.databinding.extension.DataBindingExtension).copy(java.lang.Object)
  line: 149   
   
 org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.copy(java.lang.Object,
  org.apache.tuscany.spi.databinding.DataBinding) line: 106
   
 org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 71
   
 org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 41
   
 org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler(org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler).invoke(org.apache.tuscany.spi.wire.OutboundInvocationChain,
  org.apache.tuscany.spi.wire.TargetInvoker, java.lang.Object[], 
 java.lang.Object, java.util.LinkedListjava.lang.Object) line: 91  
   
 org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder(org.apache.axiom.om.impl.builder.StAXOMBuilder).init(javax.xml.stream.XMLStreamReader)
  line: 95   
   
 org.apache.axiom.om.impl.builder.StAXOMBuilder.init(java.io.InputStream) 
 line: 86 
   
 org.apache.tuscany.databinding.axiom.AxiomDataBinding.copy(java.lang.Object) 
 line: 62   
   
 org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.copy(java.lang.Object,
  org.apache.tuscany.spi.databinding.DataBinding) line: 106
   
 org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 71
   
 org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 41
   
 org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 71 
   
 org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler(org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler).invoke(org.apache.tuscany.spi.wire.OutboundInvocationChain,
  org.apache.tuscany.spi.wire.TargetInvoker, java.lang.Object[], 
 java.lang.Object, java.util.LinkedListjava.lang.Object) line: 91  
   
 org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(java.lang.Object,
  java.lang.reflect.Method, java.lang.Object[]) line: 166  
   $Proxy43.getCustomerProfile(java.lang.String) line: not available   
   
 bigbank.webclient.services.account.AccountServiceComponentImpl.getCustomerProfile(java.lang.String)
  line: 73
   sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, 
 java.lang.Object, java.lang.Object[]) line: not available [native method] 

   sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, 
 java.lang.Object[]) line: 39  
   sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, 
 java.lang.Object[]) line: 25  
   java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) 
 line: 585
   
 org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(java.lang.Object,
  short) line: 93
   
 org.apache.tuscany.core.implementation.java.JavaTargetInvoker(org.apache.tuscany.spi.extension.TargetInvokerExtension).invoke(org.apache.tuscany.spi.wire.Message)
  line: 67 
   
 org.apache.tuscany.core.wire.InvokerInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 44
   
 org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 68
   
 org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(org.apache.tuscany.spi.wire.Message)
  line: 41
   
 

[jira] Resolved: (TUSCANY-1023) WSDL -- Java mapping: Define and document what WSDL styles are supported and not supported

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1023.
-

Resolution: Invalid

Resturning this because there's nothing in the SDO project that provides 
specific support or restrictions for certain WSDL patterns. It supports XML 
Schema according to the SDO spec.

 WSDL -- Java mapping: Define and document what WSDL styles are supported 
 and not supported
 

 Key: TUSCANY-1023
 URL: https://issues.apache.org/jira/browse/TUSCANY-1023
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SCA-Future
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Mx


 It would be beneficial for the SCA developers to have documentation about 
 what combination of WSDL styles (e.g. doc-lit-wrapped and doc-lit-nonwrapped) 
 and Java interface styles (e.g. nonwrapper and wrapper) Tuscany is supporting 
 and not supporting.  Depending what combination is supported, it would impact 
 the tooling requirements tracked by TUSCANY-1019.

-- 
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-1024) Define and document data binding for each WSDL -- Java mapping

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-1024.
-

Resolution: Invalid

SDO project doesn't have a WSDL to Java mapping. It supports XSD to Java as 
documented in the SDO specification.

 Define and document data binding for each WSDL -- Java mapping
 

 Key: TUSCANY-1024
 URL: https://issues.apache.org/jira/browse/TUSCANY-1024
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Implementation
Affects Versions: Java-SCA-Future
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Mx


 Each WSDL -- Java mapping combination may support different data bindings - 
 simple XSD types, complex types in static style, and complex types in dynamic 
 style.  Some combinations may require different Java annotations.

-- 
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-1021) CopyHelper and EqualityHelper should handle ChangeSummary

[Frank Budinsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486421
 ] 

Frank Budinsky commented on TUSCANY-1021:
-

Leveraging the serialization/deserialization work in TUSCANY-153 has proven to 
be not viable. Therefore, we are going to need to implement in-memory copy and 
equality functsions for ChangeSummaries.

 CopyHelper and EqualityHelper should handle ChangeSummary
 -

 Key: TUSCANY-1021
 URL: https://issues.apache.org/jira/browse/TUSCANY-1021
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Yang ZHONG
 Assigned To: Kelvin Goodson
 Fix For: Java-SDO-Mx


 ChangeSummary can now be any DataObject attribute, and it's stale through EMF 
 API.
 Currently, CopyHelper and EqualityHelper heavily depend on EMF. That needs to 
 be patched to support ChangeSummary at any DataObject depth and its 
 summarization if necessary.
 FYI, 859 has introduced an effort to make ChangeSummary never stale through 
 *SDO* API.

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


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

[jira] Resolved: (TUSCANY-889) Add a new codegen option to generate static SDO APIs using StAX parser

[Frank Budinsky (JIRA)]

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

Frank Budinsky resolved TUSCANY-889.


Resolution: Won't Fix

Resolving since it's old and totally unclear what it's asking for.

 Add a new codegen option to generate static SDO APIs using StAX parser
 --

 Key: TUSCANY-889
 URL: https://issues.apache.org/jira/browse/TUSCANY-889
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SDO Tools
Affects Versions: Java-SDO-Mx
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-Mx




-- 
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-1200) Default HelperContext should provide automatic ClassLoader-specific scoping

[Frank Budinsky (JIRA)]

Default HelperContext should provide automatic ClassLoader-specific scoping
---

 Key: TUSCANY-1200
 URL: https://issues.apache.org/jira/browse/TUSCANY-1200
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Frank Budinsky
 Fix For: Java-SDO-M3


The default HelperContext, returned by HelperProvider.getDefaultContext(), 
should provide automatic ClassLoader-specific scoping. It should be implemented 
using the delegating EPackage.Registry.INSTANCE, instead of using a single 
local registry as is used with HelperContexts created with 
SDOUtil.createHelperContext().

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