Hi K wrote: > Problem solved. Thanks for you help. I've implemented a number of large scale ERP integration projects with castor. I'd be interested to learn a bit more about your usage of Castor, so that we (the team) can finally go about putting together a 'user experience' page.
Would that be an option to you ? Werner > Great work by the castor team. Thank you ... > > 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, 10:40 AM > > Hi, > > K wrote: >> 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). > With 1.2, you can also use the following synatx: > > <elementBinding name="/complexType:A_Type/B"> > <java-class name="YYYY"/> > </elementBinding> > >> May want to consider adding another choice >> containing the existing choice and a sequence of the optional binding >> elements? > Yes, we could (or find even a better solution). Can you please raise a > Jira issue asking us to go about this ? > > Can I now assume that you have completely resolved your problem ? > >> 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 >> >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > 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
