Done: http://jira.codehaus.org/browse/CASTOR-2209
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);
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);
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):
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
>
>
>
--
View this message in context:
http://www.nabble.com/unmarshal%28%29-method-for-named-element-with-%27type%27-attribute-tf4681201.html#a13409166
Sent from the Castor - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
