Hi Alex,
you got a point there, to be honest. On the other side, as with any
mapping tool (persistence, xml, ...) there is always going to be a
mapping gap.
Werner
On 19.10.2011 17:09, Alex Milanovic wrote:
Hi Werner,
Yes I am using the element mode. Are there any caveats with the type mode when
it comes to (un)marshalling? For example, if I have to unmarshal a global
element (e.g. ElemA) will Castor be able to identify the Java class that
corresponds to the global element's complex type (TypeA)? Or, if I want to
marshal the class that corresponds to the global element's complex type (TypeA)
how will Castor know the XML tag (ElemA) given that the element information
would not be captured in the complex type's class?
Thanks,
Alex
-----Original Message-----
From: Werner Guttmann [mailto:[email protected]]
Sent: Wednesday, October 19, 2011 12:42 AM
To: [email protected]
Cc: Alex Milanovic; Adrien schiehle
Subject: Re: [castor-user] substitutionGroup and Source Generator
Hi Alex,
On 18.10.2011 19:51, Alex Milanovic wrote:
Werner,
I am facing the same issue described in the link below
(http://www.mail-archive.com/[email protected]/msg07657.html) with Castor
1.3.2 and the 'element' method. Please note this is not about naming conflicts
but about the fact that Castor SourceGenerator generates Java classes that
don't translate well the XML element substitutability to Java.
For example, assume we have the following XSD definitions:
TypeB extends TypeA
ElemA is of type TypeA
ElemB is of type TypeB, substitutes elemA
In XML documents ElemB can substitute ElemA but in the Java code
generated by Castor the ElemB class does not inherit from ElemA class
and therefore there is no substitutability there. Here's an example
where substitutability matters. Suppose ElemParent can have ElemA as a
child element:
Hmm, are you by chance using element mode when generating the Java classes ?
If yes, please try to switch to type mode as this clearly makes a difference in
the context of this.
Kind Regards
Werner
ElemParent
ElemA
SourceGenerator creates a Java class that specifies ElemA as the type of elemA.
Now, because ElemB does not inherit from ElemA the member _elemA cannot have a
value of type ElemB, which essentially kills the substitutability in Java.
Class ElemParent
ElemA _elemA;
Could SourceGenerator be changed to product the following?
Class ElemParent
TypeA _elemA;
In this case, the class member _elemA can have a value of type ElemB because
ElemB inherits from TypeB, which in turn inherits from TypeA. I tried enforcing
this type in the bindings as illustrated below but it didn't work.
<elementBinding name="/complexType:ElemParentType/ElemA">
<member name="ElemA" java-type="somepackage.TypeA"/>
</elementBinding>
I looked at the documentation of SourceGenerator and the Castor Reference Guide
but didn't find a way to work around this problem. Should I open a bug/CR
report?
Thanks
Alex
-----Original Message-----
From: Werner Guttmann [mailto:[email protected]]
Sent: Friday, December 17, 2010 12:27 AM
To: [email protected]
Cc: Adrien schiehle
Subject: Re: [castor-user] substitutionGroup and Source Generator
No, it does. And there's actually quite a lot of information about this and
(possible) naming conflict problems and how to go about resolving those during
source generation in the reference guide.
Just out of curiosity, what version of Castor are you trying to use ?
Regards
Werner
On 17.12.2010 06:54, Adrien schiehle wrote:
Hi,
I'm having issue with substitutionGroup and Source Generator.
My problem is the same as Michael Wang in his mail :
http://www.mail-archive.com/[email protected]/msg07657.html
( [castor-dev] About generated java codes to support
substitutionGroup
)
The mail was sent Monday, June
03, 2002
Arnaud Blandin answered him that the Source Generator doesn't support
substitutionGroup. Is it still the case?
Thanks in advance,
Adrien SCHIEHLE.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
