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\) [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: XSD2JavaGenerator and non-containment references
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:[EMAIL PROTECTED]
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\) [EMAIL PROTECTED] 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
RE: XSD2JavaGenerator and non-containment references
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:[EMAIL PROTECTED]
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\) [EMAIL PROTECTED] 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
RE: XSD2JavaGenerator and non-containment references
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\) [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
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\) [EMAIL PROTECTED] 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
