|
»
»
»
Possible 1.2 codegen bug...
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Possible 1.2 codegen bug...
by K-14
::
Rate this Message:
|
|||
|
|
Re: Possible 1.2 codegen bug...
by Werner Guttmann
::
Rate this Message:
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 |
|||
|
|
Re: Possible 1.2 codegen bug...
by K-14
::
Rate this Message:
|
|||
|
|
Re: Possible 1.2 codegen bug...
by K-14
::
Rate this Message:
|
|||
|
|
Re: Possible 1.2 codegen bug...
by K-14
::
Rate this Message:
|
|||
|
|
Re: Possible 1.2 codegen bug...
by Werner Guttmann
::
Rate this Message:
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). <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 <i8mostofit@...> wrote: > From: K <i8mostofit@...> > Subject: Re: [castor-user] Possible 1.2 codegen bug... > To: user@... > 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 <i8mostofit@...> wrote: > From: K <i8mostofit@...> > Subject: Re: [castor-user] Possible 1.2 codegen bug... > To: user@... > 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 <werner.guttmann@...> wrote: > From: Werner Guttmann <werner.guttmann@...> > Subject: Re: [castor-user] Possible 1.2 codegen bug... > To: user@... > 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 |
|||
|
|
Re: Possible 1.2 codegen bug...
by K-14
::
Rate this Message:
|
|||
|
|
Re: Possible 1.2 codegen bug...
by Werner Guttmann
::
Rate this Message:
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 <werner.guttmann@...> wrote: > From: Werner Guttmann <werner.guttmann@...> > Subject: Re: [castor-user] Possible 1.2 codegen bug... > To: user@... > 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 <i8mostofit@...> wrote: >> From: K <i8mostofit@...> >> Subject: Re: [castor-user] Possible 1.2 codegen bug... >> To: user@... >> 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 <i8mostofit@...> wrote: >> From: K <i8mostofit@...> >> Subject: Re: [castor-user] Possible 1.2 codegen bug... >> To: user@... >> 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 <werner.guttmann@...> > wrote: >> From: Werner Guttmann <werner.guttmann@...> >> Subject: Re: [castor-user] Possible 1.2 codegen bug... >> To: user@... >> 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 |
| Free Forum Powered by Nabble | Forum Help |