[jira] Resolved: (TUSCANY-2110) ChangeSummary's getOldContainer() and getOldContainmentProperty() methods are not working correctly.
[ https://issues.apache.org/jira/browse/TUSCANY-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-2110. - Resolution: Invalid If you set the containment of parentProp2 to true the test passes > ChangeSummary's getOldContainer() and getOldContainmentProperty() methods are > not working correctly. > - > > Key: TUSCANY-2110 > URL: https://issues.apache.org/jira/browse/TUSCANY-2110 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: n/a >Reporter: David T. Adcox > Fix For: Java-SDO-Next > > Attachments: Test2110.java > > > I am unable to get ChangeSummary to return a value using the > getOldContainer() method or the getOldContainmentProperty() method. I think > there may be an issue when using a three-tier model. What I mean by this is > I have created a top level 'root' type that contains two unique 'parent' > types. Each of the parent types has a unique property that can contain a > child type. When I set the child to be contained by parent2, then start > logging on the ChangeSummary, then set the containment to parent1, I am not > able to retrieve the old parent container nor the old containment property. > I will attach a test case. -- 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] Issue Comment Edited: (TUSCANY-1725) XSD2JavaGenerator has a problem with associations navigable from both sides
[ https://issues.apache.org/jira/browse/TUSCANY-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12529388#action_12529388 ] kgoodson edited comment on TUSCANY-1725 at 3/18/08 5:03 AM: -- Thanks for this. I'd like to add the schema as the basis of a test, as a first step. We need you to grant license to the ASF to use it. Would you be able to attach a file with the schema please and tick the "Grant License" button please? (for ref: here's the thread that led to this jira -- http://www.mail-archive.com/[EMAIL PROTECTED]/msg01818.html ) was (Author: kgoodson): Thanks for this. I'd like to add the schema as the basis of a test, as a first step. We need you to grant license to the ASF to use it. Would you be able to attach a file with the schema please and tick the "Grant License" button please? (for ref: here's the thread that led to this jira -- http://www.mail-archive.com/[EMAIL PROTECTED]/msg01818.html) > XSD2JavaGenerator has a problem with associations navigable from both sides > --- > > Key: TUSCANY-1725 > URL: https://issues.apache.org/jira/browse/TUSCANY-1725 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 > Environment: Linux >Reporter: Miro Kandic > Fix For: Java-SDO-Next > > Attachments: xmlSchema.xsd > > > XSD2JavaGenerator does not work in the case of any association type > (association, composition) that is navigable from both sides. > I have intentionally, just to test generator, made Customer-SoH association > in the next schema navigable from both sides and generated code cannot be > compiled. > Frank, after initial analyses, confirmed that saying "Bidirectional > references are broken in Tuscany. They seem > to have been broken when we switched over to the new (noEMF) codegen > patterns." > Next is complete XSD built automatically from the UML model. > > > targetNamespace="http://www.cisco.com/odns/soa"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:sdo="commonj.sdo" xmlns:sdoxml="commonj.sdo/xml" > xmlns:impl="http://www.cisco.com/odns/soa"; > elementFormDefault="qualified"> > > > > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > sdoxml:propertyType="impl:SoH" > sdoxml:oppositeProperty="customer" minOccurs="0" > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > sdoxml:propertyType="impl:Customer" > sdoxml:oppositeProperty="orders" minOccurs="1" maxOccurs="1" > /> > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > sdoxml:propertyType="impl:Product" > sdoxml:oppositeProperty="soLs" minOccurs="1" maxOccurs="1" /> > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2098) Bidirectional properties are not working in XSD2JavaGenerator
[ https://issues.apache.org/jira/browse/TUSCANY-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-2098. - Resolution: Duplicate Surinder, you have uncovered a known problem. It was reported in https://issues.apache.org/jira/browse/TUSCANY-1725 Unfortunately we haven't been able to tackle it yet.However, I think if you wanted to try to get your schema running using dynamic SDO you would need to add some xsd:ID properties to Writer and Book. I put up an example of this kind of thing the other day, see http://www.mail-archive.com/[EMAIL PROTECTED]/msg02626.html Is there a chance you might be able to help us fix TUSCANY-1725? > Bidirectional properties are not working in XSD2JavaGenerator > - > > Key: TUSCANY-2098 > URL: https://issues.apache.org/jira/browse/TUSCANY-2098 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 >Reporter: Surinder Pal Singh Bindra >Priority: Blocker > Attachments: library.xsd > > > Bidirectional relations seems to be broken in XSD2JavaGenerator. It generates > code which can't be compiled. Here is the sample schema. > > http://www.generated.example.sdo.org/Library"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:sdoXML="commonj.sdo/xml" > xmlns:sdoJava="commonj.sdo/java" xmlns:sdo="commonj.sdo" > xmlns:lib="http://www.generated.example.sdo.org/Library"; > sdoJava:package="org.sdo.example.generated.library"> > > > > > > >sdoXML:oppositeProperty="books" sdoXML:propertyType="lib:Writer"/> > > > > > >maxOccurs="unbounded" sdoXML:oppositeProperty="author" > sdoXML:propertyType="lib:Book"/> > > > > > >minOccurs="0" maxOccurs="unbounded" /> >maxOccurs="unbounded" /> > > > > > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source
[
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-2080.
-
Resolution: Later
The implementation is behaving as per the 2.1 spec.
There is a spec issue open for the 2.1.1 spec (I keen I had seen this recently
but didn't make the proper connection)
The spec issue is -- "No Target Namespace results in no global properties?"
The situation for the 2.1 spec is that if you register an XML schema that does
not specify a target namespace then no
global elements will be registered with XSDHelper as no open content properties
would have been registered with TypeHelper due to the namespace URI being null.
> XML Helper Load method fails to return SDO generated class when using the
> method that takes a java.xml.transform.Source
> ---
>
> Key: TUSCANY-2080
> URL: https://issues.apache.org/jira/browse/TUSCANY-2080
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Windows XP
>Reporter: Jason Dixon
> Attachments: tuscany_example.zip
>
>
> When trying to go from a Document object to a Generated Object using the XML
> helper only AnyTypeDataObject is being returned. The other SDO operations
> function propperly. For exampl if I marshall the Document to String and then
> use the XML load method that takes a string, the correct generated sdo
> instance is return. Please see the source code example below.
> Thanks in advance!
> try {
> DocumentBuilderFactory factory =
> DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
>
> DocumentBuilder builder = factory.newDocumentBuilder();
> System.out.println("Builder is namespace aware " +
> builder.isNamespaceAware());
>
> Document dom = builder.parse(new File("results.xml"));
>
>
> //Create a scope and register
> HelperContext scope =
> HelperProvider.getDefaultContext();
> DomainFactoryImpl.INSTANCE.register(scope);
> //Now load from dom to object
> DOMSource source = new DOMSource(dom);
> XMLDocument xml = scope.getXMLHelper().load(source,
> null, null);
> Object clazz = xml.getRootObject();
> System.out.println(clazz);
>
> } catch (FactoryConfigurationError e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParserConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (SAXException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
--
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] Issue Comment Edited: (TUSCANY-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source
[ https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578823#action_12578823 ] kgoodson edited comment on TUSCANY-2080 at 3/14/08 8:59 AM: -- This issue seems to be restricted to the conditions of creating the graph via a DOMSource AND the prefix "" is bound to the namespace. Any other prefix seems fine. If you parse a document direct from an inputstream that has the "" prefix, then all is well, but going via a DOMSource brings out the problem. So far I have trapped this down to the EMF XMLHelperImpl$NamespaceSupport having no table entry for the "" prefix. Here's the stack (I have to do other things for a while, if you are in a position to follow up at all that would be great) XMLHelperImpl$NamespaceSupport.getURI(String) line: 1419 SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).getURI(String) line: 1253 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFeature(EObject, String, String, boolean) line: 2707 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).handleFeature(String, String) line: 1541 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createDocumentRoot(String, String, String, EFactory, boolean) line: 1237 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String, String, boolean) line: 1165 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String, String) line: 1247 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String, String, String) line: 883 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, String, String) line: 866 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, String, String, Attributes) line: 627 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String, String, Attributes) line: 405 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 566 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 538 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, Node, Map) line: 409 SDOXMLResourceImpl(XMLResourceImpl).doLoad(Node, Map) line: 606 SDOXMLResourceImpl(XMLResourceImpl).load(Node, Map) line: 570 XMLDocumentImpl.load(Node, Object) line: 249 XMLHelperImpl.load(Source, String, Object) line: 113 SimpleStaticTestCase.testSimpleStaticViaDomSource2() line: 114 was (Author: kgoodson): This issue seems to be restricted to the conditions of creating the graph via a DOMSource AND the prefix "" is bound to the namespace. Any other prefix seems fine. If you parse a document direct from an inputstream that has the "" prefix, then all is well, but going via a DOMSource brings out the problem. So far I have trapped this down to the EMF XMLHelperImpl$NamespaceSupport having no table entry for the "" prefix. Here's the stack (I have to do other things for a while, if you can follow up at all that would be great) XMLHelperImpl$NamespaceSupport.getURI(String) line: 1419 SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).getURI(String) line: 1253 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFeature(EObject, String, String, boolean) line: 2707 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).handleFeature(String, String) line: 1541 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createDocumentRoot(String, String, String, EFactory, boolean) line: 1237 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String, String, boolean) line: 1165 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String, String) line: 1247 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String, String, String) line: 883 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, String, String) line: 866 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, String, String, Attributes) line: 627 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String, String, Attributes) line: 405 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 566 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node, XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 538 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, Node, Map) line: 409 SDOXMLResourceImpl(XMLResourceImpl).doLoad(Node, Map) line: 606 SDOXMLResourceImpl(XMLResourceImpl).load(Node, Map) line: 570 XMLDocumentImpl.load(Node,
[jira] Commented: (TUSCANY-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source
[
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578823#action_12578823
]
Kelvin Goodson commented on TUSCANY-2080:
-
This issue seems to be restricted to the conditions of creating the graph via a
DOMSource AND the prefix "" is bound to the namespace. Any other prefix seems
fine. If you parse a document direct from an inputstream that has the ""
prefix, then all is well, but going via a DOMSource brings out the problem. So
far I have trapped this down to the EMF XMLHelperImpl$NamespaceSupport having
no table entry for the "" prefix. Here's the stack
(I have to do other things for a while, if you can follow up at all that would
be great)
XMLHelperImpl$NamespaceSupport.getURI(String) line: 1419
SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).getURI(String) line: 1253
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFeature(EObject,
String, String, boolean) line: 2707
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).handleFeature(String,
String) line: 1541
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createDocumentRoot(String,
String, String, EFactory, boolean) line: 1237
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String,
String, boolean) line: 1165
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String,
String) line: 1247
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String,
String, String) line: 883
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String,
String, String) line: 866
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String,
String, String, Attributes) line: 627
SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String,
String, Attributes) line: 405
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node,
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 566
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).traverse(Node,
XMLLoadImpl$AttributesProxy, DefaultHandler, LexicalHandler) line: 538
SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, Node, Map)
line: 409
SDOXMLResourceImpl(XMLResourceImpl).doLoad(Node, Map) line: 606
SDOXMLResourceImpl(XMLResourceImpl).load(Node, Map) line: 570
XMLDocumentImpl.load(Node, Object) line: 249
XMLHelperImpl.load(Source, String, Object) line: 113
SimpleStaticTestCase.testSimpleStaticViaDomSource2() line: 114
> XML Helper Load method fails to return SDO generated class when using the
> method that takes a java.xml.transform.Source
> ---
>
> Key: TUSCANY-2080
> URL: https://issues.apache.org/jira/browse/TUSCANY-2080
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Windows XP
>Reporter: Jason Dixon
> Attachments: tuscany_example.zip
>
>
> When trying to go from a Document object to a Generated Object using the XML
> helper only AnyTypeDataObject is being returned. The other SDO operations
> function propperly. For exampl if I marshall the Document to String and then
> use the XML load method that takes a string, the correct generated sdo
> instance is return. Please see the source code example below.
> Thanks in advance!
> try {
> DocumentBuilderFactory factory =
> DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
>
> DocumentBuilder builder = factory.newDocumentBuilder();
> System.out.println("Builder is namespace aware " +
> builder.isNamespaceAware());
>
> Document dom = builder.parse(new File("results.xml"));
>
>
> //Create a scope and register
> HelperContext scope =
> HelperProvider.getDefaultContext();
> DomainFactoryImpl.INSTANCE.register(scope);
> //Now load from dom to object
> DOMSource source = new DOMSource(dom);
> XMLDocument xml = scope.getXMLHelper().load(source,
> null, null);
> Object clazz = xml.getRootObject();
> System.out.println(clazz);
>
> } catch (FactoryConfigurationError e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParserConfigurationException e) {
> // T
[jira] Commented: (TUSCANY-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source
[
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578674#action_12578674
]
Kelvin Goodson commented on TUSCANY-2080:
-
I knocked up a quick test for this which does not fail, see the commit on the
commits tab of this jira
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
> XML Helper Load method fails to return SDO generated class when using the
> method that takes a java.xml.transform.Source
> ---
>
> Key: TUSCANY-2080
> URL: https://issues.apache.org/jira/browse/TUSCANY-2080
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Windows XP
>Reporter: Jason Dixon
>
> When trying to go from a Document object to a Generated Object using the XML
> helper only AnyTypeDataObject is being returned. The other SDO operations
> function propperly. For exampl if I marshall the Document to String and then
> use the XML load method that takes a string, the correct generated sdo
> instance is return. Please see the source code example below.
> Thanks in advance!
> try {
> DocumentBuilderFactory factory =
> DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
>
> DocumentBuilder builder = factory.newDocumentBuilder();
> System.out.println("Builder is namespace aware " +
> builder.isNamespaceAware());
>
> Document dom = builder.parse(new File("results.xml"));
>
>
> //Create a scope and register
> HelperContext scope =
> HelperProvider.getDefaultContext();
> DomainFactoryImpl.INSTANCE.register(scope);
> //Now load from dom to object
> DOMSource source = new DOMSource(dom);
> XMLDocument xml = scope.getXMLHelper().load(source,
> null, null);
> Object clazz = xml.getRootObject();
> System.out.println(clazz);
>
> } catch (FactoryConfigurationError e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParserConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (SAXException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
--
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-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source
[
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578666#action_12578666
]
Kelvin Goodson commented on TUSCANY-2080:
-
I just re-read your report, and see that I had misunderstood a detail,
apologies. So if you go via string, the correct class is generated for the
root object. This does sound more like a bug. We need to create a test case,
so if you can post your schema and results.xml file that would be great.
> XML Helper Load method fails to return SDO generated class when using the
> method that takes a java.xml.transform.Source
> ---
>
> Key: TUSCANY-2080
> URL: https://issues.apache.org/jira/browse/TUSCANY-2080
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Windows XP
>Reporter: Jason Dixon
>
> When trying to go from a Document object to a Generated Object using the XML
> helper only AnyTypeDataObject is being returned. The other SDO operations
> function propperly. For exampl if I marshall the Document to String and then
> use the XML load method that takes a string, the correct generated sdo
> instance is return. Please see the source code example below.
> Thanks in advance!
> try {
> DocumentBuilderFactory factory =
> DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
>
> DocumentBuilder builder = factory.newDocumentBuilder();
> System.out.println("Builder is namespace aware " +
> builder.isNamespaceAware());
>
> Document dom = builder.parse(new File("results.xml"));
>
>
> //Create a scope and register
> HelperContext scope =
> HelperProvider.getDefaultContext();
> DomainFactoryImpl.INSTANCE.register(scope);
> //Now load from dom to object
> DOMSource source = new DOMSource(dom);
> XMLDocument xml = scope.getXMLHelper().load(source,
> null, null);
> Object clazz = xml.getRootObject();
> System.out.println(clazz);
>
> } catch (FactoryConfigurationError e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParserConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (SAXException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
--
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-2080) XML Helper Load method fails to return SDO generated class when using the method that takes a java.xml.transform.Source
[
https://issues.apache.org/jira/browse/TUSCANY-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578643#action_12578643
]
Kelvin Goodson commented on TUSCANY-2080:
-
This symptom is seen when there is a mismatch between the input XML and the
registered metadata; usually because the metadata isn't registered. Here you
have registered the metadata, so we need to see the XML that is being
delivered by the DOMSource, and the metadata that is being used to generate
the static classes. In particular the namespace URI and root element name of
the input document must match a global element in the defining schema, or the
type of the root element must be defined by an xsi:type attribute. Please can
you post the input doc and schema, or create a simulation if you are not able
to post those?
I suspect this is not a bug in Tuscany. It may be better to continue this
discussion on the tuscany-user mailing list if you didn't mind, with a link to
the JIRA, then the user community will find it easier to benefit from this
discussion.
> XML Helper Load method fails to return SDO generated class when using the
> method that takes a java.xml.transform.Source
> ---
>
> Key: TUSCANY-2080
> URL: https://issues.apache.org/jira/browse/TUSCANY-2080
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Windows XP
>Reporter: Jason Dixon
>
> When trying to go from a Document object to a Generated Object using the XML
> helper only AnyTypeDataObject is being returned. The other SDO operations
> function propperly. For exampl if I marshall the Document to String and then
> use the XML load method that takes a string, the correct generated sdo
> instance is return. Please see the source code example below.
> Thanks in advance!
> try {
> DocumentBuilderFactory factory =
> DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
>
> DocumentBuilder builder = factory.newDocumentBuilder();
> System.out.println("Builder is namespace aware " +
> builder.isNamespaceAware());
>
> Document dom = builder.parse(new File("results.xml"));
>
>
> //Create a scope and register
> HelperContext scope =
> HelperProvider.getDefaultContext();
> DomainFactoryImpl.INSTANCE.register(scope);
> //Now load from dom to object
> DOMSource source = new DOMSource(dom);
> XMLDocument xml = scope.getXMLHelper().load(source,
> null, null);
> Object clazz = xml.getRootObject();
> System.out.println(clazz);
>
> } catch (FactoryConfigurationError e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (ParserConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (SAXException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
--
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-2058) The method XSDHelper.isXSD(Type) is returning invalid information
[ https://issues.apache.org/jira/browse/TUSCANY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576145#action_12576145 ] Kelvin Goodson commented on TUSCANY-2058: - Having consulted, it seems that the intention is that only the xsd helper belonging to the scope in which the type was defined should be able to provide information on XSD metadata, so we need to check that the supplied instance of the Type is known to the "this" xsdHelper before examining the annotations we keep on the Type impl class. > The method XSDHelper.isXSD(Type) is returning invalid information > - > > Key: TUSCANY-2058 > URL: https://issues.apache.org/jira/browse/TUSCANY-2058 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: n/a >Reporter: David T. Adcox > Fix For: Java-SDO-Next > > Attachments: Test2058.java > > > Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the > supplied Type object has been defined in the Scope from which the XSDHelper > was constructed. In turn, I expect that 'false' will be returned, for a Type > object NOT defined in the Scope. In some testing I have performed, I'm > seeing that 'true' is always returned, even if the Type is defined outside > the Scope being questioned. I will attach a sample. -- 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-2065) An ECMAScript version of SDO
[ https://issues.apache.org/jira/browse/TUSCANY-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-2065: Component/s: Java SDO Implementation > An ECMAScript version of SDO > > > Key: TUSCANY-2065 > URL: https://issues.apache.org/jira/browse/TUSCANY-2065 > Project: Tuscany > Issue Type: Wish > Components: Java SDO Implementation >Reporter: Kelvin Goodson > -- 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-2065) An ECMAScript version of SDO
An ECMAScript version of SDO Key: TUSCANY-2065 URL: https://issues.apache.org/jira/browse/TUSCANY-2065 Project: Tuscany Issue Type: Wish Reporter: Kelvin Goodson -- 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-2062) WSDL2Java code generation fails on WSDL with multiple namespace imports
[ https://issues.apache.org/jira/browse/TUSCANY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-2062: Component/s: (was: Java SDO Tools) Java SCA Tools > WSDL2Java code generation fails on WSDL with multiple namespace imports > --- > > Key: TUSCANY-2062 > URL: https://issues.apache.org/jira/browse/TUSCANY-2062 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-SCA-1.0.1 > Environment: Runtime Deployment is Solaris/Websphere 6.1 however this > is a code generation bug >Reporter: David Woolley >Assignee: Raymond Feng > Attachments: AdminServiceV2.wsdl, AuthenticationServiceV2.wsdl, > ServiceV2Common.xsd, TUSCANY-2062.zip > > > As per summary. WSDLs and associated schemas will be attached. -- 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-2058) The method XSDHelper.isXSD(Type) is returning invalid information
[ https://issues.apache.org/jira/browse/TUSCANY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575016#action_12575016 ] Kelvin Goodson commented on TUSCANY-2058: - This makes me wonder whether the spec has been a bit loose in its wording here and missed an opportunity. We keep our annotations that carry this extra metadata on the Type instance itself, so every xsdHelper would have access to the infomation. I think it's worth opening this up as a spec issue. the actual contents of the Spec do not completely preclude the behaviour we are seeing ... "IsXSD() can be used to tell if the XSDHelper has information about a Type." -- and, for the duration of the isXSD(method), it does, by virtue of the supplied argument. It's the JavaDoc that's the main issue. It says ... Indicates if this helper contains XSD information for the specified type. Which again is very loose, and probably wrong, since a set of helpers congregate around a scope for Types, so an xsdHelper would have access to types that had been defined by itself, and by the TypeHelper belonging to that scope. Hence the fact that is has information about that type is not the discriminator that determines the return value. I would suggest the behaviour we are seeing is the logical behaviour. > The method XSDHelper.isXSD(Type) is returning invalid information > - > > Key: TUSCANY-2058 > URL: https://issues.apache.org/jira/browse/TUSCANY-2058 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: n/a >Reporter: David T. Adcox > Fix For: Java-SDO-Next > > Attachments: Test2058.java > > > Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the > supplied Type object has been defined in the Scope from which the XSDHelper > was constructed. In turn, I expect that 'false' will be returned, for a Type > object NOT defined in the Scope. In some testing I have performed, I'm > seeing that 'true' is always returned, even if the Type is defined outside > the Scope being questioned. I will attach a sample. -- 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-2031) Error encountered when trying to use dynamic Data APIs and SDO code-generated APIs at the same time
[ https://issues.apache.org/jira/browse/TUSCANY-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575008#action_12575008 ] Kelvin Goodson commented on TUSCANY-2031: - Hello Joseph. I'm sorry that I didn't spot this one before. I need to see a bit more of your code. I don't have the beta1 source to hand at the moment to check in detail, but the first thing that seems clear is that any occurrence of AnyTypeImpl indicates that the Type system for the document that is being read is not registered. You'll need to have registered your type system in some way. It's not clear whether you want to use the dynamic API on instances of DataObject, or to use the dynamic API on instances of your generated classes. Either is possible. In the first case you will need to use the schema that you used for generating the static classes, and provide it as an InputStream to helperContext.getTypeHelper().define(...) and in the second case you would need to do something like MyGenFactory.INSTANCE.register(helperContext). This makes the Types available so that when you do helperContext.getXMLHelper().load(...) the load operation can look up the Types referenced in the XML document's elements, and create instances of the appropriate classes. I suspect this is user error. So I am going to close this JIRA as such. If you are still having troubles please mail the tuscany-user mailing list where we'll be able to help you out. > Error encountered when trying to use dynamic Data APIs and SDO code-generated > APIs at the same time > --- > > Key: TUSCANY-2031 > URL: https://issues.apache.org/jira/browse/TUSCANY-2031 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-beta1 > Environment: Windows XP, JDK 1.6 >Reporter: Joseph Nguyen > Fix For: Java-SDO-Next > > Original Estimate: 96h > Remaining Estimate: 96h > > Can use generated codes from SDO generator to create DataObject(s) and XML > data. Once the data has been created, error encountered when trying to use > dynamic Data APIs to read in to create DataObject(s). Below shows the > details of error. > Exception in thread "main" java.lang.ClassCastException: > org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl > at > org.apache.tuscany.sdo.helper.XMLDocumentImpl.getRootObject(XMLDocumentImpl.java:320) > at tbd.TBD.getRootObjectFromXMLDoc(TBD.java:73) > at tbd.TBD.main(TBD.java:497) -- 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-2031) Error encountered when trying to use dynamic Data APIs and SDO code-generated APIs at the same time
[ https://issues.apache.org/jira/browse/TUSCANY-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-2031. - Resolution: Invalid Suspect user error as per comment above. > Error encountered when trying to use dynamic Data APIs and SDO code-generated > APIs at the same time > --- > > Key: TUSCANY-2031 > URL: https://issues.apache.org/jira/browse/TUSCANY-2031 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-beta1 > Environment: Windows XP, JDK 1.6 >Reporter: Joseph Nguyen > Fix For: Java-SDO-Next > > Original Estimate: 96h > Remaining Estimate: 96h > > Can use generated codes from SDO generator to create DataObject(s) and XML > data. Once the data has been created, error encountered when trying to use > dynamic Data APIs to read in to create DataObject(s). Below shows the > details of error. > Exception in thread "main" java.lang.ClassCastException: > org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl > at > org.apache.tuscany.sdo.helper.XMLDocumentImpl.getRootObject(XMLDocumentImpl.java:320) > at tbd.TBD.getRootObjectFromXMLDoc(TBD.java:73) > at tbd.TBD.main(TBD.java:497) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1272) CrudWithChangeHistory test case fails as it's not finding the deleted object in the changeSummary
[ https://issues.apache.org/jira/browse/TUSCANY-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1272: Component/s: (was: Java DAS RDB) Java SDO Implementation Was assigned to wrong component > CrudWithChangeHistory test case fails as it's not finding the deleted object > in the changeSummary > - > > Key: TUSCANY-1272 > URL: https://issues.apache.org/jira/browse/TUSCANY-1272 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-DAS-Next >Reporter: Luciano Resende >Assignee: Luciano Resende > Fix For: Java-SDO-1.1 > > > Looks like DAS is not finding the deleted object in the changeSummary to > remove from the DB > testDeleteAndCreate(org.apache.tuscany.das.rdb.test.CrudWithChangeHistory) > Time elapsed: 0.266 sec <<< FAILURE! > junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertFalse(Assert.java:34) > at junit.framework.Assert.assertFalse(Assert.java:41) > at > org.apache.tuscany.das.rdb.test.CrudWithChangeHistory.testDeleteAndCreate(CrudWithChangeHistory.java:83) > at > org.apache.tuscany.das.rdb.test.CrudWithChangeHistory.testDeleteAndCreate(CrudWithChangeHistory.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-829) Investigate integration of RogueWave tests
[ https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-829: --- Fix Version/s: (was: Java-SDO-1.1) Java-SDO-CTS-Next > Investigate integration of RogueWave tests > -- > > Key: TUSCANY-829 > URL: https://issues.apache.org/jira/browse/TUSCANY-829 > Project: Tuscany > Issue Type: Test > Components: Java SDO Community Test Suite >Reporter: Kelvin Goodson > Fix For: Java-SDO-CTS-Next > > Attachments: jira-829.zip, sdo.zip, testdata.zip > > > Investigation of bringing RogueWave tests into the SDO Compliance Test Suite > environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1079) Possible error in XSDSerialization tests
[ https://issues.apache.org/jira/browse/TUSCANY-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1079: Fix Version/s: (was: Java-SDO-1.1) Java-SDO-CTS-Next > Possible error in XSDSerialization tests > > > Key: TUSCANY-1079 > URL: https://issues.apache.org/jira/browse/TUSCANY-1079 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-Next >Reporter: Andy Grove > Fix For: Java-SDO-CTS-Next > > > The current test cases are expecting 2 types to be created from the following > schema but does not contain assertions about what those types should look > like. I would expect this schema to create only one type > (http://www.example.com/simple#Quote) and one open content property > (stockQuote) of that type. What other type should be created? > Thanks, > Andy. >targetNamespace="http://www.example.com/simple"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:simple="http://www.example.com/simple";> > > > > > > > > > > > > >maxOccurs="unbounded"/> > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1063) Improve diagnostics running XSD2JavaGenerator against bad schema
[ https://issues.apache.org/jira/browse/TUSCANY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1063. - Resolution: Fixed Added print stack trace for any Exception (note one mod for this JIRA was inadvertently committed under TUSCANY-1293) Also added error report for case where input file results in no metadata (not easy to catch case where some metadata is in error). > Improve diagnostics running XSD2JavaGenerator against bad schema > > > Key: TUSCANY-1063 > URL: https://issues.apache.org/jira/browse/TUSCANY-1063 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SCA-M2 >Reporter: Scott Kurz >Priority: Minor > Fix For: Java-SDO-Next > > > I gave an invalid XSD file to the XSD2JavaGenerator and had to use the > debugger to figure out the problem. > It might be nice to do a printStackTrace() on any exception before throwing > out of main(). > Also it might be good to print out simple error messages in the cases that: > a) the usage was correct but the specified file can't be read > b) the file can be read but there is no valid schema found > As a sample of the latter here is my invalid schema > http://helloworld"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" > targetNamespace="http://helloworld";> > > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568499#action_12568499
]
Kelvin Goodson commented on TUSCANY-1293:
-
The patch seems to have fixed the continuum build issues.
http://vmbuild.apache.org/continuum/buildResult.action?buildId=49832&projectId=37
Amita, please can you confirm you see the build as fixed.
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at c
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568126#action_12568126
]
Kelvin Goodson commented on TUSCANY-1293:
-
I have applied your 2nd patch, after seeing a clean build in my own
environment. I will now seek a continuum build
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commo
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568099#action_12568099
]
Kelvin Goodson commented on TUSCANY-1293:
-
So it would seem that the failure is due to 106 repetitions of the same error,
reported to stdout as ...
Running org.apache.tuscany.sdo.test.osgi.OSGiTestCase
Runs 189, Errors: 106
testBasicsDO(org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase):
org/xml/sax/ext/LexicalHandler
org/xml/sax/ext/LexicalHandler
testBasicsDG(org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase):
org/xml/sax/ext/LexicalHandler
org/xml/sax/ext/LexicalHandler
..
..
investigating
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568083#action_12568083
]
Kelvin Goodson commented on TUSCANY-1293:
-
Amita, I get clean build from a clean extraction. Looking at runSDOTests()
for your run there ought to be 106 outputs to system.out of TestFalluire
instances. Can you take a look at these, and attach to the JIRA please?
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at comm
[jira] Commented: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568064#action_12568064 ] Kelvin Goodson commented on TUSCANY-257: Thanks Amita, I took a scan of the patch file and it appears good. The only thing I spotted is that we need a new java_1_4 maven profile that does not include the new project. > recently added file Interface2JavaGenerator.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-257 > URL: https://issues.apache.org/jira/browse/TUSCANY-257 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools > Environment: all >Reporter: Paul Golick > Fix For: Java-SDO-Next > > Attachments: 257.patch, newFiles.jar, > patchInterface2JavaGenerator.txt, patchUpdated.txt > > > Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and > java.lang.reflect.Type that were added in Java 5 for generics. It appears > that the portion of Interface2JavaGenerator that uses ParameterizedType and > Type is not needed for Java 1.4 classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1293.
-
Resolution: Fixed
Thanks for the patch Rajini.
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
> at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)
> at commonj.sdo.help
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567667#action_12567667
]
Kelvin Goodson commented on TUSCANY-1293:
-
Rajini,
sorry to take so long to get to this, and thanks for the patch. I'm working
towards getting thsi in for the next release. I note a couple of occasions in
the tests where an exception is caught, and then either output is made to the
System.out, or the exception is ignored. Could you help me understand if in
either of these cases the symptom is truly benign please? If so i will add a
comment to the code. If not then I'll change to let the exception surface
through the test infrastructure.
First is on OSGITestCase ...
// Start all the installed bundles
for (int i = 0; i < bundles.size(); i++) {
Bundle bundle = (Bundle)bundles.get(i);
try {
bundle.start();
} catch (Exception e) {
e.printStackTrace();
System.out.println("Could not start bundle " +
bundle);
}
}
second is in ClassLoaderTestCase (I think I can see this is benign, but could
do with confirmation)
for (int i = 0; i < parentLoaders.length; i++) {
try {
return
parentLoaders[i].loadClass(className);
} catch (Exception e) {
}
}
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:89
[jira] Updated: (TUSCANY-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named "Con"
[ https://issues.apache.org/jira/browse/TUSCANY-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1688: I did a check for EMF bugs raised for this issue, but couldn't find one. Do you know if this issue has been addressed in EMF? > XSD2JavaGenerator throws IOException:Access is denied with complexType named > "Con" > -- > > Key: TUSCANY-1688 > URL: https://issues.apache.org/jira/browse/TUSCANY-1688 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-Next > Environment: Windows XP SP2 w/Sun JDK 1.4.2_11 >Reporter: Ron Gavlin > Fix For: Java-SDO-Next > > > I have an XML Schema that contains a complexType named "Con". The following > error output is displayed to stdout: > >> Generating Con > >> Generating Java interface test.Con > >> Generating /TargetProject/test/Con.java > >> Examining old /TargetProject/test/Con.java > org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is > denied > at > org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava > (AbstractGeneratorAdapter.java:1046) > at > org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface > (GenClassGeneratorAdapter.java:123) > at > org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel > (GenClassGeneratorAdapter.java:106) > at > org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate > (GenBaseGeneratorAdapter.java:214) > at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate > (AbstractGeneratorAdapter.java:275) > at org.eclipse.emf.codegen.ecore.generator.Generator.generate > (Generator.java:600) > at org.eclipse.emf.codegen.ecore.generator.Generator.generate > (Generator.java:512) > at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel > (JavaGenerator.java:515) > ... > It seems as if the type name 'Con' conflicts with the operating system's > console device named 'Con'. The code first checks to see if the file exists > to decide if a merge is required. The code seems to incorrectly find the > file/device named 'Con' and then tries to access it in error. I suspect this > is an Eclipse EMF problem. -- 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-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named "Descriptor"
[
https://issues.apache.org/jira/browse/TUSCANY-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1689:
I did a check for EMF bugs raised for this issue, but couldn't find one. Do
you know if this issue has been addressed in EMF?
> XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType
> named "Descriptor"
>
>
> Key: TUSCANY-1689
> URL: https://issues.apache.org/jira/browse/TUSCANY-1689
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Tools
> Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> I have a schema with a complexType named "Descriptor".
> The generated FactoryImpl.java class includes the following code which does
> not compile because the return type
> "org.eclipse.emf.ecore.EPackage.Descriptor" is not compatible with
> Factory.createDescriptor() with return type "myNamespace.Descriptor":
> public Descriptor createDescriptor()
> {
> DescriptorImpl descriptor = new DescriptorImpl();
> return descriptor;
> }
> I suspect this is an EMF bug but I am reporting it here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1831) Make SDOPackageRegistryDelegator pluggable
[ https://issues.apache.org/jira/browse/TUSCANY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567578#action_12567578 ] Kelvin Goodson commented on TUSCANY-1831: - I guess we could parallel the way that the default HelperProvider implementation is made pluggable in the SDO API project's HelperProvider class, where the default impl is looked up by PROPERTY_NAME. > Make SDOPackageRegistryDelegator pluggable > -- > > Key: TUSCANY-1831 > URL: https://issues.apache.org/jira/browse/TUSCANY-1831 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next >Reporter: Ron Gavlin > Fix For: Java-SDO-Next > > > The current SDOPackageRegistryDelegator implementation assumes that a > standard, hierarchical classloader structure is present in the "hosting > environment". BEA WebLogic, for example, uses an unusual "change aware" > classloading scheme which does not meet the expectations of the > SDOPackageRegistryDelegator. Prior to Tuscany SDO 1.0, I was able to > work-around this former EMF problem by setting the EMF JVM property > "org.eclipse.emf.ecore.EPackage.Registry.INSTANCE". In Tuscany SDO 1.0, this > setting is no longer relevant. I would like to be able to plugin my own > SDOPackageRegistryDelegator implementation that provides a > non-classloader-aware registry, knowing full well the limitations of of this > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-182) Investigate how to best represent 0..n relationships requiring a keyed access in models
[ https://issues.apache.org/jira/browse/TUSCANY-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-182: --- Component/s: Java SCA Assembly Model There's too much assumed context in this JIRA description for me to begin to have an idea of how to address this without some expansion of the topic. I'm adding the SCA Assembly model as an additional component to bring this back onto the SCA radar for some input. If this is not the right SCA component, please advise what it should be. > Investigate how to best represent 0..n relationships requiring a keyed access > in models > --- > > Key: TUSCANY-182 > URL: https://issues.apache.org/jira/browse/TUSCANY-182 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Assembly Model, Java SDO Implementation >Reporter: Jean-Sebastien Delfino >Assignee: Frank Budinsky > Fix For: Java-SDO-Next > > > Some of the 0..n relationships in the SCA assembly model should provide a > keyed access (e.g get a component by name in a composite). > We need to investigate the best pattern (which we may want to also implement > in our codegenerator) to provide this function: > - a list with a get(key) method > - a map (but the map should preserve the sequence of elements) > We'll have to balance ease of use for adding to and navigating the > relationship, ability to implement integrity constraints on the relationship, > relationship with best model implementation practices as well as the SDO > spectification, and footprint + performance. > We also need to investigate if there is a way to automatically derive the > introduction of this keyed access to a relationship from XSD metadata > (xsd:key for example). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1514) DataHelperImpl.toDate will report a NullPointerException
[ https://issues.apache.org/jira/browse/TUSCANY-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1514: Component/s: (was: Java DAS RDB) Java SDO Implementation This JIRA was in a hybrid state with a DAS component and a target release of SDO. So as there seems to be a fix already made to SDO I'm changing the component to SDO and will alert the DAS folks to this. > DataHelperImpl.toDate will report a NullPointerException > - > > Key: TUSCANY-1514 > URL: https://issues.apache.org/jira/browse/TUSCANY-1514 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-beta1 >Reporter: Leo Li > Fix For: Java-SDO-Next > > > Hi All , > when I read the data from a table , there is a Datetime field in the > table , if the datetime field'value is null , the SDO will produce a > NullPointException , Maybe this is a bug , and How to fixed it ? > > Exception content as follow : > > 12:02:21,015 [main] ERROR [DasService] > java.lang.NullPointerException > at > org.apache.tuscany.sdo.helper.DataHelperImpl.toDate(DataHelperImpl.java:48) > at > org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createDateFromString(Mode > lFactoryImpl.java:1931) > at > org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createFromString(ModelFac > toryImpl.java:224) > at > org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.createFromString(Fac > toryBase.java:270) > at > org.eclipse.emf.ecore.util.EcoreUtil.createFromString(EcoreUtil.java:2982) > at > org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getValue(FeatureChangeIm > pl.java:428) > at > org.apache.tuscany.sdo.impl.ChangeSummarySettingImpl.getValue(ChangeSummaryS > ettingImpl.java:89) > at > org.apache.tuscany.das.rdb.util.DataObjectUtil.restoreAttributeValues(DataOb > jectUtil.java:74) > at > org.apache.tuscany.das.rdb.util.DataObjectUtil.getRestoredCopy(DataObjectUti > l.java:41) > at > org.apache.tuscany.das.rdb.impl.DeleteOperation.(DeleteOperation.java: > 34) > at > org.apache.tuscany.das.rdb.impl.ChangeFactory.createDeleteOperation(ChangeFa > ctory.java:77) > at > org.apache.tuscany.das.rdb.impl.ChangeSummarizer.createChange(ChangeSummariz > er.java:103) > at > org.apache.tuscany.das.rdb.impl.ChangeSummarizer.loadChanges(ChangeSummarize > r.java:80) > at > org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute(ApplyChanges > CommandImpl.java:64) > at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges(DASImpl.java:310) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1527.
-
Resolution: Fixed
I applied something very similar to what I had in my sandbox to the trunk, and
labelled the new interfaces "experimental" in order to indicate that there's a
chance we made need to tweak these in the future. Feedback on the use would be
great. The new code supports registration for notification at a DataObject
level, (which caters for open content properties etc). It would be pretty
simple to add a layer that gives a per Property registration interface that
simply filters the DataObject level notifications according to registered
interest in particular Properties. Take a look at the new NotificationTestCase
to see the new interface in action.
> 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: agfasdoui.tar.gz, com.zip
>
>
> We're developing 3-tier applications with a swing client, JBoss app server
> and a couple of databases in the back-end. On the client side we use sdo
> objects as model objects for our UI. As such, we need a mechanism for binding
> our objects to the UI controls such that changes in the objects are reflected
> in the UI and vice versa.
> At the moment, there is no real standard for data binding and many different
> implementations exist. As such, it would not be a good idea to build support
> for this directly into the sdo core. Ideally, the sdo core would allow
> implementations supporting data binding to be added as extensions [an
> extension as in jar, module, bundle, component, ...]. This is a request for
> supporting this in Tuscany SDO.
> -
> For our applications, we developed our own implementation of the sdo
> specification. This implementation is designed to support that kind of
> extensions. In the rest of this description, I'd like to show more details on
> our implementation to make this more clear and to serve as food for a
> possible discussion.
> Our sdo core module defines the abstract class AbstractPartialDataObject
> implementing DataObject. This class (together with its superclasses)
> implements the majority of the bevahiour of DataObject. This includes
> bi-directional property updates, type-safe properties, containment, ... It
> doesn't implement however the basic access to property values.
> Here's a code fragment.
> public abstract class AbstractPartialDataObject extends AbstractDataObject
> implements PartialDataObject {
> protected abstract Object basicGet(Property property);
>
> protected abstract void basicSet(Property property, Object value);
>
> public Object get(Property property) { ... }
> public void set(Property property, Object value) { ... }
>...
> }
> The sdo core module also provides a non-abstract class
> DataObjectImplementation that provides a simple implementation of this
> abstract behaviour where the property values are stored in an ArrayList.
> On top of that we defined an extension that deals with our UI requirements.
> Our UI is based on a proprietary UI framework. This framework has the
> following requirements:
> - single valued properties should be exposed as XObservables. An XObservable
> is a kind of ValueModel that provides access to a value (get/set) and also
> allows for registration of change listeners
> - multi valued properties should be exposed as ListModel instances. A
> ListModel is a proprietary class (a bit similar to the javax.swing.ListModel)
> that provides List functionality and also allows for change listeners
> - the data object itself should allow registration of attribute change
> listeners that are notified each time a property changes
> The extension implements these requirements by providing an appropriate
> subclass ObservableDataObject of AbstractPartialDataObject. The only other
> pieces of code needed in the extension is an appropriate implementation of
> DataFactory and a wrapper to deal with the differences between ListModel and
> List.
> Here's the class with the most important code snippets.
> public class ObservableDataObject extends CompositePartialDataObject
> implements {
> private XObservable[] properties;
>
> protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
> super(type);
> this.properties = new XObservable[type.getProperties().size()];
> for (int i = 0; i < properties.length; i++) {
> initializeProperty(type.getProperty(i));
[jira] Updated: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1293:
Patch Info: [Patch Available]
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
> Attachments: sdo-osgi.txt
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
> at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)
> at commonj.sdo.helper.XSDHelper.(XSDHel
[jira] Commented: (TUSCANY-1483) Static SDO generator: problem with elements named internal*
[ https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561997#action_12561997 ] Kelvin Goodson commented on TUSCANY-1483: - Your most recent patch ( 1483-withTestCaseInToolsTest.patch ) looks good by visual inspection. I haven't applied it to a test environment. Please feel free to commit it, and I'll check the commit log and run the tests after. Kelvin. > Static SDO generator: problem with elements named internal* > --- > > Key: TUSCANY-1483 > URL: https://issues.apache.org/jira/browse/TUSCANY-1483 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SDO-beta1 >Reporter: Daniel Peter >Priority: Minor > Fix For: Java-SDO-Next > > Attachments: 1483-withTestCase.patch, > 1483-withTestCaseInToolsTest.patch, 1483.patch, test1483.xsd > > > Hi, > I run into a problem with the static generated SDOs, when having a xsd with > the following two elements: > > > In the generated Impl class this leads twice to the same constant > INTERNAL_ABC. > The xsd elements might simply be renamed in order to avoid this clash, but > there might be situations where this is not possible. > The generator could use a different, less probable prefix (e.g. ___INTERNAL_). > Thanks, Daniel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1026) Java SDO Overview page on Web site has out of date information on samples
[ https://issues.apache.org/jira/browse/TUSCANY-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1026. - Resolution: Invalid The passage of time has made this JIRA invalid. Improvements will be made to the website structure, but this specific issue has disappeared. > Java SDO Overview page on Web site has out of date information on samples > - > > Key: TUSCANY-1026 > URL: https://issues.apache.org/jira/browse/TUSCANY-1026 > Project: Tuscany > Issue Type: Bug > Components: Website >Affects Versions: Java-SCA-M2 > Environment: all >Reporter: Simon Nash > Fix For: Java-SDO-Next > > > The file java_sdo_overview.xml has a section at the end entitiled > Test/Example programs. This section is out of date and needs to be updated > to reflect the current state of the SDO Java technology samples and the > Tuscany Java sample applications. The latter are described in > java-projects.html#Running the Samples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561304#action_12561304 ] Kelvin Goodson commented on TUSCANY-2009: - I'm surprised that the Ecore equality helper doesn't handle this. If my understanding is correct then Ecore could check the eAttribute.getEAttributeType().getInstanceClass().isArray() and then use Arrays.equals() for all arrays. Maybe there's a fix in a later version of EMF? This is our only array of primitives type, so we can special case it. We should check for type Bytes and use java.util.Arrays.equals(arg1,arg2) in our impl of haveEqualAttribute > Java SDO's EqualityHelper doesn't compare Bytes values correctly > > > Key: TUSCANY-2009 > URL: https://issues.apache.org/jira/browse/TUSCANY-2009 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: n/a >Reporter: David T. Adcox > Fix For: Java-SDO-Next > > Attachments: Test2009.java > > > Comparison of two Bytes values fails when it should succeed. The test for > equality passes through the EqualityHelperImpl.equal method. In that method, > the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, > EAttribute). For a simple type, it defers to java's '==' operator. So, two > different object arrays are being compared, not for their contents, but > rather if they are the same object. Attached is a test case which > demonstrates this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1483) Static SDO generator: problem with elements named internal*
[ https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559045#action_12559045 ] Kelvin Goodson commented on TUSCANY-1483: - Amita, thanks for looking at this. A while back we moved nearly all of our generated class test cases out of the tools project into the tools-test project. The reason for this is that generating classes in a build requires use of the plugin project, but the plugin project relies on the tools project, so we couldn't add a test scope dependency of the tools project on the plugin one, as there would then be circular dependencies. The outcome is that we have an extra project, with dependencies on both tools and plugin, where nearly all the testing goes on. The only test I left in the tools project itself was one that looked at package names, and for that I bypassed the plugin. The reason for this was that I could inspect runtime artifacts to ensure the behaviour, instead of having into inspect files or jars if I had done the test using the plugin. The upshot of this is that I think the behaviour in question for this JIRA is better tested in the tools-test project, where we can just add the schema to a stanza in the pom.xml, and exercise the generated classes in a small test program. > Static SDO generator: problem with elements named internal* > --- > > Key: TUSCANY-1483 > URL: https://issues.apache.org/jira/browse/TUSCANY-1483 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SDO-beta1 >Reporter: Daniel Peter >Priority: Minor > Fix For: Java-SDO-Next > > Attachments: 1483-withTestCase.patch, 1483.patch, test1483.xsd > > > Hi, > I run into a problem with the static generated SDOs, when having a xsd with > the following two elements: > > > In the generated Impl class this leads twice to the same constant > INTERNAL_ABC. > The xsd elements might simply be renamed in order to avoid this clash, but > there might be situations where this is not possible. > The generator could use a different, less probable prefix (e.g. ___INTERNAL_). > Thanks, Daniel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1935) Conversion of Bytes to/from String properties is not functioning correctly.
[
https://issues.apache.org/jira/browse/TUSCANY-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1935.
-
Resolution: Fixed
Patch applied, thanks David.
> Conversion of Bytes to/from String properties is not functioning correctly.
> ---
>
> Key: TUSCANY-1935
> URL: https://issues.apache.org/jira/browse/TUSCANY-1935
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: n/a
>Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: 1935.patch, 1935WithTestAugmentation.patch, Test1935.java
>
>
> According to the SDO for Java specification v. 2.1.0, conversion of string
> properties to byte arrays and from byte array properties to string is a
> supported conversion type. This is confirmed on page 138 of the spec.
> Additionally, sections 8.1.4 and 8.1.5 describe the behavior of such
> conversions. When an attempt is made to perform one of the following
> functions, though, a ClassCastException is thrown:
> dataObj.getBytes("stringPropName");
> dataObj.set("stringPropName", byteArrayValue);
> dataObj.set("byteArrayPropName", stringValue);
> The dataObj.getString("byteArrayPropName") method seems to be functioning
> correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549058 ] Kelvin Goodson commented on TUSCANY-1493: - I've just made some observations on the tuscany-user mailing list which should appear in the mailing list archives shortly, under the thread that contains http://www.mail-archive.com/[EMAIL PROTECTED]/msg02162.html > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: agfasdo.tar.gz, sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- 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-1545) Change default XML encoding to "UTF-8".
[ https://issues.apache.org/jira/browse/TUSCANY-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1545. - Resolution: Fixed Patch applied, thanks David. > 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 > > Attachments: 1545.patch > > > XMLHelper.save() uses "ASCII" encoding by default, but the spec says the > default encoding is "UTF-8". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544782 ] Kelvin Goodson commented on TUSCANY-1493: - Kris, I downloaded and manually installed the eclipse core and osgi dependencies at the appropriate level into my maven repository. Currently I'm getting more eclipse missing classes such as IExtension, which I guess is because the eclipse artifacts have transitive dependencies which would be known if maven had installed the artifacts itself. I'm guessing you have a repository in your settings.xml file for maven that can resolve these artifacts automatically. I can continue to dig out jars and manually install them into my repo until all requirements are resolved, but if you happen to be able to point me at a maven repo to do the job automatically that would be great, thanks. > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: agfasdo.tar.gz, sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544420
]
Kelvin Goodson commented on TUSCANY-1293:
-
There's an offer of help from Rajini to get this fixed that's current on the
tuscany-dev mailing list. I'm actively trying to help Rajini with her request
for info, but if anyone watching this JRIA wan't to pitch in, please do so.
See http://marc.info/?l=tuscany-dev&m=119563682818977&w=2
> SDO does not work with OSGi
> ---
>
> Key: TUSCANY-1293
> URL: https://issues.apache.org/jira/browse/TUSCANY-1293
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-beta1
> Environment: OS X Eclipse 3.3 M7
>Reporter: Bryan Hunt
>Priority: Blocker
> Fix For: Java-SDO-Next
>
>
> When I execute:
> XSDHelper.INSTANCE.define(schema, null);
> I end up with a NullPointerException. I've tracked down root cause ...
> The static initializer of the HelperProvider executes this code:
> provider = getInstance(HelperProvider.class.getClassLoader());
> which ends up calling:
> HelperProvider provider = loadImplementation(cl, implName);
> implName is null so
> if (implName == null) {
> implName = getImplementationName(cl);
> }
> ends up calling
> implName = getImplementationName(cl);
> which ends up calling:
> InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
> where SERVICE_RESORUCE_NAME =
> "META-INF/services/commonj.sdo.impl.HelperProvider"
> getResourceAsStream() return null because META-INF/services does not exist in
> the API bundle. It exists in the IMPL bundle and since you are using the
> class loader from the API bundle, it won't work.
> You can set
> -Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
> to get around the above problem, but as soon as
> return (HelperProvider) cl.loadClass(implName).newInstance();
> executes, you get a CalssNotFoundException. Again, this is because you are
> trying to load a class outside the bundle with the wrong class loader.
> tried modifying the API manifest by hand to add
> Eclipse-BuddyPolicy: dependent
> and
> Eclipse-BuddyPolicy: global
> Either of those buddy policies will get past the class loader problem
> (although I believe this is specific to eclipse and won't work for OSGi in
> general), but when HelperProvider is initializing, you get the following
> exception:
> java.lang.ExceptionInInitializerError
> at org.apache.tuscany.sdo.impl.AttributeImpl.(AttributeImpl.java:126)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
> at org.apache.tuscany.sdo.impl.ClassImpl.(ClassImpl.java:68)
> at
> org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
> at
> org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
> at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
> at org.apache.tuscany.sdo.SDOPackage.(SDOPackage.java:76)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
> at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41)
> at
> org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
> at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl.java:46)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
> at
> org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.(HelperProviderBase.java:78)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:31)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at c
[jira] Updated: (TUSCANY-1899) Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase char?
[ https://issues.apache.org/jira/browse/TUSCANY-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1899: Component/s: (was: Java SDO Tools) In the SDO tools we do this is in generation of XML schemas from existing Properties and Types. We do have a method "formGlobalElementName" which does this lower casing of the first letter when generating a global element in the schema. The behaviour is due to the paragraph in section 10 of the SDO spec which says ... The global element for the type: • lowercase(TYPE.NAME) is the type name with the first letter converted to lower case as defined type java.lang.Character.toLowerCase() > Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase > char? > -- > > Key: TUSCANY-1899 > URL: https://issues.apache.org/jira/browse/TUSCANY-1899 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1 >Reporter: Scott Kurz >Priority: Trivial > Fix For: Java-SCA-Next > > > The fact that: TuscanyWSDLTypesGenerator .createSchemaTypeForMethodPart > on line 267 calls: > globalElement.setName(formGlobalElementName(localPartName)); > which lowercases the first char in the parm passed to formGlobalElementName > ends up implying that method names must start in a lowercase char. > Because otherwise..the elem name > so constructed won't match the operation name... which will cause us to not > end up with doc-lit-wrapped WSDL. > Since everyone uses lowercase method names this in Java, I ranked this as > 'trivial'. > Still, I opened this anyway because I didn't see why we bother to lowercase > this string at all, and thought that if someone cancelled this JIRA, at least > I'd learn > there was a good reason for doing so. -- 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-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content
[ https://issues.apache.org/jira/browse/TUSCANY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1842. - Resolution: Fixed Applied patch, many thanks Ron. > 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 > > Attachments: 1842data.zip, tuscany-sdo.TUSCANY-1842.patch > > > In the test method, testComplexTypeWithSimpleContentExtensionChangeSummary() > listed below, a DataGraph is created with a dataObject whose property type > extends a complexType with simple integer content. After the dataObject is > deleted, an attempt is made to save and load the DataGraph. While the > DataGraph is being loaded, an unsuccessful attempt is made to convert a > zero-length string into a BigInteger. > Any suggestions on how to best fix this are most welcome. > Thanks, > - Ron > == > substitutionWithExtensionValues.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >value="English" /> >value="French" /> >value="Spanish" /> > > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues2.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV2"; > xmlns:sev2="http://www.example.com/substitutionEV2"; > xmlns:sev="http://www.example.com/substitutionEV";> > > http://www.example.com/substitutionEV"; > schemaLocation="substitutionWithExtensionValues.xsd" /> > > > > >maxOccurs="unbounded" > type="sev2:Results2Type" /> > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues1.xml > == > > http://www.example.com/substitutionEV2";> > > http://www.example.com/substitutionEV";> > > > > name1 > 1 >
[jira] Resolved: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored
[ https://issues.apache.org/jira/browse/TUSCANY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1832. - Resolution: Fixed Fixed by updates in TUSCANY-1812 > Complex type w/simple content restriction facets are ignored > > > Key: TUSCANY-1832 > URL: https://issues.apache.org/jira/browse/TUSCANY-1832 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next >Reporter: Ron Gavlin > Fix For: Java-SDO-Next > > > Namespace "http://www.example.com/substitutionEV"; includes two complex type > with simple content named CommentType and MyCommentType. MyCommentType > restricts CommentType with facet maxLength="40". This maxLength facet does > not appear to exist in the SDO metadata. The sample test case named > testComplexTypeWithSimpleContentExtension() is included below. > == > substitutionWithExtensionValues.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >value="English" /> >value="French" /> >value="Spanish" /> > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues2.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV2"; > xmlns:sev2="http://www.example.com/substitutionEV2"; > xmlns:sev="http://www.example.com/substitutionEV";> > > http://www.example.com/substitutionEV"; > schemaLocation="substitutionWithExtensionValues.xsd" /> > > > > >maxOccurs="unbounded" > type="sev2:Results2Type" /> > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues1.xml > == > > http://www.example.com/substitutionEV2";> > > http://www.example.com/substitutionEV";> > > > > name1 > value1 > > > > myName2 > myValue2 > > comment0 > > http://www.example.com/substitutionEV";> > > > > myNameB > myValueB > > commentA > > > commentZZ > > > == > SubstitutionWithExtensionValuesTestCase.java > == > /** > * > * Licensed to the Apache Software Foundation (ASF) under one > * or more contributor license agreements. See the NOTICE file > * distributed with this work for additional information > * regarding copyright ownership. The ASF licenses this file > * to you under the Apache License, Vers
[jira] Resolved: (TUSCANY-1830) SimpleType extension across mixed static/dynamic namespaces is broken
[
https://issues.apache.org/jira/browse/TUSCANY-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1830.
-
Resolution: Fixed
Fixed by updates in TUSCANY-1812
> SimpleType extension across mixed static/dynamic namespaces is broken
> -
>
> Key: TUSCANY-1830
> URL: https://issues.apache.org/jira/browse/TUSCANY-1830
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
>
> I have a statically registered namespace
> "http://www.example.com/substitutionEV"; with a simpleType named UuidType with
> a pattern facet. I also have a dynamically registered namespace
> "http://www.example.com/substitutionEV2"; with a simpleType named Uuid2Type
> which is a restriction of UuidType. When I invoke uuid2Type.getBaseTypes(),
> the parent UuidType is not returned. I have included a sample test below.
> ==
> substitutionWithExtensionValues.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV";
> xmlns:sev="http://www.example.com/substitutionEV";>
>
>
>
>
>substitutionGroup="sev:result"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>value="[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-f]{12}"/>
>
>
>
>
>
>
>
>
>
>
> ==
> substitutionWithExtensionValues2.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV2";
> xmlns:sev2="http://www.example.com/substitutionEV2";
> xmlns:sev="http://www.example.com/substitutionEV";>
>
> http://www.example.com/substitutionEV";
> schemaLocation="substitutionWithExtensionValues.xsd" />
>
>
>
>
>maxOccurs="unbounded"
> type="sev2:Results2Type" />
>
>
>
>
>
>
>
>
>
>
>
>
> ==
> substitutionWithExtensionValues1.xml
> ==
>
> http://www.example.com/substitutionEV2";>
> ----
> http://www.example.com/substitutionEV";>
> ----
>
>
> ----
> name1
> value1
>
>
>
> ----
> myName2
> myValue2
>
> comment0
>
> http://www.example.com/substitutionEV";>
> ----
>
>
> ----
> myNameB
> myValueB
>
> commentA
>
> commentZ
>
> ==
> SubstitutionWithExtensionValuesTestCase.java
> ==
> /**
> *
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> *http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing,
> * software distributed under the License is distributed on an
> * "AS IS" BASIS, 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.
> */
> package org.apache.tuscany.sdo.test;
> import java.io.IOException;
> import java.io.InputStream;
> import java.net.URL;
> import java.util.List;
> import junit.framework.TestCase;
> import org.eclipse.emf.common.util.Diagnostic;
> import org.eclipse.emf.ecore.EObject;
> import org.eclipse.emf.ecore.util.Diagnostician;
> import com.example.substitution.ev.SEVFactory;
> import com.example.substitution.ev.impl.SEVFactoryImpl;
> import commonj.sdo.DataObject
[jira] Resolved: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1812.
-
Resolution: Fixed
Patch Applied (many thanks Ron)
> XMLHelper.load() IOException using schema that has both a substitution group
> and an extension
> -
>
> Key: TUSCANY-1812
> URL: https://issues.apache.org/jira/browse/TUSCANY-1812
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>Priority: Critical
> Fix For: Java-SDO-Next
>
> Attachments: tuscany-sdo.TUSCANY-1812_1830_1832.patch
>
>
> Below, please find a failing Java test case and its XSD and XML test
> resources. Also, please find the stacktrace from the failing Java test case.
> It is interesting to note that this test does not fail when using dynamic
> SDO. Please comment if you have questions.
> - Ron
> package org.apache.tuscany.sdo.test;
> import java.io.IOException;
> import junit.framework.TestCase;
> import com.example.substitution.ev.SEVFactory;
> import commonj.sdo.DataObject;
> import commonj.sdo.helper.HelperContext;
> import commonj.sdo.helper.XMLHelper;
> import commonj.sdo.impl.HelperProvider;
> public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
>
> public void test() throws IOException {
> HelperContext hc = HelperProvider.getDefaultContext();
> SEVFactory.INSTANCE.register(hc);
>
> XMLHelper xmlHelper = hc.getXMLHelper();
> DataObject loadedObject =
> xmlHelper.load(getClass().getResourceAsStream("/substitutionWithExtensionValues1.xml")).getRootObject();
> }
> }
> substitutionWithExtensionValues.xsd
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV";
> xmlns:sv="http://www.example.com/substitutionEV";>
>
>
>
>
>substitutionGroup="sv:result"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> substitutionWithExtensionValues1.xml
>
> http://www.example.com/substitutionEV";>
>
> name1
> value1
>
>
> myName1
> myValue1
>
> comment1
>
> STACKTRACE
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
> 'myResult' not found. (http:///temp.xml, 7, 17)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
> at
> org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
> at
> org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
> at
> org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
> at
> org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
> at
> org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
> at
> org.apache.tuscany.sdo.test.SubstitutionWithExtensionValuesTestCase.test(SubstitutionWithExtensionValuesTestCase.java:40)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.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.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
> 'myResult' not found. (h
[jira] Updated: (TUSCANY-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content
[ https://issues.apache.org/jira/browse/TUSCANY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1842: Attachment: 1842data.zip Hi Ron, I'm having trouble getting the data files to validate before I run the test cases. I have made some updates, but need some assistance in fixing the final errors without changing the meaning of the test case. I have attached my updates to the files in 1842data.zip. In these files I have fixed up some of the validation errors by ... adding elementFormDefault="qualified" to both schema files changing the sev:results to sev2:results elements changing the values of the sev2:id and sev2:comment elements to match the appropriate facets but I am left with the errors below, and no matter how I try to vary the method of type derivation I cant seem to create a valid schema that conveys the meaning I think you want. Can you take a look please? src-ct.2.1: Complex Type Definition Representation Error for type 'Integer32Bit'. When is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'integer' satisfies none of these conditions. tuscany-sdo-tools-test/src/main/resources substitutionWithExtensionValues.xsd line 69 src-ct.2.1: Complex Type Definition Representation Error for type 'StringBasedCommentType'. When is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'string' satisfies none of these conditions.tuscany-sdo-tools-test/src/main/resources substitutionWithExtensionValues.xsd line 103 src-ct.2.1: Complex Type Definition Representation Error for type 'ValueType'. When is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'Integer32Bit' satisfies none of these conditions. tuscany-sdo-tools-test/src/main/resources substitutionWithExtensionValues.xsd line 63 > 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 > > Attachments: 1842data.zip, tuscany-sdo.TUSCANY-1842.patch > > > In the test method, testComplexTypeWithSimpleContentExtensionChangeSummary() > listed below, a DataGraph is created with a dataObject whose property type > extends a complexType with simple integer content. After the dataObject is > deleted, an attempt is made to save and load the DataGraph. While the > DataGraph is being loaded, an unsuccessful attempt is made to convert a > zero-length string into a BigInteger. > Any suggestions on how to best fix this are most welcome. > Thanks, > - Ron > == > substitutionWithExtensionValues.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[jira] Resolved: (TUSCANY-1811) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:float
[
https://issues.apache.org/jira/browse/TUSCANY-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1811.
-
Resolution: Fixed
Applied patch, thanks Ron.
> ClassCastException saving codegen-based DataGraph with ChangeSummary
> containing an xsd:float
>
>
> Key: TUSCANY-1811
> URL: https://issues.apache.org/jira/browse/TUSCANY-1811
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
>Reporter: Ron Gavlin
> Fix For: Java-SDO-Next
>
> Attachments: tuscany-sdo.TUSCANY-1811.patch
>
>
> This problem is similar to TUSCANY-1393 except the schema type in this case
> is an xsd:float instead of an xsd:int. The fix involves adding the following
> lines to DataObjectBase.java. If you would like me to submit a patch with a
> revised testcase, let me know.
> LINES TO BE ADDED to DataObjectBase.java:
> protected void notify(int changeKind, int property, float oldFloatValue,
> float newFloatValue)
> {
> eNotify(new ENotificationImpl(this, Notification.SET, property,
> oldFloatValue, newFloatValue));
> }
>
> protected void notify(int changeKind, int property, float oldFloatValue,
> float newFloatValue, boolean isSetChange)
> {
> eNotify(new ENotificationImpl(this, Notification.SET, property,
> oldFloatValue, newFloatValue, isSetChange));
> }
> END OF LINES TO BE ADDED
> - Ron
> P.S., below I have included the stacktrace for the problem.
> java.lang.ClassCastException: java.lang.Double
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertFloatToString(ModelFactoryImpl.java:2036)
> at
> org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertToString(ModelFactoryImpl.java:318)
> at
> org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.convertToString(FactoryBase.java:291)
> at
> org.eclipse.emf.ecore.util.EcoreUtil.convertToString(EcoreUtil.java:2994)
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getDataValue(FeatureChangeImpl.java:228)
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.eIsSet(FeatureChangeImpl.java:771)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:818)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1107)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:620)
> at
> org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$SaveImpl.traverse(DataGraphResourceFactoryImpl.java:382)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
> at
> org.apache.tuscany.sdo.helper.SDOHelperImpl.saveDataGraph(SDOHelperImpl.java:182)
> at org.apache.tuscany.sdo.api.SDOUtil.saveDataGraph(SDOUtil.java:158)
> at
> org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithIntAndFloat(ChangeSummaryGenTestCase.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.r
[jira] Commented: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539056
]
Kelvin Goodson commented on TUSCANY-1527:
-
OK, thanks, I'll take a peek ASAP and see how it fits with what's in my
sandbox already, and how we can advance that.
> 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: agfasdoui.tar.gz, com.zip
>
>
> We're developing 3-tier applications with a swing client, JBoss app server
> and a couple of databases in the back-end. On the client side we use sdo
> objects as model objects for our UI. As such, we need a mechanism for binding
> our objects to the UI controls such that changes in the objects are reflected
> in the UI and vice versa.
> At the moment, there is no real standard for data binding and many different
> implementations exist. As such, it would not be a good idea to build support
> for this directly into the sdo core. Ideally, the sdo core would allow
> implementations supporting data binding to be added as extensions [an
> extension as in jar, module, bundle, component, ...]. This is a request for
> supporting this in Tuscany SDO.
> -
> For our applications, we developed our own implementation of the sdo
> specification. This implementation is designed to support that kind of
> extensions. In the rest of this description, I'd like to show more details on
> our implementation to make this more clear and to serve as food for a
> possible discussion.
> Our sdo core module defines the abstract class AbstractPartialDataObject
> implementing DataObject. This class (together with its superclasses)
> implements the majority of the bevahiour of DataObject. This includes
> bi-directional property updates, type-safe properties, containment, ... It
> doesn't implement however the basic access to property values.
> Here's a code fragment.
> public abstract class AbstractPartialDataObject extends AbstractDataObject
> implements PartialDataObject {
> protected abstract Object basicGet(Property property);
>
> protected abstract void basicSet(Property property, Object value);
>
> public Object get(Property property) { ... }
> public void set(Property property, Object value) { ... }
>...
> }
> The sdo core module also provides a non-abstract class
> DataObjectImplementation that provides a simple implementation of this
> abstract behaviour where the property values are stored in an ArrayList.
> On top of that we defined an extension that deals with our UI requirements.
> Our UI is based on a proprietary UI framework. This framework has the
> following requirements:
> - single valued properties should be exposed as XObservables. An XObservable
> is a kind of ValueModel that provides access to a value (get/set) and also
> allows for registration of change listeners
> - multi valued properties should be exposed as ListModel instances. A
> ListModel is a proprietary class (a bit similar to the javax.swing.ListModel)
> that provides List functionality and also allows for change listeners
> - the data object itself should allow registration of attribute change
> listeners that are notified each time a property changes
> The extension implements these requirements by providing an appropriate
> subclass ObservableDataObject of AbstractPartialDataObject. The only other
> pieces of code needed in the extension is an appropriate implementation of
> DataFactory and a wrapper to deal with the differences between ListModel and
> List.
> Here's the class with the most important code snippets.
> public class ObservableDataObject extends CompositePartialDataObject
> implements {
> private XObservable[] properties;
>
> protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
> super(type);
> this.properties = new XObservable[type.getProperties().size()];
> for (int i = 0; i < properties.length; i++) {
> initializeProperty(type.getProperty(i));
> }
> }
> private XObservable initializeProperty(Property prop) {
> XObservable observable =
> XObservableFactory.create(prop.getType().getInstanceClass(), this);
> if (prop.isMany()) {
> observable.init(new DataObjectListModel(this, prop));
> }
> properties[prop.getIndex()] = observable;
> return observable;
> }
> public XObservable getObservable(commonj.sdo.Property property) {
> XObservable result = properties
[jira] Commented: (TUSCANY-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539055 ] Kelvin Goodson commented on TUSCANY-1493: - Kris, thanks for this. It's going to be a couple of days before I can get to looking at it, but I look forward to doing so. > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: agfasdo.tar.gz, sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- 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-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538718
]
Kelvin Goodson commented on TUSCANY-1527:
-
I just came across this link
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/common/notify/Notification.html
and recalled your enquiry.
> 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 XObservable initializeProperty(Property prop) {
> XObservable 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.Propert
[jira] Resolved: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1780. - Resolution: Fixed Resolved in 588261. > [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: > default="myCat"/> > > > > This generates the following line in the impl class: > protected static final Object CATEGORY_TYPE_DEFAULT_ = > ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), > "myCat"); > The class ModelPackageImpl doesn't exist. > I've tried this with the 1.0 version of SDO and a version I built today. > Let me know if you need any more information. Thanks, > -Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1868) Schema imports not working in multiple class-loader environment
[ https://issues.apache.org/jira/browse/TUSCANY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1868: Component/s: Java SDO Implementation > Schema imports not working in multiple class-loader environment > --- > > Key: TUSCANY-1868 > URL: https://issues.apache.org/jira/browse/TUSCANY-1868 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: n/a >Reporter: David T. Adcox > Fix For: Java-SDO-Next > > Attachments: Test1868.java > > > There is a problem with loading schemas that import an additional namespace > when in a multiple class-loader environment. The problem exists due to a > design flaw in how the EcoreBuilder and package registries interact under a > specific circumstance. That circumstance exists when the default helper > context is used to load a schema model using the XSDHelper.define() method in > two different, peer class-loaders. These peer class-loaders must share the > same parentage. >--- > | CL parent | >--- > /\ > / \ > /\ > / \ > --- --- > | CL1 || CL2 | > --- --- > In this scenario, the same EcoreBuilder is used on both passes of > XSDHelper.define(), because the EcoreBuilder is associated with the CL > Parent. A unique registry is created for CL1 and another for CL2. During > the processing for CL1, the target namespace and all imported namespaces are > properly parsed and the models stored in the associated registry, but during > the processing for CL2, because the same EcoreBuilder is used, only the > target namespace is processed. So, any imported models are missing from the > CL2 registry. > I've attached an example that will demonstrate this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1780: Attachment: SDOClass.java As a checkpoint in investigating this issue I'm attaching a sanitised version of SDOClass.java for debug purposes which is logically equivalent to the status quo. Here's where I've got to --- At line 530 of this file we create the static defaults of variables, be they single instance or list type. So the one call to stringBuffer.append(genFeature.getStaticDefaultValue()); is used to handle thing like protected static final String VALUE_DEFAULT_ = null; protected static final boolean DISPLAYABLE_DEFAULT_ = false; as well as the case in hand. The differential logic for creating the string is found in guarded code portions of GenDataTypeImpl#getStaticValue (as reached from GenFeatureImpl#getStaticDefaultValue()) and it is there that the "createFromString" code that is in error is generated. The problem as I see it at the moment is that all that logic is bound up in one single EMF method, containing some code that I want, and some that I don't. It's not clear to me at the moment whether I need to add guards into SDOClass which replicate the fairly detailed logic in the calling stack to avoid the call to getFeature.getStaticDefaultValue() in the circumstances when it produces the erroneous code (providing an alternative generation in those circumstances), or whether there is some better means of influencing the output. > [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: > default="myCat"/> > > > > This generates the following line in the impl class: > protected static final Object CATEGORY_TYPE_DEFAULT_ = > ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), > "myCat"); > The class ModelPackageImpl doesn't exist. > I've tried this with the 1.0 version of SDO and a version I built today. > Let me know if you need any more information. Thanks, > -Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-152) Java SDO generation from XML Schema needs schema validation.
[ https://issues.apache.org/jira/browse/TUSCANY-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-152: --- Component/s: (was: Java SDO Implementation) Java SDO Tools > Java SDO generation from XML Schema needs schema validation. > > > Key: TUSCANY-152 > URL: https://issues.apache.org/jira/browse/TUSCANY-152 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Tools > Environment: SVN HEAD java >Reporter: Rick Rineholt > Fix For: Java-SDO-Next > > > Using the generation through the WSDL tool it appears the XML schema can have > invalid schema and still the generator produces code. The particular case I > had was the an element that had this case >
[jira] Commented: (TUSCANY-1192) Preserve demand created global properties
[ https://issues.apache.org/jira/browse/TUSCANY-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536669 ] Kelvin Goodson commented on TUSCANY-1192: - Note, related to this issue is that http://www.xcalia.com/support/browse/SDO-263 recently established the principle that ... " ... if the last value of an existing open content property list is removed and then another value is added, the same instance property will reappear, ..." > Preserve demand created global properties > - > > Key: TUSCANY-1192 > URL: https://issues.apache.org/jira/browse/TUSCANY-1192 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Affects Versions: Java-SDO-beta1 >Reporter: Kelvin Goodson > Fix For: Java-SDO-Next > > > TUSCANY-917 addressed the issue of demand creating global properties when > needed for an xmlHelper.load operation, but the property is ephemeral and is > therefore not available for use after the load operation. This JIRA is opened > to alter behaviour such that the demand created property is available in the > applications metadata after the load operation. -- 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-1180) Unable to initialize read-only properties
[ https://issues.apache.org/jira/browse/TUSCANY-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536664 ] Kelvin Goodson commented on TUSCANY-1180: - Resolution of this issue is dependent on http://www.xcalia.com/support/browse/SDO-37, currently targeted at SDO 3. > Unable to initialize read-only properties > - > > Key: TUSCANY-1180 > URL: https://issues.apache.org/jira/browse/TUSCANY-1180 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next >Reporter: Stepan Ilchenko > Fix For: Java-SDO-Next > > > The problem is that we can't initialize read-only property in recently > created DataObject, when we fill it with data by own DAS. SDO API says, that > Exception should be raized in case of attempting to change that king of > property through API. That's why new method in SDO Implementation needs to be > created to provide property initialization. > Maybe 'isSet' parameter should be used to control initialization process of > the property. -- 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-1283) Better organization of the interfaces and classes in the SDO Java project
[ https://issues.apache.org/jira/browse/TUSCANY-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1283. - Resolution: Fixed The basis of the plan described above is in place. The split between emf and non-emf runtime was implemented by an additional project, rather than a division at the java package level. > 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-Next > > > 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] Commented: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created
[ https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536660 ] Kelvin Goodson commented on TUSCANY-1178: - TODO: given the discussion above, and the unresolved SDO spec JIRA targeteed for the SDO 3 spec, the assertions in the test case relating to the types mentioned above in the description should be removed. > DynamicTypesFromSchemaTestCase expecting *Object types to be created > > > Key: TUSCANY-1178 > URL: https://issues.apache.org/jira/browse/TUSCANY-1178 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-CTS-Next >Reporter: Andy Grove > Fix For: Java-SDO-CTS-Next > > > DynamicTypesFromSchemaTestCase expects the following types to be included in > the list returned by XSDHelper.define() but there are no types with these > names in the XSD (these types minus the "Object" suffix do exist though). Is > there something in the spec that says these extra Object types must be > created or is this Tuscany-specific implementation detail that should be > excluded from the CTS? > evenNumberOfOddOrEvenDigitsObject > monthObject > oddOrEvenDigitsObject > smallIntObject > smallOddNumberObject -- 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-1263) XMLEqualityChecker too strict
[ https://issues.apache.org/jira/browse/TUSCANY-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536659 ] Kelvin Goodson commented on TUSCANY-1263: - An alternative to using another tool is the approach adopted in commit http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DupElementTestCase.java?view=markup&pathrev=586476 > XMLEqualityChecker too strict > - > > Key: TUSCANY-1263 > URL: https://issues.apache.org/jira/browse/TUSCANY-1263 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Community Test Suite >Affects Versions: Java-SDO-CTS-Next >Reporter: Lionel Villard > Fix For: Java-SDO-CTS-Next > > > The XMLEqualityChecker is too strict wrt to whitespace checking. For example, > this 2 documents are considered different: > > 2003-11-24 > > 2003-11-24 > when, from the validation point of view, they are the same. -- 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-1659) SDO DateConversion test cases fail under linux
[ https://issues.apache.org/jira/browse/TUSCANY-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536655 ] Kelvin Goodson commented on TUSCANY-1659: - Luciano, can you confirm whether this is still an issue please, and if so, could you attach the surefire reports. Can you also say what JVM you are using please? Kelvin > SDO DateConversion test cases fail under linux > -- > > Key: TUSCANY-1659 > URL: https://issues.apache.org/jira/browse/TUSCANY-1659 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next > Environment: Linux Ubuntu 7.0.4 >Reporter: Luciano Resende > Fix For: Java-SDO-Next > > > The following tests are failing under revision #571238 > Tests in error: > testConversionsFromDate(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromDateTime(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromDuration(org.apache.tuscany.sdo.test.DateConversionTestCase) > testConversionsFromMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) > testConversionsFromYear(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromYearMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromYearMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) > Looks like working ok in windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content
[ https://issues.apache.org/jira/browse/TUSCANY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1842: Patch Info: [Patch Available] Setting PAtach Available: Ron's suggestion gives us a quick workaround to be committed under this JIRA. TUSCANY-1862 will provide the proper fix. > 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 > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >value="English" /> >value="French" /> >value="Spanish" /> > > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues2.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV2"; > xmlns:sev2="http://www.example.com/substitutionEV2"; > xmlns:sev="http://www.example.com/substitutionEV";> > > http://www.example.com/substitutionEV"; > schemaLocation="substitutionWithExtensionValues.xsd" /> > > > > >maxOccurs="unbounded" > type="sev2:Results2Type" /> > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues1.xml > == > > http://www.example.com/substitutionEV2";> > > http://www.example.com/substitutionEV";> > > > >
[jira] Commented: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots
[
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536641
]
Kelvin Goodson commented on TUSCANY-1853:
-
Hi Czarek, I'm just looking at what to do with this JIRA on the basis of
Frank's comment above. Could you let us know what version of SDO you are
running please? Perhaps if the issue turns out to be not already fixed you
could also attach a schema demonstrating the issue.
> 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] Issue Comment Edited: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536432 ] kgoodson edited comment on TUSCANY-1780 at 10/20/07 6:46 AM: --- Commented in error was (Author: kgoodson): Here's what the generator should be generating I think. protected static final List CATEGORY_TYPE_DEFAULT_ = (List)((XsdlistwitdefaultFactoryImpl)XsdlistwitdefaultFactory.INSTANCE).createFromString(XsdlistwitdefaultFactoryImpl.CATEGORY_TYPE, "myCat"); > [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 > > > Hello, > There seems to be a problem when generating static classes when lists are > involved. I have the following lines in my schema: > default="myCat"/> > > > > This generates the following line in the impl class: > protected static final Object CATEGORY_TYPE_DEFAULT_ = > ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), > "myCat"); > The class ModelPackageImpl doesn't exist. > I've tried this with the 1.0 version of SDO and a version I built today. > Let me know if you need any more information. Thanks, > -Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536432 ] Kelvin Goodson commented on TUSCANY-1780: - Here's what the generator should be generating I think. protected static final List CATEGORY_TYPE_DEFAULT_ = (List)((XsdlistwitdefaultFactoryImpl)XsdlistwitdefaultFactory.INSTANCE).createFromString(XsdlistwitdefaultFactoryImpl.CATEGORY_TYPE, "myCat"); > [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 > > > Hello, > There seems to be a problem when generating static classes when lists are > involved. I have the following lines in my schema: > default="myCat"/> > > > > This generates the following line in the impl class: > protected static final Object CATEGORY_TYPE_DEFAULT_ = > ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), > "myCat"); > The class ModelPackageImpl doesn't exist. > I've tried this with the 1.0 version of SDO and a version I built today. > Let me know if you need any more information. Thanks, > -Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1397. - Resolution: Fixed This patch was applied in commit 562586. Please resolve JIRAs when handled, and include a comment of the form TUSCANY- in the svn commit record in order that the commit be added to the subversion commits tab of the JIRA. > createDataObject() throws NPE if property does not exist > > > Key: TUSCANY-1397 > URL: https://issues.apache.org/jira/browse/TUSCANY-1397 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Andy Grove > Fix For: Java-SDO-Next > > Attachments: tuscany1397-v2.patch, tuscany1397.patch > > > Calling createDataObject( "foo" ) where the data object's type does not > define a property "foo" causes a null pointer exception in > DataObjectUtil.createDataObject(DataObject dataObject, Property property, > Type type) because it attempts to call property.isContainment without > checking if the property is null. > Calling createDataObject( "foo" ) on an open type should create an on-demand > property. If the type is not open and the property does not exist then an > exception should be thrown. > Thanks, > Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1128) Support attribute and element with same name
[ https://issues.apache.org/jira/browse/TUSCANY-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1128. - Resolution: Fixed > Support attribute and element with same name > > > Key: TUSCANY-1128 > URL: https://issues.apache.org/jira/browse/TUSCANY-1128 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next >Reporter: Yang ZHONG >Priority: Minor > Fix For: Java-SDO-Next > > Attachments: 1128.patch, 1128.patch, > DifferAttrFromElementTestCase.java, dupelement.xsd, dupelement.xsd, > DupElementTestCase.java, DupElementTestCase.java > > > To support attribute and element with same name within one Type such as > > > > > > > and using "@property" to access attribute and "property" to access element. > This is to support OTA standard schema used in the travel industry. > "@property" notation comes from XPath: > http://www.w3.org/TR/xpath#path-abbrev -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1144) Type Schema Location
[ https://issues.apache.org/jira/browse/TUSCANY-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1144. - Resolution: Later Will await SDO 3 spec group resolution. > 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-Next >Reporter: Yang ZHONG > Fix For: Java-SDO-Next > > 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] Resolved: (TUSCANY-193) Fix eclipse warnings for sdo/tools
[ https://issues.apache.org/jira/browse/TUSCANY-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-193. Resolution: Fixed cleaned up referenced files > Fix eclipse warnings for sdo/tools > -- > > Key: TUSCANY-193 > URL: https://issues.apache.org/jira/browse/TUSCANY-193 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Reporter: Daniel Kulp >Assignee: Frank Budinsky >Priority: Minor > Fix For: Java-SDO-Next > > Attachments: sdo.patch > > > Very small and minor patch to the sdo/tools section to remove the last > eclipse warning in there. Also patches one file in sdo/impl. The only > eclipse warning left in there is use of a deprecated API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1817) Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests
[ https://issues.apache.org/jira/browse/TUSCANY-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534846 ] Kelvin Goodson commented on TUSCANY-1817: - Thanks for your suggestions. One small problem we would have to overcome is that maven does not make test code available from one project to another project that expresses a dependency on it. Moving some part of the test code into the implementation wouldn't be nice from the point of view the run-time artifacts that are distributed. Separating testing out into higher level projects means we wouldn't get the automatic benefits of an immediate notification of the introduction of an issue when building with maven. We could insert an intermediate "test-core" project, that is not part of the SDO distribution, either between the API project and the lib projects (in dependency terms) or between the lib and the impl projects. The bodies of the tests could then be implemented in the _main_ source folder hierarchy of that project (as opposed to the test code hierarchy). The test bodies would be in abstract classes with template methods as you suggest. The lib, impl and tools-tests projects can then declare a test scope dependency on that new project, and the test programs be implemented in the test code hierarchy of the implementation projects, extending the behaviour of the test programs in the new project. Similarly the tools-test project could declare a dependency on the new project. There would be a deficiency here that I haven't got my head round yet. If we want a single location for the schemas, then they would have to be in the new project. This means I think that we wouldn't be able to rely on maven's "generate" phase to handle the generation for us in the tools-test project. One possibility would be to use svn's "externals" property to make the same schema files available to the test resources of both projects, but that may be a trip hazard. > Improve SDO test infrastructure to re-use/re-execute most dynamic tests as > static tests > --- > > Key: TUSCANY-1817 > URL: https://issues.apache.org/jira/browse/TUSCANY-1817 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SDO-Next >Reporter: Ron Gavlin > Fix For: Java-SDO-Next > > > Currently, static Tuscany SDO is being inadequately tested. Based on > TUSCANY-1812, I suspect there are currently numerous dynamic test cases that > would fail if they were executed as static test cases. I suggest the testing > infrastructure be enhanced to allow tests to be re-used as both dynamic and > static tests with minimal effort. The build should automatically execute > these "shared" tests in both dynamic and static contexts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored
[
https://issues.apache.org/jira/browse/TUSCANY-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533327
]
Kelvin Goodson commented on TUSCANY-1838:
-
I made a fix in http://svn.apache.org/viewvc?rev=583095&view=rev
Could you see if this fixes your issue please?
> HelperContext provided to createObjectOutputStream is inadvertantly ignored
> ---
>
> Key: TUSCANY-1838
> URL: https://issues.apache.org/jira/browse/TUSCANY-1838
> Project: Tuscany
> Issue Type: Bug
>Affects Versions: Java-SDO-1.0
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-Next
>
>
> Ron Gavlin reported in http://www.mail-archive.com/[EMAIL
> PROTECTED]/msg01884.html an issue with HelperContexts being unavailable
> during marshalling. I feel sure that this is due to this piece of code here
> in HelperProviderBase::ResolvableImpl#writeDataObject
> XMLHelper xmlHelperLocal = xmlHelper;
> if(objectOutput instanceof SDOObjectInputStream)
> {
> xmlHelperLocal =
> ((SDOObjectInputStream)objectOutput).getHelperContext().getXMLHelper();
> }
> xmlHelperLocal.save(dataObject, "commonj.sdo", "dataObject",
> gzipOutputStream);
> where the instanceof test and cast should be to SDOObjectOutputStream
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1838) HelperContext provided to createObjectOutputStream is inadvertantly ignored
HelperContext provided to createObjectOutputStream is inadvertantly ignored
---
Key: TUSCANY-1838
URL: https://issues.apache.org/jira/browse/TUSCANY-1838
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SDO-1.0
Reporter: Kelvin Goodson
Fix For: Java-SDO-Next
Ron Gavlin reported in http://www.mail-archive.com/[EMAIL
PROTECTED]/msg01884.html an issue with HelperContexts being unavailable during
marshalling. I feel sure that this is due to this piece of code here in
HelperProviderBase::ResolvableImpl#writeDataObject
XMLHelper xmlHelperLocal = xmlHelper;
if(objectOutput instanceof SDOObjectInputStream)
{
xmlHelperLocal =
((SDOObjectInputStream)objectOutput).getHelperContext().getXMLHelper();
}
xmlHelperLocal.save(dataObject, "commonj.sdo", "dataObject",
gzipOutputStream);
where the instanceof test and cast should be to SDOObjectOutputStream
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531744 ] Kelvin Goodson commented on TUSCANY-1493: - I've added as much as I can to my sandbox in commit http://svn.apache.org/viewvc?rev=581184&view=rev I've not added anything from the hibernate integration archive due to the licensing issues alluded to earlier. Two of the files with header issues are part of the generic snapshot code, so they are missing from what I have committed (see the commit comment in http://svn.apache.org/viewvc?rev=581184&view=rev) > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- 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-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531727 ] Kelvin Goodson commented on TUSCANY-1493: - I've been going through the files in preparation for putting them into the code base somewhere, and have been adding apache license headers to the files that have no headers, on the basis of the license you granted when attaching the zip files. There are about 10 files in the archives which have Agfa copyright headers in them (e.g. ExtendablePropertyAccessBuilder.java), saying that . ... // THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF //Agfa-Gevaert Group I don't feel it's right for me to remove those headers, although I guess that would be in the spirit of the submission. Could you please search for files with similar headers to that file, fix the headers as you see fit, and resubmit any files you wish to be included in the submission. > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- 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-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531723 ] Kelvin Goodson commented on TUSCANY-1493: - Hi, Thanks for the code. Sorry to take a while to get back to you. I have revisited this a few times to make sure I have a reasonably good feel for it before commenting. I'd love to be able to execute a test program to answer some of the question I have about the code, or at least to see some code that exercises it. Looking at the SnapshotSerializer code I think I'm OK to make the inference that the Type and Property classes used in there are your implementation classes of the SDO concepts, although of course that implementation code is not available. So, given that assumption, I understand that the implementation of your opaque snapshot representation is based on SDOs. It would be interesting to understand the issues you have encountered in using the code; for example, if there are any lossy round-trip transformations that cause problems. It would be great to work towards getting some code running inside the Tuscany code base; it would also be helpful if you could put some more words around any key design concepts and the issues you have encountered and solved, or have yet to solve. How should we proceed? Clearly the code is broken at the moment, given the missing aspects, so it's not suitable for including in the nightly build. I can put it in my sandbox, or I could set up another project under the SDO project, but not include it in the main build. > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- 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-1817) Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests
[ https://issues.apache.org/jira/browse/TUSCANY-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531015 ] Kelvin Goodson commented on TUSCANY-1817: - Ron, this sounds like a good idea. Do you have specific design thoughts or plans for a contribution for this? > Improve SDO test infrastructure to re-use/re-execute most dynamic tests as > static tests > --- > > Key: TUSCANY-1817 > URL: https://issues.apache.org/jira/browse/TUSCANY-1817 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SDO-Next >Reporter: Ron Gavlin > > Currently, static Tuscany SDO is being inadequately tested. Based on > TUSCANY-1812, I suspect there are currently numerous dynamic test cases that > would fail if they were executed as static test cases. I suggest the testing > infrastructure be enhanced to allow tests to be re-used as both dynamic and > static tests with minimal effort. The build should automatically execute > these "shared" tests in both dynamic and static contexts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1780: Patch Info: [Patch Available] Franks comment represents a fix - so setting patch available flag. > [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: > default="myCat"/> > > > > This generates the following line in the impl class: > protected static final Object CATEGORY_TYPE_DEFAULT_ = > ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), > "myCat"); > The class ModelPackageImpl doesn't exist. > I've tried this with the 1.0 version of SDO and a version I built today. > Let me know if you need any more information. Thanks, > -Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1810) SDOUtil.createHelperContext() fails with NPE on HP-UX and Solaris
[
https://issues.apache.org/jira/browse/TUSCANY-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530663
]
Kelvin Goodson commented on TUSCANY-1810:
-
This looks like an EMF problem. The failure seems to be in the EMF code at
at
org.eclipse.emf.ecore.impl.EPackageRegistryImpl$Delegator.getEFactory(EPackageRegistryImpl.java:250)
which is ..
return delegateRegistry().getEFactory(key);
suggesting null return from ...
protected EPackage.Registry delegateRegistry()
{
return delegateRegistry(Thread.currentThread().getContextClassLoader());
}
which eventually ends up in ...
public static synchronized EPackage.Registry getRegistry(ClassLoader
classLoader)
{
EPackage.Registry result =
(EPackage.Registry)classLoaderToRegistryMap.get(classLoader);
if (result == null)
{
if (classLoader == null)
{
result = null;
}
else
{
result = new EPackageRegistryImpl(getRegistry(classLoader.getParent()));
classLoaderToRegistryMap.put(classLoader, result);
}
}
return result;
}
it would appear to me by eyeballing that code that the supplied ClassLoader is
null (obtained by Thread.currentThread().getContextClassLoader()). I'm not
expert in understanding in what circumstances that might happen.
Could you please run this tiny program which I think embodies the issue in your
environments, with the EMF 2.2.3 jars on your classpath, please and report the
result. If this fails then the problem needs to be reported to EMF.
package org.apache.tuscany.sdo.test;
import org.eclipse.emf.ecore.EDataType;
import org.eclipse.emf.ecore.EcoreFactory;
public class EMFInit {
protected static final EDataType UNINITIALIZED_EDATA_TYPE =
EcoreFactory.eINSTANCE.createEDataType();
public static void main(String[] args) {
System.out.println("Uninitialised data type is " +
(UNINITIALIZED_EDATA_TYPE == null ? "null" : "not null"));
}
}
> SDOUtil.createHelperContext() fails with NPE on HP-UX and Solaris
> -
>
> Key: TUSCANY-1810
> URL: https://issues.apache.org/jira/browse/TUSCANY-1810
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: This fails on HP-UX and Solaris. It works fine on all
> other platforms tested.
>Reporter: Travis Nelson
>Priority: Blocker
>
> The following exception is thrown when attempting to create the helper
> context:
> java.lang.NullPointerException
> at
> org.eclipse.emf.ecore.impl.EPackageRegistryImpl$Delegator.getEFactory(EPackageRegistryImpl.java:250)
> at
> org.eclipse.emf.ecore.impl.EcoreFactoryImpl.init(EcoreFactoryImpl.java:55)
> at org.eclipse.emf.ecore.EcoreFactory.(EcoreFactory.java:35)
> at
> org.eclipse.emf.ecore.util.BasicExtendedMetaData.(BasicExtendedMetaData.java:2139)
> at
> org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHelperContextImpl.java:31)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:37)
> at
> org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase.java:81)
> at
> org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderImpl.java:30)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at
> commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157)
> at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126)
> at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69)
> at org.apache.tuscany.sdo.api.SDOUtil.(SDOUtil.java:47)
> at
> org.apache.tuscany.sdo.util.SDOUtil.createHelperContext(SDOUtil.java:389)
--
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-1726) List DataObject.getList(String path) should return an empty list when there is no value
[ https://issues.apache.org/jira/browse/TUSCANY-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1726. - Resolution: Fixed Patch looks good, so I committed it with an adapted test to exercise equivalent generated classes. > List DataObject.getList(String path) should return an empty list when there > is no value > --- > > Key: TUSCANY-1726 > URL: https://issues.apache.org/jira/browse/TUSCANY-1726 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: WinXP >Reporter: Fuhwei Lwo > Fix For: Java-SDO-Next > > Attachments: 1726.patch > > > According to SDO 2.1 spec section 3.1.4, it said "DataObject methods with a > return type of List, on the DataObject interface or generated, return empty > lists rather than null when there is no value." This means getList() method > should return an empty list when there is no value. Current implementation > returns null which is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1493) Snapshot mapping framework to convert DataObjects to and from Java objects
[ https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529846 ] Kelvin Goodson commented on TUSCANY-1493: - Bogdan, it's not in the code base yet. I'm looking at it now. > Snapshot mapping framework to convert DataObjects to and from Java objects > -- > > Key: TUSCANY-1493 > URL: https://issues.apache.org/jira/browse/TUSCANY-1493 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: bert.robben > Fix For: Java-SDO-Next > > Attachments: sdo-snapshot.zip, sdo.zip > > > We're developing 3-tier applications with a swing client, JBoss app server > and a couple of databases in the back-end. We use sdo as mechanism to > exchange data between our client and our server. On the server side we have a > fairly complex implementation based partially on Hibernate pojo's, partially > on an inhouse legacy persistency system. The legacy part (although written in > Java) is very hard to change. In this environment we often need to convert > between data objects and server side objects (typically, but not always at a > transition from server to client or vice versa). > To support this we developed a mapping framework that allows us to convert > data between SDO and ordinary Java objects. This framework defines a number > of important concepts. > - A snapshot is an opaque collection of structured data at a given moment in > time. It is opaque in the sense that the data inside can't be accessed > directly. > - A Mapper is an interface that defined how data can be accessed from an > object. We have implementations for SDO DataObjects, normal Java POJO's > (following java beans convention). hibernate pojos, and support for > customizing this to access any kind of object (as we need for instance for > our legacy objects). > - We defined a DataAccessService (sorry for the confusing name) that given a > mapper and some objects can create a snapshot. Given a snapshot and a mapper > it can instantiate new objects. As such we can convert data to and from data > objects very easily. > This framework is part of our in-house developed implementation of the SDO > spec. We want to share our code and experience with the open-source > community. As such, Frank Budinsky proposed that we make JIRA request for > this to start the discussion. > I'll attach the core classes for this feature to this JIRA. At this moment > I'm not making the entire code available because we implemented more than one > additional feature (I'll add some more JIRA over the next days) and I'd like > to have a more focussed discussion. Also, at this moment in time some smaller > parts of implementation (for instance the hibernate integration) are still > implemented as a specialization of our SDO implementation. As such they can't > be built outside of the rest of our application (which is not open-sourced). > However this is just a matter of finding enough time to move them to our sdo > component. -- 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-1788) DataObjectXMLStreamReader doesn't declare the xsi namespace if there is a xsi:type or xsi:nil attribute
[ https://issues.apache.org/jira/browse/TUSCANY-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529826 ] Kelvin Goodson commented on TUSCANY-1788: - There has been one commit for this JIRA. I'm not sure if that's the full extent of the required fix. Can you provide a a test to demonstrate the fix please? > DataObjectXMLStreamReader doesn't declare the xsi namespace if there is a > xsi:type or xsi:nil attribute > --- > > Key: TUSCANY-1788 > URL: https://issues.apache.org/jira/browse/TUSCANY-1788 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Raymond Feng > Fix For: Java-SDO-Next > > > In the case that we need to produce an xsi:type or xsi:nil attribute, the > current code doesn't declare the xsi namespace. As a result, it creates an > invalid XML stream. I'll check in a fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (TUSCANY-1725) XSD2JavaGenerator has a problem with associations navigable from both sides
[ https://issues.apache.org/jira/browse/TUSCANY-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529388 ] kgoodson edited comment on TUSCANY-1725 at 9/21/07 4:46 AM: -- Thanks for this. I'd like to add the schema as the basis of a test, as a first step. We need you to grant license to the ASF to use it. Would you be able to attach a file with the schema please and tick the "Grant License" button please? (for ref: here's the thread that led to this jira -- http://www.mail-archive.com/[EMAIL PROTECTED]/msg01818.html) was (Author: kgoodson): Thanks for this. I'd like to add the schema as the basis of a test, as a first step. We need you to grant license to the ASF to use it. Would you be able to attach a file with the schema please and tick the "Grant License" button please? > XSD2JavaGenerator has a problem with associations navigable from both sides > --- > > Key: TUSCANY-1725 > URL: https://issues.apache.org/jira/browse/TUSCANY-1725 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 > Environment: Linux >Reporter: Miro Kandic > Fix For: Java-SDO-Next > > > XSD2JavaGenerator does not work in the case of any association type > (association, composition) that is navigable from both sides. > I have intentionally, just to test generator, made Customer-SoH association > in the next schema navigable from both sides and generated code cannot be > compiled. > Frank, after initial analyses, confirmed that saying "Bidirectional > references are broken in Tuscany. They seem > to have been broken when we switched over to the new (noEMF) codegen > patterns." > Next is complete XSD built automatically from the UML model. > > > targetNamespace="http://www.cisco.com/odns/soa"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:sdo="commonj.sdo" xmlns:sdoxml="commonj.sdo/xml" > xmlns:impl="http://www.cisco.com/odns/soa"; > elementFormDefault="qualified"> > > > > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > sdoxml:propertyType="impl:SoH" > sdoxml:oppositeProperty="customer" minOccurs="0" > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > sdoxml:propertyType="impl:Customer" > sdoxml:oppositeProperty="orders" minOccurs="1" maxOccurs="1" > /> > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > sdoxml:propertyType="impl:Product" > sdoxml:oppositeProperty="soLs" minOccurs="1" maxOccurs="1" /> > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1725) XSD2JavaGenerator has a problem with associations navigable from both sides
[ https://issues.apache.org/jira/browse/TUSCANY-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529388 ] Kelvin Goodson commented on TUSCANY-1725: - Thanks for this. I'd like to add the schema as the basis of a test, as a first step. We need you to grant license to the ASF to use it. Would you be able to attach a file with the schema please and tick the "Grant License" button please? > XSD2JavaGenerator has a problem with associations navigable from both sides > --- > > Key: TUSCANY-1725 > URL: https://issues.apache.org/jira/browse/TUSCANY-1725 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 > Environment: Linux >Reporter: Miro Kandic > Fix For: Java-SDO-Next > > > XSD2JavaGenerator does not work in the case of any association type > (association, composition) that is navigable from both sides. > I have intentionally, just to test generator, made Customer-SoH association > in the next schema navigable from both sides and generated code cannot be > compiled. > Frank, after initial analyses, confirmed that saying "Bidirectional > references are broken in Tuscany. They seem > to have been broken when we switched over to the new (noEMF) codegen > patterns." > Next is complete XSD built automatically from the UML model. > > > targetNamespace="http://www.cisco.com/odns/soa"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:sdo="commonj.sdo" xmlns:sdoxml="commonj.sdo/xml" > xmlns:impl="http://www.cisco.com/odns/soa"; > elementFormDefault="qualified"> > > > > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > sdoxml:propertyType="impl:SoH" > sdoxml:oppositeProperty="customer" minOccurs="0" > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > sdoxml:propertyType="impl:Customer" > sdoxml:oppositeProperty="orders" minOccurs="1" maxOccurs="1" > /> > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > sdoxml:propertyType="impl:Product" > sdoxml:oppositeProperty="soLs" minOccurs="1" maxOccurs="1" /> > maxOccurs="unbounded" /> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > maxOccurs="1"/> > > > > > > > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > maxOccurs="unbounded" /> > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1574) SDOXSDEcoreBuilder.createResourceSet() is not thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1574. - Resolution: Fixed Fixed in rev 578054 > SDOXSDEcoreBuilder.createResourceSet() is not thread safe > - > > Key: TUSCANY-1574 > URL: https://issues.apache.org/jira/browse/TUSCANY-1574 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-1.0 > Environment: n/a >Reporter: David T. Adcox > Fix For: Java-SDO-Next > > Attachments: 1574.patch > > > The method createResourceSet() in SDOXSDEcoreBuilder is not thread safe. It > performs an enumeration of EPackage resource objects and adds them to the > ResourceSet created within the method. The problem is that a ResourceSet > object is a container. So, when the Resource objects are added with this > statement: > resources.add(resource); > EMF attempts to first unlink the resource from its previous container. That > in itself is an issue, but beyond that, during a stress run, the unlinking > can occur simultaneously on multiple threads, causing exceptions. This code > was added for Tuscany-513. I'm not clear what are the goals, but I was > wondering if we can accomplish the same task in another manner. The goal > seems to be to expose the newly created ResourceSet to the built-in models. > Perhaps this pattern from DataObjectUtil.configureResourceSet would work: > resourceSet.setPackageRegistry(new > EPackageRegistryImpl(HelperContextImpl.getBuiltInModelRegistry())); > Would this line of code accomplish a similar function? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1759) quote-xquery code missing from RC3 source distro
[ https://issues.apache.org/jira/browse/TUSCANY-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1759. - Resolution: Fixed fixed in http://svn.apache.org/viewvc?rev=577237&view=rev > quote-xquery code missing from RC3 source distro > > > Key: TUSCANY-1759 > URL: https://issues.apache.org/jira/browse/TUSCANY-1759 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-SCA-1.0 > Environment: windows and > http://people.apache.org/~antelder/tuscany/1.0-RC3/apache-tuscany-sca-1.0-incubating-src.zip >Reporter: Kelvin Goodson >Assignee: Kelvin Goodson > Fix For: Java-SCA-1.0 > > > C:\Release\SCA\1.0\RC3\src\tuscany-sca-1.0-incubating-src>mvn > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: unknown > Reason: Could not find the model file > 'C:\Release\SCA\1.0\RC3\src\tuscany-sca-1.0-incubating-src\samples\quote-xquery\po > m.xml'. for project unknown > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Could not find the model > file 'C:\Release\SCA\1.0\RC3\src\tuscany-sca- > 1.0-incubating-src\samples\quote-xquery\pom.xml'. for project unknown > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) -- 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] Assigned: (TUSCANY-1759) quote-xquery code missing from RC3 source distro
[ https://issues.apache.org/jira/browse/TUSCANY-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson reassigned TUSCANY-1759: --- Assignee: Kelvin Goodson > quote-xquery code missing from RC3 source distro > > > Key: TUSCANY-1759 > URL: https://issues.apache.org/jira/browse/TUSCANY-1759 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-SCA-1.0 > Environment: windows and > http://people.apache.org/~antelder/tuscany/1.0-RC3/apache-tuscany-sca-1.0-incubating-src.zip >Reporter: Kelvin Goodson >Assignee: Kelvin Goodson > Fix For: Java-SCA-1.0 > > > C:\Release\SCA\1.0\RC3\src\tuscany-sca-1.0-incubating-src>mvn > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: unknown > Reason: Could not find the model file > 'C:\Release\SCA\1.0\RC3\src\tuscany-sca-1.0-incubating-src\samples\quote-xquery\po > m.xml'. for project unknown > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Could not find the model > file 'C:\Release\SCA\1.0\RC3\src\tuscany-sca- > 1.0-incubating-src\samples\quote-xquery\pom.xml'. for project unknown > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) -- 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-1759) quote-xquery code missing from RC3 source distro
quote-xquery code missing from RC3 source distro Key: TUSCANY-1759 URL: https://issues.apache.org/jira/browse/TUSCANY-1759 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Environment: windows and http://people.apache.org/~antelder/tuscany/1.0-RC3/apache-tuscany-sca-1.0-incubating-src.zip Reporter: Kelvin Goodson Fix For: Java-SCA-1.0 C:\Release\SCA\1.0\RC3\src\tuscany-sca-1.0-incubating-src>mvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file 'C:\Release\SCA\1.0\RC3\src\tuscany-sca-1.0-incubating-src\samples\quote-xquery\po m.xml'. for project unknown [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file 'C:\Release\SCA\1.0\RC3\src\tuscany-sca- 1.0-incubating-src\samples\quote-xquery\pom.xml'. for project unknown at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) -- 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-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528702
]
Kelvin Goodson commented on TUSCANY-1527:
-
The info I have on these events came from Frank's book
(http://www.informit.com/store/product.aspx?isbn=0131425420&rl=1). There's a
whole load of pointers to documents and resources at
http://www.eclipse.org/modeling/emf/docs/ which may save you having to lay
your hands on the book.
> 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 XObservable initializeProperty(Property prop) {
> XObservable observable =
> XObservableFactory.create(prop.getType().getInstanceClass(), this);
> if (prop.isMany()) {
> observable.init(new DataObjectListModel(this, prop));
> }
> properties[prop.getIndex()] = observable;
>
[jira] Resolved: (TUSCANY-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse
[ https://issues.apache.org/jira/browse/TUSCANY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1638. - Resolution: Fixed Assuming this is fixed in the live environment, since the test case passes. Please reopen if issues still exist. > SDO command-line code generator behaves differently than standalone when > invoked in Eclipse > --- > > Key: TUSCANY-1638 > URL: https://issues.apache.org/jira/browse/TUSCANY-1638 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 > Environment: OS is Windows XP Professional SP2, and the SDO command > line tool is invoked in side an Eclipse 3.3 plugin. >Reporter: Sean Zhou > Fix For: Java-SDO-Next > > Attachments: 1638.patch, test1638.zip > > > I am trying to invoke the SDO command-line code generator inside eclipse > which is causing it to behave differently than standalone. The following fix > is suggested by Frank in Tuscany: >1) In class > org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory > add another override method, createGenModelAdapter(), to return a new Tuscany > subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter). >2) In the new subclass, override the ensureProjectExists() method to do > nothing. >3) Override anything else you need to ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1685) XSD2JavaGenerator should support name mangling (dashes to underscores, etc.)
[ https://issues.apache.org/jira/browse/TUSCANY-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528095 ] Kelvin Goodson commented on TUSCANY-1685: - Any name overrides must be done with schema annotations, so the input to the generator must contain those annotations, such as sdo:name="Bogus_1" in the input schema. The SDO spec allows for a generator to insert annotations into an updated schema before generating, in which case the generator must be able to output the annotated schema, but we don't have that capacity currently. > XSD2JavaGenerator should support name mangling (dashes to underscores, etc.) > > > Key: TUSCANY-1685 > URL: https://issues.apache.org/jira/browse/TUSCANY-1685 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 >Reporter: Ron Gavlin >Priority: Critical > Fix For: Java-SDO-Next > > > I have the following complex type in a schema: > > > > > > When I use XSD2JavaGenerator to code-generate classes for this schema, an > invalidly named Bogus-1.java class is generated. The class name should be > mangled into a valid Java class name, such as Bogus_1.java. EMF provides this > behavior in its NameMangler which Tuscany currently disables. -- 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-1296) Build failure on Linux/IBM JDK
[ https://issues.apache.org/jira/browse/TUSCANY-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528040 ] Kelvin Goodson commented on TUSCANY-1296: - I think I am seeing this issue when trying to build on linux. Is this what you saw? [INFO] Building Apache Tuscany SCA Data Binding for JAXB [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: com.sun.tools.xjc.maven2:maven-jaxb-plugin Reason: Failed to build model from file '/home/kg/.m2/repository/com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.1/maven-jaxb-plugin-1.1.pom'. Error: 'null' for project com.sun.tools.xjc.maven2:maven-jaxb-plugin == my environment is ... [EMAIL PROTECTED] sca-java-1.0]$ uname -a Linux kglinux 2.6.18-8.1.6.el5 #1 SMP Fri Jun 1 18:52:11 EDT 2007 i686 i686 i386 GNU/Linux with [EMAIL PROTECTED] sca-java-1.0]$ $JAVA_HOME/bin/java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070806 (SR5a)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426 (JIT enabled) J9VM - 20070420_12448_lHdSMR JIT - 20070419_1806_r8 GC - 200704_19) JCL - 20070725 > Build failure on Linux/IBM JDK > -- > > Key: TUSCANY-1296 > URL: https://issues.apache.org/jira/browse/TUSCANY-1296 > Project: Tuscany > Issue Type: Bug > Components: Build System >Affects Versions: Java-SCA-0.90 > Environment: Fedora Core 5 > Ibm JDK 1.5.0 build 2.3 > Maven 2.0.6 >Reporter: Simon Laws >Assignee: Simon Laws > Fix For: Java-SCA-Next > > > SCA fails to build under maven in my Linux/IBM JDK environment. The culprit > is the maven-jaxb-plugin. The pom provided with the version that we refer in > our poms, e.g. databinding-jaxb, has a non-UTF8 character which causes the > maven build to fail with the IBM JDK 1.5.0 on Linux. I can confirm that this > does not cause a problem with the same JDK (same version and build at least) > on Windows XP. I tried using different maven-jaxb-plugins from a variety of > repositories. All failed for other reasons. There is a manual work around to > the problem, i.e. remove the non-UTF8 characters. > The best solution would be to move to a newer version of this plugin (I note > that the author name that includes the non-UTF8 characted doesn't appear in > later versions) but we need to test these later version on all platforms. -- 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-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse
[
https://issues.apache.org/jira/browse/TUSCANY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527546
]
Kelvin Goodson commented on TUSCANY-1638:
-
I have now run the test, seen the failure, applied the patch and seen clean
code generation, so I will commit the patch. For reference I had to download
the Eclipse Classic version of Europa, since the Java developers version
doesn't include the eclipse plugin stuff. After that, when configuring the
paths in the SampleAction class, I couldn't use an absolute path for the
targetDirectory, since the test adds this to the base runtime directory of the
spawned eclipse environment , so my config element looked like this ...
IPath installIPath = new
Path("C:/Dev/test1638/apache-tuscany-sca-0.99-incubating/tuscany-sca-0.99-incubating");
String targetDirectory = "/../test1638/output/";
String wsdlURI = "C:/Dev/test1638/AddressBook.wsdl";
I could work this out by looking at the "Run as" dialog entry for the Eclipse
Application and seeing that the runtime directory was ..
${workspace_loc}/../runtime-EclipseApplication
> SDO command-line code generator behaves differently than standalone when
> invoked in Eclipse
> ---
>
> Key: TUSCANY-1638
> URL: https://issues.apache.org/jira/browse/TUSCANY-1638
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Tools
>Affects Versions: Java-SDO-1.0
> Environment: OS is Windows XP Professional SP2, and the SDO command
> line tool is invoked in side an Eclipse 3.3 plugin.
>Reporter: Sean Zhou
> Fix For: Java-SDO-Next
>
> Attachments: 1638.patch, test1638.zip
>
>
> I am trying to invoke the SDO command-line code generator inside eclipse
> which is causing it to behave differently than standalone. The following fix
> is suggested by Frank in Tuscany:
>1) In class
> org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory
> add another override method, createGenModelAdapter(), to return a new Tuscany
> subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter).
>2) In the new subclass, override the ensureProjectExists() method to do
> nothing.
>3) Override anything else you need to ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse
[ https://issues.apache.org/jira/browse/TUSCANY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527498 ] Kelvin Goodson commented on TUSCANY-1638: - I was trying this, but don't see "Run as .. => Eclipse Application" in the context menu of the emitterTest project > SDO command-line code generator behaves differently than standalone when > invoked in Eclipse > --- > > Key: TUSCANY-1638 > URL: https://issues.apache.org/jira/browse/TUSCANY-1638 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 > Environment: OS is Windows XP Professional SP2, and the SDO command > line tool is invoked in side an Eclipse 3.3 plugin. >Reporter: Sean Zhou > Fix For: Java-SDO-Next > > Attachments: 1638.patch, test1638.zip > > > I am trying to invoke the SDO command-line code generator inside eclipse > which is causing it to behave differently than standalone. The following fix > is suggested by Frank in Tuscany: >1) In class > org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory > add another override method, createGenModelAdapter(), to return a new Tuscany > subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter). >2) In the new subclass, override the ensureProjectExists() method to do > nothing. >3) Override anything else you need to ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526097
]
Kelvin Goodson commented on TUSCANY-1527:
-
I resolved the interface awkwardness in commit 574177
(http://svn.apache.org/viewvc?rev=574177&view=rev)
> 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 XObservable initializeProperty(Property prop) {
> XObservable 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()];
>
[jira] Commented: (TUSCANY-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse
[ https://issues.apache.org/jira/browse/TUSCANY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525399 ] Kelvin Goodson commented on TUSCANY-1638: - In the absence of a test case for this I manually altered the value of org.eclipse.emf.common.EMFPlugin.IS_ECLIPSE_RUNNING to true in an eclipse debug session and observed different behaviour. I made the changes suggested and observed that the generation then proceeded OK with the variable value once again altered to true. Please could you try out the updated code that I committed in http://svn.apache.org/viewvc?view=rev&revision=573214 and see if it fixes your problem. I will leave the JIRA open pending your feedback. My guess is it is not easy to provide a test case to exhibit the problem, but if you can it would be greatly appreciated. > SDO command-line code generator behaves differently than standalone when > invoked in Eclipse > --- > > Key: TUSCANY-1638 > URL: https://issues.apache.org/jira/browse/TUSCANY-1638 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Tools >Affects Versions: Java-SDO-1.0 > Environment: OS is Windows XP Professional SP2, and the SDO command > line tool is invoked in side an Eclipse 3.3 plugin. >Reporter: Sean Zhou > Fix For: Java-SDO-Next > > > I am trying to invoke the SDO command-line code generator inside eclipse > which is causing it to behave differently than standalone. The following fix > is suggested by Frank in Tuscany: >1) In class > org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory > add another override method, createGenModelAdapter(), to return a new Tuscany > subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter). >2) In the new subclass, override the ensureProjectExists() method to do > nothing. >3) Override anything else you need to ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1659) SDO DateConversion test cases fail under linux
[ https://issues.apache.org/jira/browse/TUSCANY-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525115 ] Kelvin Goodson commented on TUSCANY-1659: - I get no errors on my pendrivelinux env (a debian derivative) > SDO DateConversion test cases fail under linux > -- > > Key: TUSCANY-1659 > URL: https://issues.apache.org/jira/browse/TUSCANY-1659 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next > Environment: Linux Ubuntu 7.0.4 >Reporter: Luciano Resende > Fix For: Java-SDO-Next > > > The following tests are failing under revision #571238 > Tests in error: > testConversionsFromDate(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromDateTime(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromDuration(org.apache.tuscany.sdo.test.DateConversionTestCase) > testConversionsFromMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) > testConversionsFromYear(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromYearMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromYearMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) > Looks like working ok in windows. -- 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-1659) SDO DateConversion test cases fail under linux
[ https://issues.apache.org/jira/browse/TUSCANY-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525099 ] Kelvin Goodson commented on TUSCANY-1659: - could you please attach the report file from the target/sure-firereports directory if you still have it? > SDO DateConversion test cases fail under linux > -- > > Key: TUSCANY-1659 > URL: https://issues.apache.org/jira/browse/TUSCANY-1659 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Next > Environment: Linux Ubuntu 7.0.4 >Reporter: Luciano Resende > Fix For: Java-SDO-Next > > > The following tests are failing under revision #571238 > Tests in error: > testConversionsFromDate(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromDateTime(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromDuration(org.apache.tuscany.sdo.test.DateConversionTestCase) > testConversionsFromMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) > testConversionsFromYear(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromYearMonth(org.apache.tuscany.sdo.test.DateConversionTestCase) > > testConversionsFromYearMonthDay(org.apache.tuscany.sdo.test.DateConversionTestCase) > Looks like working ok in windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1359) New SDOUtil: Upper and lower bound on properties where 'isMany' is true
[
https://issues.apache.org/jira/browse/TUSCANY-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1359:
Patch Info: (was: [Patch Available])
patch available flag was set in error
> New SDOUtil: Upper and lower bound on properties where 'isMany' is true
> ---
>
> Key: TUSCANY-1359
> URL: https://issues.apache.org/jira/browse/TUSCANY-1359
> Project: Tuscany
> Issue Type: Wish
> Components: Java SDO Tools
>Reporter: Christian Landbo Frederiksen
>Priority: Minor
> Fix For: Java-SDO-Next
>
>
> Can be implemented like this:
> public static int getUpperBound(Property property) {
> return ((EStructuralFeature) property).getUpperBound();
> }
>public static int getLowerBound(Property property) {
>return ((EStructuralFeature) property).getLowerBound();
>}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
