Greetings!
I find the following problem regarding the sourceGen
generated code using Castor XML and the way
unmarshaller handles xsi:type information. This is
regarding Castor 0.9.5.3. It is a bit long, so I
appreciate your patience of reading it. I didn't find
the appropriate bug report facility and don't know
whether this is a known problem.
For a schema segment like the following:
<xsd:complexType name="RequestType">
<xsd:sequence>
...
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Request" type="RequestType"/>
When using Castor XML sourceGen with "element" option,
i.e. in the castorbuilder.properties, I have:
# Java class mapping of <xsd:element>'s and
<xsd:complexType>'s
#
org.exolab.castor.builder.javaclassmapping=element
Two classes will be generated:
class Request extends RequestType
abstract class RequestType
Corresponding XXXXDescriptor classes are also
generated.
Here is the way I am using the unmarshaller to
destabilize a document into a Request object:
Unmarshaller um = new Unmarshaller(Request.class);
Request obj = (Request) um.unmarshal(doc);
doc represents a org.w3c.Element from an XML document.
This works fine for documents without xsi:type set,
however, for a document like the following, it failed
miserably:
<Request xsi:type="RequestType" ...>
...
</Request>
I dug around Castor source code and found out
something I would consider a bug. In
org.exolab.castor.UnmarshalHandler, it seems that even
if the "_topClass" is present (via the call "new
Unmarshaller(Request.class)"), UnmarshalHandler still
tries to deserialize the document element into what
xsi:type specifies if xsi:type is found and a class
(through XXXXDescriptor) can be found. The are three
things that I think are wrong:
1. The logic in the current code will instantiate an
instance of the type class, which is generated as
an
abstract class by sourceGen.
2. Even if an instance of the xsi:type class can be
instantiated, it will not pass the type
compatibility test: since the class requested by
the
client code is "Request",
and UnmarshalHandler is to make sure the actual
instance it is going to return is a type of
"Request". And RequestType is not (backward!).
3. If no "type" class can be found using xsi:type,
e.g., a bogus xis:type specified, UnmarshalHandler
will ignore the xsi:type all together.
In short, I think the way Castor XML generates code
about xsi:type and handles deserialization are flawed.
Here is what I think that could help the situation:
A. Have sourceGen (when generating using "element"
option) generate "xsi:type" information for the
"element" class descriptor (currently it keeps
track
of xmlName, but not xmlType). The xsi:type
information for abstract type class'descriptor can
be ignored.
B. In UnmarshalHandler, if the _topClass is specified,
i.e., when the client code knows what class it need
to unmarshal to, do a check if xsi:type is present
in the document element, to make sure it matches
the
type information of the class descriptor specifies.
If it doesn't match, either warn
the user (if validation is turned off, e.g.) or
fail
as unmarshalling error.
Again, if this is a known problem, I apologize for
this long posting. If not, I'd appreciate feedback
from Castor developers.
Thanks,
j.t.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
