AFAIK the actual JAXB 2.0 specification and RI are still covered by
licenses which prohibit public discussions of the API information
disclosed under those licenses. However, a search finds unrestricted
pages such as
https://jax-rpc.dev.java.net/jaxws20-ea2/docs/mtom-swaref.html which
discuss JAXB 2.0 usage of MTOM/XOP, and you can also search for
AttachmentMarshaller and AttachmentUnmarshaller for more details.
This support uses AttachmentMarshaller and AttachmentUnmarshaller for
the actual handling of attachment data (in combination with the standard
DataHandler class). I'm planning a similar type of approach for JiBX.
The key issue is that the data binding framework has to have access to
something more than just an input or output stream in order to handle
MTOM/XOP (not surprising, since MTOM/XOP deliberately breaks layering so
that the transport becomes intertwined with the XML representation).
I haven't looked into the details of how the OM support for MTOM/XOP
hooks into the transport, but I imagine there's some similar kind of
deferred processing list for attachments. The data binding framework
interfaces will need to have access to this deferred processing list so
that they can convert binary data blobs to attachments when marshalling,
and hook up objects containing binary data blobs to receive attachments
when unmarshalling. You might want to think about how to hook the JAXB
2.0 AttachmentMarshaller and AttachmentUnmarshaller into the Axis2
MTOM/XOP support, on the assumption that this is something which will be
required if Axis2 is going to have JAXB 2.0 support. The issues are
likely to be very similar for other data binding frameworks that support
MTOM/XOP.
- Dennis
Thilina Gunarathne wrote:
Hi,
First of all I'm not sure about the any of the frameworks supporting
MTOM/XOP.
IMHO if somebody wants to have MTOM with data binding, there will be
issues with both these approaches.
In the first approach we are giving the StaxOMBuilder an pull parser.
Given a pull parser even though it throws xop events, there won't be
MIME parts for those references. This issue will be resolved if there
is a way to keep a reference to the underlying stream.
In the second approach we are giving out a plain XMLStreamWriter. If
we have any intentions of MTOM/XOP according to the current
architecture we have to pass a OMOutput in to the serialize method. It
is clear that these frameworks does not support XOP, byseeing that
they take in XMLStreamWriters for the serialize. IMO Things will be
much more difficult for MTOM/XOP in this approach.
Just my two cents. I'm still new to the Data binding concepts and some
of my ideas may sound crazy. Pls bare with me.
