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
