No worries. Werner
Karr, David wrote: > 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 > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
