Sigh. I'm confused. I'm certain I had already tried that, and it didn't make any difference. I must have done something wrong, because now it appears to be working.
> -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Monday, February 19, 2007 1:31 AM > To: [email protected] > Subject: Re: [castor-user] How to deal with extending types in 1.1 > > David, > > you are doing the right thing by providing a binding file, > but the <elementBinding>s for the 'Fault' elements need to be ... > > <elementBinding name="/complexType:GeneralLoanInfoResponseType/Fault"> > <java-class name="GeneralLoanInfoResponseFault"/> > </elementBinding> > > <elementBinding name="/complexType:AddNoteResponseType/Fault"> > <java-class name="AddNoteResponseFault"/> </elementBinding> > > Please note the leading '/' before the 'complexType:' prefix. > > I hope this makes things a bit clearer. The relevant HTML > pages have been fixed in SVN trunk already, and will be made > available as part of > 1.1.1 (latest). If there's no other changes that interfere > with this, I guess I will be uploading the relevant pages > again to http://www.castor.org. > > Werner > > Karr, David wrote: > > I already tried prepending "/" to the name. No difference. > > > >> -----Original Message----- > >> From: Ralf Joachim [mailto:[EMAIL PROTECTED] > >> Sent: Sunday, February 18, 2007 3:11 PM > >> To: [email protected] > >> Subject: Re: [castor-user] How to deal with extending types in 1.1 > >> > >> David, > >> > >> as far as I know there has been a change in binding syntax that > >> requires that the name of the elementBinding starts with > /. It seams > >> that this still is not correctly documented. > >> > >> Another alternative for you would be to use the latest snapshot > >> release of castor as Werner has added a automatic conflict > resolution > >> recently. > >> For more information you have to wait on a comment from > Werner as I > >> am not familiar with that. > >> > >> Sorry for any inconvenience > >> Ralf > >> > >> > >> Karr, David schrieb: > >>> Before I file a case, could I just provide more info here, > >> and perhaps > >>> we'll be able to get through this? > >>> > >>> With my Ant task test case, and looking at warnings, I see > >> that I have > >>> numerous situations in my schemas like this: > >>> > >>> <xs:complexType name="GeneralLoanInfoResponseType"> > >>> <xs:sequence> > >>> <xs:element name="Fault" type="FaultType" > >>> minOccurs="0" maxOccurs="unbounded"/> > >>> <xs:element name="AccountInformation" > >>> type="AccountInformationType" minOccurs="0"/> > >>> <xs:element name="GeneralLoanInfo" > >>> type="GeneralLoanInfoType" minOccurs="0"/> > >>> </xs:sequence> > >>> </xs:complexType> > >>> <xs:complexType name="AddNoteResponseType"> > >>> <xs:sequence> > >>> <xs:element name="Fault" type="FaultType" > >>> minOccurs="0" maxOccurs="unbounded"/> > >>> <xs:element name="AccountInformation" > >>> type="AccountInformationType" minOccurs="0"/> > >>> </xs:sequence> > >>> </xs:complexType> > >>> > >>> Which produces warnings like this: > >>> > >>> Warning: A class name generation conflict has occured > >> between element > >>> '/complexType:GeneralLoanInfoResponseType/Fault' and element > >>> '/complexType:AddNoteResponseType/Fault' > >>> > >>> So, to handle this, I figured I would need a binding file > like this: > >>> > >>> <binding xmlns="http://www.castor.org/SourceGenerator/Binding"; > >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > >>> <elementBinding > >> name="complexType:GeneralLoanInfoResponseType/Fault"> > >>> <java-class name="GeneralLoanInfoResponseFault"/> > >>> </elementBinding> > >>> <elementBinding name="complexType:AddNoteResponseType/Fault"> > >>> <java-class name="AddNoteResponseFault"/> </elementBinding> > >>> </binding> > >>> > >>> Unfortunately, this had no effect (I verified the process > >> is reading > >>> the binding.xml file). It still gives me the exact same > >> warning. I > >>> imagine I have something slightly off in the xpath of my "name" > >>> attribute, but I'm not sure what it would be. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Werner Guttmann [mailto:[EMAIL PROTECTED] > >>>> Sent: Sunday, February 18, 2007 7:24 AM > >>>> To: [email protected] > >>>> Subject: Re: [castor-user] How to deal with extending > types in 1.1 > >>>> > >>>> Not sure whether you'd need a binding file (or not, as > there's not > >>>> enough information to make an educated guess). As such, can > >> I please > >>>> ask you to create a Jira issue at > >>>> > >>>> http://jira.codehaus.org/browse/CASTOR > >>>> > >>>> and I'll be back with more than a wild guess in due time. > >>>> > >>>> Werner > >>>> > >>>> Karr, David wrote: > >>>> > >>>>> I asked about this last month, but I wasn't committed to > >>>> resolving it > >>>> > >>>>> then. > >>>>> > >>>>> I'm porting from 0.9.6 to 1.1, and after resolving other > >>>> setup issues, > >>>> > >>>>> I see the following compile error (this is the first one), > >>>>> somewhat > >>>>> paraphrased: > >>>>> > >>>>> .../BorrowerType.java:97: unmarshal(java.io.Reader) in > >>>> ...BorrowerType > >>>> > >>>>> cannot override unmarshal(java.io.Reader) in ...CustomerType; > >>>>> attempting to use incompatible return type > >>>>> found : ...BorrowerType > >>>>> required: ...CustomerType > >>>>> public static ...BorrowerType unmarshal( > >>>>> > >>>>> An excerpt from the relevent schema (consumertypes.xsd) > >>>> looks like this: > >>>> > >>>>> <xs:complexType name="BorrowerType"> > >>>>> <xs:complexContent> > >>>>> <xs:extension base="crm:CustomerType"/> > >>>>> </xs:complexContent> > >>>>> </xs:complexType> > >>>>> > >>>>> Note that there are three schemas, "consumer.xsd", > >>>>> "consumertypes.xsd", and "consumercrmtypes.xsd". The first one > >>>>> includes the second one, and imports the third one. In our > >>>>> "maven.xml", we generate the source corresponding to all 3 > >>>> of these schemas. > >>>> > >>>>> I imagine I probably have to build a bindings file to deal > >>>> with this, > >>>> > >>>>> but I'm not sure what it needs to do. > >>>>> > >>>>> > >>>> ------------------------------------------------------------ > >> --------- > >>>>> 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 > >> > --------------------------------------------------------------------- > >> 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 > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
