users@jaxb.java.net

Re: Unmarshalling problem due to xsi:type attribute value

From: Wolfgang Laun <wolfgang.laun_at_gmail.com>
Date: Fri, 25 May 2012 20:36:54 +0200

You do understand the problem, so I don't have to discuss in much detail
that attaching a type name as an attribute is something that depends on
sender and receiver agreeing on their joint understanding and interpretation
of this attribute. If the receiving web service doesn't care about the type,
the second transmission with swapped sender and receiver falls short
of this convention being maintained.

Perhaps you can modify all participating programs to send the type as
a separate element (or as a child to payload), also to be copied by the
service. Then, the code interpreting the answer would have an
indication of the type. That's not to be achieved automatically.

-W


On 25/05/2012, flemingt_at_finra.org <flemingt_at_finra.org> wrote:
> I have a schema that defines an element ("payload") as "anyType". My
> code generator defines the property as type Object as it should. When
> I marshal the message JAXB creates XML along the lines of the
> following:
>
> <ns2:MessageToAccept
> xmlns:ns2="http://soa.finra.org/member/common/ESBToWebServiceClientV02/
> " xmlns:ns4="http://soa.finra.org/ufi/ufi-commandV01"
> xmlns:ns3="http://soa.finra.org/ufi/ufi-responseV01"
> xmlns:ns5="http://soa.finra.org/member/common/common-messagesV01">
> <ns4:ufiCommand>
> <payload xsi:type="ns4:UfiCommandPayload"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> ...
> </payload>
> </ns4:ufiCommand>
> </ns2:MessageToAccept>
>
> Note that the "payload" element has the xsi:type attribute with a value
> of "ns4:UfiCommandPayload". ns4 is a namespace defined in the root
> element. I assume this attribute is used as a hint to JAXB when
> unmarshalling.
>
> The problem is that include a namespace in an attribute value is
> nothing XML cares about. In my case the service I call copies the
> payload and returns it to me as part of the response. When JAXB gets
> hold of it to unmarshal, that ns4:UfiCommandPayload is used as a
> namespace which is no longer present.
>
> Put another way, JAXB put the namespace alias in an attribute value
> with the namespace itself defined elsewhere. The service I called
> copied the payload out of my request and returned it in the response.
> However it didn't need to copy the ns4 namespace because there are no
> elements in that namespace used. When JAXB takes the attribute value
> and tries to look up a namespace which is not defined in the response.
>
> I'm not sure what to do at this point. I understand that JAXB needs
> hints on how to unmarshal a document. Using a namespace in that hint
> that isn't defined in the element itself is probably not a good idea.
> I guess if I could get JAXB to define the namespace in the payload
> element, that should work. Is it possible?
>
> (Note: I tried adding XmlElement(type = UfiCommandPayload) to the
> payload property. That removes the xsi:type attribute from the request
> xml but there are other classes that inherit the Message class that has
> the payload property. JAXB can't always unmarshal payload as
> UfiCommandPayload.)
>