You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Miro Kandic (mkandic)" <mk...@cisco.com> on 2007/09/15 02:40:40 UTC
XSD2JavaGenerator and non-containment references
I am having a problem with new XSD2JavaGenerator (M2 was OK) and it generates code that cannot be compiled in case when container element has non-containment reference to the container.
Entire xsd file is attched.
In this case I want to use static API and I want to get sales order header (SoH) from its lines (SoL) using the same Java code (getter) as in case when I use corresponding POJO's.
It works fine if property is non-containment reference to no container class (SoL references product or SoH references Customer).
I am a new in this community and I do not know if this is considered as a bug who and how should open it. Please, advise.
<xsd:complexType name="SoH">
<xsd:sequence>
<xsd:element name="customer" type="xsd:IDREF" sdoxml:propertyType="impl:Customer" sdoxml:oppositeProperty="soHs" minOccurs="1" maxOccurs="1" />
<xsd:element name="lines" type="impl:SoL" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="number" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="receivedDate" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:complexType name="SoL">
<xsd:sequence>
<xsd:element name="order" type="xsd:IDREF" sdoxml:propertyType="impl:SoH" sdoxml:oppositeProperty="lines" minOccurs="1" maxOccurs="1" />
<xsd:element name="product" type="xsd:IDREF" sdoxml:propertyType="impl:Product" sdoxml:oppositeProperty="soLs" minOccurs="1" maxOccurs="1" />
<xsd:element name="soLineSch" type="impl:SoLSch" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="quantity" type="xsd:double" minOccurs="1" maxOccurs="1"/>
<xsd:element name="requestedDate" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
Regards,
Miro
RE: XSD2JavaGenerator and non-containment references
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Miro,
You're right. The generated method is a little more complicated than I
said. The generated getCircle() method would actually look something like
this:
Circle getCircle() { if (getContainmentProperty() !=
getProperty_Circle_points()) return null; return (Circle)getContainer(); }
And the getPolygon() method, if also requested, would look like this:
Polygon getPolygon() { if (getContainmentProperty() !=
getProperty_Polygon_points()) return null; return (Polygon)getContainer();
}
Note that EMF works exactly this way.
Frank
"Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/17/2007 02:42:10
PM:
> Frank,
>
> maybe solution for the representation of composition (containment)
> in XSD and SDO is not so simple.
> Recall that one class in UML class diagram can be part of many
> compositions but instance of that class, in the run-time, can be
> part of only one whole/assembly object (well known example with
> class Point that can be part in run-time of either Polygon or Circle
> but not both in the same time).
>
> So this would not be solution for this design problem:
> <xsd:element name="points" type="impl:Point"
> sdojava:getContainer="getCircle" minOccurs="0" maxOccurs="unbounded" />
>
> because we do not know what is class of point's container in advance.
>
> ((DataObject)point.getContainer() should return object either of
> Circle or Polygon type and one of static API methods point.
> getCyrcle() or point.GetPolygon() will return null and other method
> will return something.
>
> I am developing DAS for JPA (EJB 3.0) where DAS accepts set of EJB-
> QL queries and returns SDO DataGraph (also applyChanges in opposite
> direction) and developing that graph-to-graph transformation of
> POJOs graph (not tree) to SDO graph (should be graph not tree) I saw
> couple of missing peaces in SDO specification and technology and I
> will try to compile that and come back as soon as I can.
>
> Regards,
> Miro.
>
>
>
> Miro Kandic
> (408)525-2596
>
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Mon 9/17/2007 11:01 AM
> To: tuscany-user@ws.apache.org
> Subject: RE: XSD2JavaGenerator and non-containment references
>
> Miro,
>
> You are right. Bidirectional references are broken in Tuscany. They seem
> to have been broken when we switched over to the new (noEMF) codegen
> patterns. I guess nobody uses them much and we don't have a test case.
Can
> you please open a JIRA bug report to track this?
>
> I understand your point about wanting a static (non SDO dependent) way
to
> navigate to the container. I think this is something that we should try
to
> change in the next version of SDO. Maybe something like this:
>
> <xsd:element name="lines" type="impl:SoL"
> sdojava:getContainer="getOrder" minOccurs="0" maxOccurs="unbounded" />
>
> Maybe for now in Tuscany, we could just always generate a static method
> for getContainer equal to "get" + <container type name>. For example, we
> would generate:
>
> SoH getSoH() { return (SoH)getContainer(); }
>
> in class SoLImpl. This wouldn't be standard SDO, but a generator is
> allowed to generate additional implementation-specific methods and still
> be considered compliant.
>
> Frank
>
> "Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/17/2007
01:09:38
> PM:
>
> > Frank,
> >
> > actually XSD2JavaGenerator does not work in the case of any
> > association type that is navigable from both sides.
> > I have intentionally, just to test generator, made Customer-SoH
> > association navigable from both sides and generated code again
> > cannot be compiled.
> >
> > Regarding your comments on bidirectional references and
> > containments, I know I can get container using dynamic SDO API but I
> > don't want to see in a code that implements business logic any code
> > that is related to protocols or data implementation technologies.
> > Packing data to SOAP envelop or sendig data over IIOP is job of
> > stubs and scaletons and main stream priogrammer should not ever cast
> > object to classes related to those techologies. Based on the same
> > principales, business programmer should not be avere that object
> > he/she is dealing with is actually instance of some Hybernate proxy
> > or SDO DataObject and should not ever cast those objects to
> > mentioned classes unless he/she develops some tools or similar
> > generic software.
> > And I do not want to use any dynamic API if I don't have to, so I
> > prefer to have typed Java API and SDO specification explicitally
> > lists that support as one of the major requirements. So SDO should
> > support static API defined by XSD schema.
> > I think Java business programmer should be familiar with UML class
> > diagrams that define domain and should get only corresponding POJOs
> > to deal with. Code dealing with data transport or object
> > distribution or data persistance, where BTW one technology is "cool"
> > today and next day another one, should be hidden in adapters,
> > skeletons and stubs.
> >
> > Next is complete XSD built automatically from attached UML.
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!--
> Attention: Generated code! Do not modify by hand!
> > Generated by: XmlSchema.vsl in andromda-xmlschema-cartridge.
> > -->
> > <xsd:schema
> > 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">
> >
> > <xsd:import namespace="commonj.sdo/xml"
> schemaLocation="sdoXML.xsd"/>
> >
> > <xsd:complexType name="Address">
> > <xsd:sequence>
> > <xsd:element name="street" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="city" type="xsd:string" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Customer">
> > <xsd:sequence>
> > <xsd:element name="orders" type="xsd:IDREF" sdoxml:
> > propertyType="impl:SoH"
> > sdoxml:oppositeProperty="customer" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="name" type="xsd:string" minOccurs="1"
> > maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Part">
> > <xsd:sequence>
> > <xsd:element name="uom" type="xsd:string" minOccurs="1"
> > maxOccurs="1"/>
> > <xsd:element name="aggState" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Product">
> > <xsd:complexContent>
> > <xsd:extension base="impl:Part">
> > <xsd:sequence>
> > <xsd:element name="description" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > </xsd:sequence>
> > </xsd:extension>
> > </xsd:complexContent>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoH">
> > <xsd:sequence>
> > <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Customer"
> > sdoxml:oppositeProperty="orders" minOccurs="1"
> > maxOccurs="1" />
> > <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="number" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="receivedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoL">
> > <xsd:sequence>
> > <xsd:element name="product" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Product"
> > sdoxml:oppositeProperty="soLs" minOccurs="1"
> maxOccurs="1" />
> > <xsd:element name="soLineSch" type="impl:SoLSch"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="quantity" type="xsd:double"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="requestedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoLSch">
> > <xsd:sequence>
> > <xsd:element name="requestedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="quantity" type="xsd:double"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:element name="DataGraphRootEl" type="impl:DataGraphRoot"/>
> > <xsd:complexType name="DataGraphRoot">
> > <xsd:sequence>
> > <xsd:element name="customer" type="impl:Customer"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="product" type="impl:Product"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="part" type="impl:Part" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="soH" type="impl:SoH" minOccurs="0"
> > maxOccurs="unbounded" />
> > </xsd:sequence>
> > </xsd:complexType>
> >
> > </xsd:schema>
> >
> >
> >
> > Miro
> >
> >
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Mon 9/17/2007 7:49 AM
> > To: tuscany-user@ws.apache.org
> > Subject: Re: XSD2JavaGenerator and non-containment references
> >
> > Miro,
> >
> > Both sides of a relationship defined with sdoXML:oppositeProperty need
> to
> > be non-containment references. All containment references are
implicitly
> > bidirectional (the reverse is the elements container), so you wouldn't
> > really want to use an IDREF element anyway - it's just duplicate
> > information.
> >
> > To get the SoH from an SoL, you can call:
> >
> > SoH soh = (SoH)sol.getContainer();
> >
> > You could manually add a getOrder() (convenience) method in the
> generated
> > class like this:
> >
> > SoH getOrder() { return (SoH)getContainer(): }
> >
> > EMF has a way to generate this kind of method for you, but there's no
> > support for this in SDO.
> >
> > Frank.
> >
> > "Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/14/2007
> 08:40:40
> > PM:
> >
> > > I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
> > > generates code that cannot be compiled in case when container
> > > element has non-containment reference to the container.
> > > Entire xsd file is attched.
> > > In this case I want to use static API and I want to get sales order
> > > header (SoH) from its lines (SoL) using the same Java code (getter)
> > > as in case when I use corresponding POJO's.
> > > It works fine if property is non-containment reference to no
> > > container class (SoL references product or SoH references Customer).
> > >
> > > I am a new in this community and I do not know if this is considered
> > > as a bug who and how should open it. Please, advise.
> > >
> > > <xsd:complexType name="SoH">
> > > <xsd:sequence>
> > > <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> > > propertyType="impl:Customer" sdoxml:oppositeProperty="soHs"
> > > minOccurs="1" maxOccurs="1" />
> > > <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> > > maxOccurs="unbounded" />
> > > <xsd:element name="number" type="xsd:string"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="receivedDate" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="modifiedBy" type="xsd:string"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="created" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > > maxOccurs="1"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > > </xsd:complexType>
> > >
> > > <xsd:complexType name="SoL">
> > > <xsd:sequence>
> > > <xsd:element name="order" type="xsd:IDREF" sdoxml:
> > > propertyType="impl:SoH" sdoxml:oppositeProperty="lines"
> > > minOccurs="1" maxOccurs="1" />
> > > <xsd:element name="product" type="xsd:IDREF" sdoxml:
> > > propertyType="impl:Product" sdoxml:oppositeProperty="soLs"
> > > minOccurs="1" maxOccurs="1" />
> > > <xsd:element name="soLineSch" type="impl:SoLSch"
> > > minOccurs="0" maxOccurs="unbounded" />
> > > <xsd:element name="quantity" type="xsd:double"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="requestedDate" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="modifiedBy" type="xsd:string"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="created" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > > maxOccurs="1"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > > </xsd:complexType>
> > >
> > > Regards,
> > > Miro
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: XSD2JavaGenerator and non-containment references
Posted by "Miro Kandic (mkandic)" <mk...@cisco.com>.
Frank,
maybe solution for the representation of composition (containment) in XSD and SDO is not so simple.
Recall that one class in UML class diagram can be part of many compositions but instance of that class, in the run-time, can be part of only one whole/assembly object (well known example with class Point that can be part in run-time of either Polygon or Circle but not both in the same time).
So this would not be solution for this design problem:
<xsd:element name="points" type="impl:Point"
sdojava:getContainer="getCircle" minOccurs="0" maxOccurs="unbounded" />
because we do not know what is class of point's container in advance.
((DataObject)point.getContainer() should return object either of Circle or Polygon type and one of static API methods point.getCyrcle() or point.GetPolygon() will return null and other method will return something.
I am developing DAS for JPA (EJB 3.0) where DAS accepts set of EJB-QL queries and returns SDO DataGraph (also applyChanges in opposite direction) and developing that graph-to-graph transformation of POJOs graph (not tree) to SDO graph (should be graph not tree) I saw couple of missing peaces in SDO specification and technology and I will try to compile that and come back as soon as I can.
Regards,
Miro.
Miro Kandic
(408)525-2596
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Mon 9/17/2007 11:01 AM
To: tuscany-user@ws.apache.org
Subject: RE: XSD2JavaGenerator and non-containment references
Miro,
You are right. Bidirectional references are broken in Tuscany. They seem
to have been broken when we switched over to the new (noEMF) codegen
patterns. I guess nobody uses them much and we don't have a test case. Can
you please open a JIRA bug report to track this?
I understand your point about wanting a static (non SDO dependent) way to
navigate to the container. I think this is something that we should try to
change in the next version of SDO. Maybe something like this:
<xsd:element name="lines" type="impl:SoL"
sdojava:getContainer="getOrder" minOccurs="0" maxOccurs="unbounded" />
Maybe for now in Tuscany, we could just always generate a static method
for getContainer equal to "get" + <container type name>. For example, we
would generate:
SoH getSoH() { return (SoH)getContainer(); }
in class SoLImpl. This wouldn't be standard SDO, but a generator is
allowed to generate additional implementation-specific methods and still
be considered compliant.
Frank
"Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/17/2007 01:09:38
PM:
> Frank,
>
> actually XSD2JavaGenerator does not work in the case of any
> association type that is navigable from both sides.
> I have intentionally, just to test generator, made Customer-SoH
> association navigable from both sides and generated code again
> cannot be compiled.
>
> Regarding your comments on bidirectional references and
> containments, I know I can get container using dynamic SDO API but I
> don't want to see in a code that implements business logic any code
> that is related to protocols or data implementation technologies.
> Packing data to SOAP envelop or sendig data over IIOP is job of
> stubs and scaletons and main stream priogrammer should not ever cast
> object to classes related to those techologies. Based on the same
> principales, business programmer should not be avere that object
> he/she is dealing with is actually instance of some Hybernate proxy
> or SDO DataObject and should not ever cast those objects to
> mentioned classes unless he/she develops some tools or similar
> generic software.
> And I do not want to use any dynamic API if I don't have to, so I
> prefer to have typed Java API and SDO specification explicitally
> lists that support as one of the major requirements. So SDO should
> support static API defined by XSD schema.
> I think Java business programmer should be familiar with UML class
> diagrams that define domain and should get only corresponding POJOs
> to deal with. Code dealing with data transport or object
> distribution or data persistance, where BTW one technology is "cool"
> today and next day another one, should be hidden in adapters,
> skeletons and stubs.
>
> Next is complete XSD built automatically from attached UML.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> Attention: Generated code! Do not modify by hand!
> Generated by: XmlSchema.vsl in andromda-xmlschema-cartridge.
> -->
> <xsd:schema
> 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">
>
> <xsd:import namespace="commonj.sdo/xml"
schemaLocation="sdoXML.xsd"/>
>
> <xsd:complexType name="Address">
> <xsd:sequence>
> <xsd:element name="street" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="city" type="xsd:string" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="Customer">
> <xsd:sequence>
> <xsd:element name="orders" type="xsd:IDREF" sdoxml:
> propertyType="impl:SoH"
> sdoxml:oppositeProperty="customer" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="name" type="xsd:string" minOccurs="1"
> maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="Part">
> <xsd:sequence>
> <xsd:element name="uom" type="xsd:string" minOccurs="1"
> maxOccurs="1"/>
> <xsd:element name="aggState" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="Product">
> <xsd:complexContent>
> <xsd:extension base="impl:Part">
> <xsd:sequence>
> <xsd:element name="description" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> <xsd:complexType name="SoH">
> <xsd:sequence>
> <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> propertyType="impl:Customer"
> sdoxml:oppositeProperty="orders" minOccurs="1"
> maxOccurs="1" />
> <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="number" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="receivedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="SoL">
> <xsd:sequence>
> <xsd:element name="product" type="xsd:IDREF" sdoxml:
> propertyType="impl:Product"
> sdoxml:oppositeProperty="soLs" minOccurs="1"
maxOccurs="1" />
> <xsd:element name="soLineSch" type="impl:SoLSch"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="quantity" type="xsd:double"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="requestedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="SoLSch">
> <xsd:sequence>
> <xsd:element name="requestedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="quantity" type="xsd:double"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:element name="DataGraphRootEl" type="impl:DataGraphRoot"/>
> <xsd:complexType name="DataGraphRoot">
> <xsd:sequence>
> <xsd:element name="customer" type="impl:Customer"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="product" type="impl:Product"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="part" type="impl:Part" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="soH" type="impl:SoH" minOccurs="0"
> maxOccurs="unbounded" />
> </xsd:sequence>
> </xsd:complexType>
>
> </xsd:schema>
>
>
>
> Miro
>
>
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Mon 9/17/2007 7:49 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: XSD2JavaGenerator and non-containment references
>
> Miro,
>
> Both sides of a relationship defined with sdoXML:oppositeProperty need
to
> be non-containment references. All containment references are implicitly
> bidirectional (the reverse is the elements container), so you wouldn't
> really want to use an IDREF element anyway - it's just duplicate
> information.
>
> To get the SoH from an SoL, you can call:
>
> SoH soh = (SoH)sol.getContainer();
>
> You could manually add a getOrder() (convenience) method in the
generated
> class like this:
>
> SoH getOrder() { return (SoH)getContainer(): }
>
> EMF has a way to generate this kind of method for you, but there's no
> support for this in SDO.
>
> Frank.
>
> "Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/14/2007
08:40:40
> PM:
>
> > I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
> > generates code that cannot be compiled in case when container
> > element has non-containment reference to the container.
> > Entire xsd file is attched.
> > In this case I want to use static API and I want to get sales order
> > header (SoH) from its lines (SoL) using the same Java code (getter)
> > as in case when I use corresponding POJO's.
> > It works fine if property is non-containment reference to no
> > container class (SoL references product or SoH references Customer).
> >
> > I am a new in this community and I do not know if this is considered
> > as a bug who and how should open it. Please, advise.
> >
> > <xsd:complexType name="SoH">
> > <xsd:sequence>
> > <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Customer" sdoxml:oppositeProperty="soHs"
> > minOccurs="1" maxOccurs="1" />
> > <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="number" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="receivedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoL">
> > <xsd:sequence>
> > <xsd:element name="order" type="xsd:IDREF" sdoxml:
> > propertyType="impl:SoH" sdoxml:oppositeProperty="lines"
> > minOccurs="1" maxOccurs="1" />
> > <xsd:element name="product" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Product" sdoxml:oppositeProperty="soLs"
> > minOccurs="1" maxOccurs="1" />
> > <xsd:element name="soLineSch" type="impl:SoLSch"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="quantity" type="xsd:double"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="requestedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > Regards,
> > Miro
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: XSD2JavaGenerator and non-containment references
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Miro,
You are right. Bidirectional references are broken in Tuscany. They seem
to have been broken when we switched over to the new (noEMF) codegen
patterns. I guess nobody uses them much and we don't have a test case. Can
you please open a JIRA bug report to track this?
I understand your point about wanting a static (non SDO dependent) way to
navigate to the container. I think this is something that we should try to
change in the next version of SDO. Maybe something like this:
<xsd:element name="lines" type="impl:SoL"
sdojava:getContainer="getOrder" minOccurs="0" maxOccurs="unbounded" />
Maybe for now in Tuscany, we could just always generate a static method
for getContainer equal to "get" + <container type name>. For example, we
would generate:
SoH getSoH() { return (SoH)getContainer(); }
in class SoLImpl. This wouldn't be standard SDO, but a generator is
allowed to generate additional implementation-specific methods and still
be considered compliant.
Frank
"Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/17/2007 01:09:38
PM:
> Frank,
>
> actually XSD2JavaGenerator does not work in the case of any
> association type that is navigable from both sides.
> I have intentionally, just to test generator, made Customer-SoH
> association navigable from both sides and generated code again
> cannot be compiled.
>
> Regarding your comments on bidirectional references and
> containments, I know I can get container using dynamic SDO API but I
> don't want to see in a code that implements business logic any code
> that is related to protocols or data implementation technologies.
> Packing data to SOAP envelop or sendig data over IIOP is job of
> stubs and scaletons and main stream priogrammer should not ever cast
> object to classes related to those techologies. Based on the same
> principales, business programmer should not be avere that object
> he/she is dealing with is actually instance of some Hybernate proxy
> or SDO DataObject and should not ever cast those objects to
> mentioned classes unless he/she develops some tools or similar
> generic software.
> And I do not want to use any dynamic API if I don't have to, so I
> prefer to have typed Java API and SDO specification explicitally
> lists that support as one of the major requirements. So SDO should
> support static API defined by XSD schema.
> I think Java business programmer should be familiar with UML class
> diagrams that define domain and should get only corresponding POJOs
> to deal with. Code dealing with data transport or object
> distribution or data persistance, where BTW one technology is "cool"
> today and next day another one, should be hidden in adapters,
> skeletons and stubs.
>
> Next is complete XSD built automatically from attached UML.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> Attention: Generated code! Do not modify by hand!
> Generated by: XmlSchema.vsl in andromda-xmlschema-cartridge.
> -->
> <xsd:schema
> 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">
>
> <xsd:import namespace="commonj.sdo/xml"
schemaLocation="sdoXML.xsd"/>
>
> <xsd:complexType name="Address">
> <xsd:sequence>
> <xsd:element name="street" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="city" type="xsd:string" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="Customer">
> <xsd:sequence>
> <xsd:element name="orders" type="xsd:IDREF" sdoxml:
> propertyType="impl:SoH"
> sdoxml:oppositeProperty="customer" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="name" type="xsd:string" minOccurs="1"
> maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="Part">
> <xsd:sequence>
> <xsd:element name="uom" type="xsd:string" minOccurs="1"
> maxOccurs="1"/>
> <xsd:element name="aggState" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="Product">
> <xsd:complexContent>
> <xsd:extension base="impl:Part">
> <xsd:sequence>
> <xsd:element name="description" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> <xsd:complexType name="SoH">
> <xsd:sequence>
> <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> propertyType="impl:Customer"
> sdoxml:oppositeProperty="orders" minOccurs="1"
> maxOccurs="1" />
> <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="number" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="receivedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="SoL">
> <xsd:sequence>
> <xsd:element name="product" type="xsd:IDREF" sdoxml:
> propertyType="impl:Product"
> sdoxml:oppositeProperty="soLs" minOccurs="1"
maxOccurs="1" />
> <xsd:element name="soLineSch" type="impl:SoLSch"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="quantity" type="xsd:double"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="requestedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="SoLSch">
> <xsd:sequence>
> <xsd:element name="requestedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="quantity" type="xsd:double"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:element name="DataGraphRootEl" type="impl:DataGraphRoot"/>
> <xsd:complexType name="DataGraphRoot">
> <xsd:sequence>
> <xsd:element name="customer" type="impl:Customer"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="product" type="impl:Product"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="part" type="impl:Part" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="soH" type="impl:SoH" minOccurs="0"
> maxOccurs="unbounded" />
> </xsd:sequence>
> </xsd:complexType>
>
> </xsd:schema>
>
>
>
> Miro
>
>
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Mon 9/17/2007 7:49 AM
> To: tuscany-user@ws.apache.org
> Subject: Re: XSD2JavaGenerator and non-containment references
>
> Miro,
>
> Both sides of a relationship defined with sdoXML:oppositeProperty need
to
> be non-containment references. All containment references are implicitly
> bidirectional (the reverse is the elements container), so you wouldn't
> really want to use an IDREF element anyway - it's just duplicate
> information.
>
> To get the SoH from an SoL, you can call:
>
> SoH soh = (SoH)sol.getContainer();
>
> You could manually add a getOrder() (convenience) method in the
generated
> class like this:
>
> SoH getOrder() { return (SoH)getContainer(): }
>
> EMF has a way to generate this kind of method for you, but there's no
> support for this in SDO.
>
> Frank.
>
> "Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/14/2007
08:40:40
> PM:
>
> > I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
> > generates code that cannot be compiled in case when container
> > element has non-containment reference to the container.
> > Entire xsd file is attched.
> > In this case I want to use static API and I want to get sales order
> > header (SoH) from its lines (SoL) using the same Java code (getter)
> > as in case when I use corresponding POJO's.
> > It works fine if property is non-containment reference to no
> > container class (SoL references product or SoH references Customer).
> >
> > I am a new in this community and I do not know if this is considered
> > as a bug who and how should open it. Please, advise.
> >
> > <xsd:complexType name="SoH">
> > <xsd:sequence>
> > <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Customer" sdoxml:oppositeProperty="soHs"
> > minOccurs="1" maxOccurs="1" />
> > <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="number" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="receivedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoL">
> > <xsd:sequence>
> > <xsd:element name="order" type="xsd:IDREF" sdoxml:
> > propertyType="impl:SoH" sdoxml:oppositeProperty="lines"
> > minOccurs="1" maxOccurs="1" />
> > <xsd:element name="product" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Product" sdoxml:oppositeProperty="soLs"
> > minOccurs="1" maxOccurs="1" />
> > <xsd:element name="soLineSch" type="impl:SoLSch"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="quantity" type="xsd:double"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="requestedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > Regards,
> > Miro
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: XSD2JavaGenerator and non-containment references
Posted by "Miro Kandic (mkandic)" <mk...@cisco.com>.
Frank,
actually XSD2JavaGenerator does not work in the case of any association type that is navigable from both sides.
I have intentionally, just to test generator, made Customer-SoH association navigable from both sides and generated code again cannot be compiled.
Regarding your comments on bidirectional references and containments, I know I can get container using dynamic SDO API but I don't want to see in a code that implements business logic any code that is related to protocols or data implementation technologies.
Packing data to SOAP envelop or sendig data over IIOP is job of stubs and scaletons and main stream priogrammer should not ever cast object to classes related to those techologies. Based on the same principales, business programmer should not be avere that object he/she is dealing with is actually instance of some Hybernate proxy or SDO DataObject and should not ever cast those objects to mentioned classes unless he/she develops some tools or similar generic software.
And I do not want to use any dynamic API if I don't have to, so I prefer to have typed Java API and SDO specification explicitally lists that support as one of the major requirements. So SDO should support static API defined by XSD schema.
I think Java business programmer should be familiar with UML class diagrams that define domain and should get only corresponding POJOs to deal with. Code dealing with data transport or object distribution or data persistance, where BTW one technology is "cool" today and next day another one, should be hidden in adapters, skeletons and stubs.
Next is complete XSD built automatically from attached UML.
<?xml version="1.0" encoding="UTF-8"?>
<!--
Attention: Generated code! Do not modify by hand!
Generated by: XmlSchema.vsl in andromda-xmlschema-cartridge.
-->
<xsd:schema
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">
<xsd:import namespace="commonj.sdo/xml" schemaLocation="sdoXML.xsd"/>
<xsd:complexType name="Address">
<xsd:sequence>
<xsd:element name="street" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="city" type="xsd:string" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:complexType name="Customer">
<xsd:sequence>
<xsd:element name="orders" type="xsd:IDREF" sdoxml:propertyType="impl:SoH"
sdoxml:oppositeProperty="customer" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="name" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:complexType name="Part">
<xsd:sequence>
<xsd:element name="uom" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="aggState" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:complexType name="Product">
<xsd:complexContent>
<xsd:extension base="impl:Part">
<xsd:sequence>
<xsd:element name="description" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SoH">
<xsd:sequence>
<xsd:element name="customer" type="xsd:IDREF" sdoxml:propertyType="impl:Customer"
sdoxml:oppositeProperty="orders" minOccurs="1" maxOccurs="1" />
<xsd:element name="lines" type="impl:SoL" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="number" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="receivedDate" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:complexType name="SoL">
<xsd:sequence>
<xsd:element name="product" type="xsd:IDREF" sdoxml:propertyType="impl:Product"
sdoxml:oppositeProperty="soLs" minOccurs="1" maxOccurs="1" />
<xsd:element name="soLineSch" type="impl:SoLSch" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="quantity" type="xsd:double" minOccurs="1" maxOccurs="1"/>
<xsd:element name="requestedDate" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:complexType name="SoLSch">
<xsd:sequence>
<xsd:element name="requestedDate" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="quantity" type="xsd:double" minOccurs="1" maxOccurs="1"/>
<xsd:element name="modifiedBy" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="lastUpdated" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/>
<xsd:element name="created" type="xsd:date" minOccurs="1" maxOccurs="1"/>
<xsd:element name="id" type="xsd:long" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="xmlId" type="xsd:ID"/>
</xsd:complexType>
<xsd:element name="DataGraphRootEl" type="impl:DataGraphRoot"/>
<xsd:complexType name="DataGraphRoot">
<xsd:sequence>
<xsd:element name="customer" type="impl:Customer" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="product" type="impl:Product" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="part" type="impl:Part" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="soH" type="impl:SoH" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Miro
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Mon 9/17/2007 7:49 AM
To: tuscany-user@ws.apache.org
Subject: Re: XSD2JavaGenerator and non-containment references
Miro,
Both sides of a relationship defined with sdoXML:oppositeProperty need to
be non-containment references. All containment references are implicitly
bidirectional (the reverse is the elements container), so you wouldn't
really want to use an IDREF element anyway - it's just duplicate
information.
To get the SoH from an SoL, you can call:
SoH soh = (SoH)sol.getContainer();
You could manually add a getOrder() (convenience) method in the generated
class like this:
SoH getOrder() { return (SoH)getContainer(): }
EMF has a way to generate this kind of method for you, but there's no
support for this in SDO.
Frank.
"Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/14/2007 08:40:40
PM:
> I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
> generates code that cannot be compiled in case when container
> element has non-containment reference to the container.
> Entire xsd file is attched.
> In this case I want to use static API and I want to get sales order
> header (SoH) from its lines (SoL) using the same Java code (getter)
> as in case when I use corresponding POJO's.
> It works fine if property is non-containment reference to no
> container class (SoL references product or SoH references Customer).
>
> I am a new in this community and I do not know if this is considered
> as a bug who and how should open it. Please, advise.
>
> <xsd:complexType name="SoH">
> <xsd:sequence>
> <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> propertyType="impl:Customer" sdoxml:oppositeProperty="soHs"
> minOccurs="1" maxOccurs="1" />
> <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="number" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="receivedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="SoL">
> <xsd:sequence>
> <xsd:element name="order" type="xsd:IDREF" sdoxml:
> propertyType="impl:SoH" sdoxml:oppositeProperty="lines"
> minOccurs="1" maxOccurs="1" />
> <xsd:element name="product" type="xsd:IDREF" sdoxml:
> propertyType="impl:Product" sdoxml:oppositeProperty="soLs"
> minOccurs="1" maxOccurs="1" />
> <xsd:element name="soLineSch" type="impl:SoLSch"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="quantity" type="xsd:double"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="requestedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> Regards,
> Miro
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: XSD2JavaGenerator and non-containment references
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Miro,
Both sides of a relationship defined with sdoXML:oppositeProperty need to
be non-containment references. All containment references are implicitly
bidirectional (the reverse is the elements container), so you wouldn't
really want to use an IDREF element anyway - it's just duplicate
information.
To get the SoH from an SoL, you can call:
SoH soh = (SoH)sol.getContainer();
You could manually add a getOrder() (convenience) method in the generated
class like this:
SoH getOrder() { return (SoH)getContainer(): }
EMF has a way to generate this kind of method for you, but there's no
support for this in SDO.
Frank.
"Miro Kandic \(mkandic\)" <mk...@cisco.com> wrote on 09/14/2007 08:40:40
PM:
> I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
> generates code that cannot be compiled in case when container
> element has non-containment reference to the container.
> Entire xsd file is attched.
> In this case I want to use static API and I want to get sales order
> header (SoH) from its lines (SoL) using the same Java code (getter)
> as in case when I use corresponding POJO's.
> It works fine if property is non-containment reference to no
> container class (SoL references product or SoH references Customer).
>
> I am a new in this community and I do not know if this is considered
> as a bug who and how should open it. Please, advise.
>
> <xsd:complexType name="SoH">
> <xsd:sequence>
> <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> propertyType="impl:Customer" sdoxml:oppositeProperty="soHs"
> minOccurs="1" maxOccurs="1" />
> <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> maxOccurs="unbounded" />
> <xsd:element name="number" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="receivedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> <xsd:complexType name="SoL">
> <xsd:sequence>
> <xsd:element name="order" type="xsd:IDREF" sdoxml:
> propertyType="impl:SoH" sdoxml:oppositeProperty="lines"
> minOccurs="1" maxOccurs="1" />
> <xsd:element name="product" type="xsd:IDREF" sdoxml:
> propertyType="impl:Product" sdoxml:oppositeProperty="soLs"
> minOccurs="1" maxOccurs="1" />
> <xsd:element name="soLineSch" type="impl:SoLSch"
> minOccurs="0" maxOccurs="unbounded" />
> <xsd:element name="quantity" type="xsd:double"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="requestedDate" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="modifiedBy" type="xsd:string"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="lastUpdated" type="xsd:dateTime"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="created" type="xsd:date"
> minOccurs="1" maxOccurs="1"/>
> <xsd:element name="id" type="xsd:long" minOccurs="1"
> maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attribute name="xmlId" type="xsd:ID"/>
> </xsd:complexType>
>
> Regards,
> Miro
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org