Aslam,
aslam wrote:
Done: http://jira.codehaus.org/browse/CASTOR-2209
Thanks.
Also added the following comment:
Even with JDK 1.4, shouldn't the type cast in the return statement be to the
subtype? Like so:
return (com.ak.castor.AKConfig)
Unmarshaller.unmarshal(com.ak.castor.AKConfig.class, reader);
That would not compile with Java 1.4, even though its a static method.
Looks like Java changed with Java 5.0.
I think the typecast to the supertype (AKConfigType) would cause a statement
like the following to throw a ClassCastException:
AKConfig akConfig = (AKConfig) AKConfig.unmarshal(akConfigReader);
Not sure. But I have not seen anybody complain about this yet. But I
will use your test case to double-check this.
This is what might be causing our old code to break, I'm still not entirely
sure. Incidentally, this is what the unmarshal() method generated with
Castor 0.9.* looks like (note the typecast):
As far as I remember, there were several Jira requests to change this
code as returning java.lang.Object was too wide in terms of type
staticness.
If there's demand, I think we could introduce a property to
(selectively) restore the old behavior, though I'd rather avoid that.
public static java.lang.Object unmarshal(java.io.Reader reader)
throws org.exolab.castor.xml.MarshalException,
org.exolab.castor.xml.ValidationException
{
return (com.ak.castor..AKConfig)
Unmarshaller.unmarshal(com.ak.castor.AKConfig.class, reader);
}
--aslam
Werner Guttmann wrote:
Actually, I just learned myself that what I have said is valid for Java
1.4 and below only. With java 5.0 and baove, this will be possible.
As such, can you please create a new Jira issue, asking us to support
this.
Regards
Werner
aslam wrote:
Here's an example, with generated code snippets:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; version="1.0.0">
<xsd:element name="AKConfig" type="AKConfigType">
<xsd:annotation>
<xsd:documentation>AK Config</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="AKConfigType">
<xsd:sequence>
<xsd:element name="handler" type="xsd:string" />
<xsd:element name="timeout" type="xsd:int" />
<xsd:element name="allowMultiplePartsPerCnxn"
type="xsd:boolean"
default="false" />
<xsd:element name="CategoryList" type="CategoryListType"
/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CategoryListType">
<xsd:sequence>
<xsd:element name="CnxnCategory" type="CategoryType"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CategoryType">
<xsd:attribute name="value" type="xsd:string" use="required" />
<xsd:attribute name="MaxConnectionsAllowed" type="xsd:int"
use="optional"
default="1" />
</xsd:complexType>
</xsd:schema>
In the generated AKConfig.java, the unmarshal() method is:
public static com.ak.castor.AKConfigType unmarshal(
final java.io.Reader reader)
throws org.exolab.castor.xml.MarshalException,
org.exolab.castor.xml.ValidationException {
return (com.ak.castor.AKConfigType)
Unmarshaller.unmarshal(com.ak.castor.AKConfig.class, reader);
}
Why does this method return AKConfigType, and not AKConfig?
--aslam
a k'wala wrote:
If my schema has the following:
<xsd:element name="myElem" type="ElemType" />
<xsd:complexType name="ElemType">
...
</xsd:complexType>
The unmarshal() methods generated for MyElem and ElemType, both, return
type ElemType. Is there a way to have the one for MyElem return type
MyElem?
Background: I'm updating from Castor 0.9.* to the latest, and am getting
ClassCastExceptions with the existing code, which wants the return type
of
unmarshal() to be that corresponding to the element name (MyElem), not
its
superclass (ElemType).
---------------------------------------------------------------------
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
