Thanks.
Werner
aslam wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
