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
