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
