axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: [Axis2] Data Binding
Date Wed, 02 Nov 2005 08:52:16 GMT
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 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 

  - Dennis

Thilina Gunarathne wrote:

> Hi,
> First of all I'm not sure about the any of the frameworks supporting 
> 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.

View raw message