Appologies in advance for the clutter. I got this to work with the following:
<complexTypeBinding name="A_Type"> <java-class name="A_Type"/> <elementBinding name="/B"> <java-class name="YYYY"/> </elementBinding> </complexTypeBinding> http://www.castor.org/binding.xsd defines componentBindingType with a choice and optional sub-binding elements. Adding something from the choice in the top level binding makes it work (even though its just a dummy class assignment). May want to consider adding another choice containing the existing choice and a sequence of the optional binding elements? Thanks for your help, Keith --- On Wed, 7/16/08, K <[EMAIL PROTECTED]> wrote: From: K <[EMAIL PROTECTED]> Subject: Re: [castor-user] Possible 1.2 codegen bug... To: [email protected] Date: Wednesday, July 16, 2008, 6:51 AM Just a followup. The below complexTypeBinding fails in 1.2 with the same error. Forgive me if I'm missing something obvious. Keith --- On Wed, 7/16/08, K <[EMAIL PROTECTED]> wrote: From: K <[EMAIL PROTECTED]> Subject: Re: [castor-user] Possible 1.2 codegen bug... To: [email protected] Date: Wednesday, July 16, 2008, 6:36 AM My mistake. Many thanks for your help. The correct binding reference is "/complexType:A_Type/B" However, I'm triing to work out a solution for a legacy system using 1.0.2 and the above reference does not work in 1.0.2. using the following instead: <complexTypeBinding name="A_Type"> <elementBinding name="B"> <java-class name="YYYY"/> </elementBinding> </complexTypeBinding> results in: The following exception occured while validating field: _complexTypeBindingList of class: org.exolab.castor.builder.binding.Binding: The field '_componentBindingTypeChoice' is a required field of class 'org.exolab.castor.builder.binding.ComponentBindingType I know this is a legacy version but upgrading is not possible. Just need documentation on componentBindingTypeChoice - its not in the 1.0.2 docs. many thanks, Keith --- On Wed, 7/16/08, Werner Guttmann <[EMAIL PROTECTED]> wrote: From: Werner Guttmann <[EMAIL PROTECTED]> Subject: Re: [castor-user] Possible 1.2 codegen bug... To: [email protected] Date: Wednesday, July 16, 2008, 2:30 AM Hi, it is no suprise to me that things work partially only. Here's why. The binding definition <elementBinding name="/C"> <java-class name="ZZZZ"/> </elementBinding> defines a a new Java class name for the Java class generated from the global element definition <xsd:element name="C"> ... </xsd:element> So far, so fine. But for the second binding definition, there's no corresponding global element definition with the name 'B'. In other words, this will never work. Having said that, what artifact should be affected by the second binding at all ? Regards Werner K wrote: > Just checking to see if this is a bug. Using codegen with 1.2, I cannot map an element in certain cases (all other cases I've tried work fine). Any help would be appreciated. > > ** given an xsd that defines B and C in A: > > <xsd:element name="A" type="A_Type"/> > <xsd:complexType name="A_Type"> > <xsd:sequence> > <xsd:element name="B" type="B_Type"/> > <xsd:element ref="C"/> > </xsd:sequence> > </xsd:complexType> > <xsd:complexType name="B_Type"> > <xsd:sequence> > <xsd:element name="D" type="xsd:string"/> > </xsd:sequence> > </xsd:complexType> > <xsd:element name="C"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="E" type="xsd:string"/> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > > > > ** and a binding file of: > > <elementBinding name="/B"> > <java-class name="YYYY"/> > </elementBinding> > > <elementBinding name="/C"> > <java-class name="ZZZZ"/> > </elementBinding> > > > ** B is not changed to YYYY but C is changed to ZZZZ > > Thanks, > Keith > > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
