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
