Yes, the signature of the unmarshal() method(s) generated has changed (back to what's been with really old releases of Castor). Iow, we like compile time checks ...
Werner Karr, David wrote: > I'm not certain, but I think when we were using v0.9.6, the transparent > overwrite didn't matter much, because the classes would have been > identical. However, it appears that in v1.0.5, the return type of the > "unmarshal()" method has changed from java.lang.Object to the actual > type. This fact by itself wouldn't matter, but I actually simplified > the schema example provided here. The second Borrower element's type > was actually "crm:CustomerType", instead of BorrowerType. As a result, > when I ran the build with v1.0.5, the "unmarshal()" methods of > CustomerType and its subclass, BorrowerType, were not compatible. > >> -----Original Message----- >> From: Werner Guttmann [mailto:[EMAIL PROTECTED] >> Sent: Monday, January 15, 2007 1:46 PM >> To: [email protected] >> Subject: Re: [castor-user] Does Castor try to generate >> different classes for same-named elements using the same type? >> >> David, >> >> you actually did, but only if you looked closely enough. In 'older' >> versions of Castor, classes simply got overwritten without >> any warnings (or very restricted warnings, especially when >> turning warnings off). >> >> We are about to change the current behaviour slightly, by >> >> a) adding more information about what's going on (as you have >> noted yourself). >> b) improving the code base with regards to such 'naming >> collisions', as in many (but not all cases) we could offer >> various strategies to implement a collision resolution. >> >> Having said that, that's still some weeks (if not months) >> away, so for the time being, I'd advise you to use a binding >> file. And imho it does not really relate to Java per se, as >> it mainly allows you to define things like class names, >> member names et alias. >> >> Personally, I would never change an XML schema (if possible) >> to allow a tool (such as Castor is) to be able to work with >> it properly. >> >> Werner >> >> Karr, David wrote: >>> In my comparison of results from v0.9.6 and v1.0.5, it seems like >>> Castor complains about situations like this: >>> >>> ------------- >>> <xs:complexType name="BorrowerType"> >>> <xs:complexContent> >>> <xs:extension base="crm:CustomerType"/> >>> </xs:complexContent> >>> </xs:complexType> >>> <xs:complexType name="OwnersType"> >>> <xs:sequence> >>> <xs:element name="Borrower" type="BorrowerType" >>> minOccurs="0"/> >>> </xs:sequence> >>> </xs:complexType> >>> <xs:complexType name="DocumentType"> >>> <xs:sequence> >>> <xs:element name="Borrower" type="BorrowerType" >>> minOccurs="0"/> >>> </xs:sequence> >>> </xs:complexType> >>> ------------- >>> >>> Warning: A class name generation conflict has occured >> between element >>> 'complexType:OwnersType/Borrower' and element >>> 'complexType:DocumentType/Borrower' >>> >>> I don't think we saw this problem with v0.9.6. >>> >>> Logically, it seems like I could fix this in two different ways: >>> >>> * Use a binding file to specify different classes for >>> OwnersTypeBorrower and DocumentTypeBorrower. >>> * Declare Borrower as a standalone element and use "ref" in each of >>> these two elements. >>> >>> I'd say either of these choices have tradeoffs. The first >> has a bit >>> of a Java smell, and the second a bit of schema smell. >>> >>> What do you think? >>> >>> >> --------------------------------------------------------------------- >>> 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
