I agree that the return type of Object is too broad. It was the typecast that
I wanted to draw attention to. However, it's likely that the typecast
(before returning) isn't a problem, as long as the actual object returned is
of the correct (sub)type.
I did track a ClassCastException down to a setValue() method of a handler in
a supertype descriptor. I'll post the details when I have them.
--aslam
Werner Guttmann wrote:
>
> Aslam,
>
>> 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
>
>
--
View this message in context:
http://www.nabble.com/unmarshal%28%29-method-for-named-element-with-%27type%27-attribute-tf4681201.html#a13433014
Sent from the Castor - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
