axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] [Commented] (AXIS2-4602) JAX-WS MTOM issue
Date Sat, 07 May 2011 16:42:03 GMT


Andreas Veithen commented on AXIS2-4602:

The code pretty much duplicates some code that can be found in the ADB databinding. It has
the same flaws:
* Incorrect handling of namespace bindings. Namespace bindings are scoped and you can't simply
store them in a map.
* It's an implementation of the anti-pattern described in [1], which (in the ADB case) is
one of the culprits of the bad performance revealed by Dennis Sosnoski's articles.
* It introduces yet another component specific API to deal with DataHandler objects, instead
of using the standard API defined by Axiom [2].


> JAX-WS MTOM issue
> -----------------
>                 Key: AXIS2-4602
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: jaxws
>            Reporter: Isuru Eranga Suriarachchi
>            Assignee: Isuru Eranga Suriarachchi
>         Attachments: jaxws-mtom-fix.txt
> In Axis2 JAX-WS implementation, org.apache.axis2.jaxws.message.Block is extending OMDataSourceExt.
In the response messages of normal invocations, this object is kept inside the body of the
SOAPEnvelope and directly serialized without building the OMElement. In order to handle MTOM,
it uses the JAXBAttachmentMarshaller which writes data handler objects into the MTOMXMLStreamWriter.
> MTOM works fine as far as the return OMElement is not built and directly serialized using
the OMDataSource. But if the OMElement is built by some handler on the return path, JAXB Block
is written to a ByteArrayOutputStream and read as a ByteArray (through the getReader() method
of BlockImpl). Therefore, the OMElement which is built using this ByteArray, doesn't know
about MTOM. So, the response is given as base64 (inline).
> So even though the service is MTOM enabled, if some handler (Ex: Security) builds the
body element, the binary response data is transmitted as base64-encoded inline, instead of
as a separate binary attachment (see below - I remove most of the returned data due to its
> --MIMEBoundaryurn_uuid_6A41A9AB6F9E3EEAB71262792774662
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: <>
> <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv=""><soapenv:Body><dlwmin:getBinaryTestDataResponse
> --MIMEBoundaryurn_uuid_6A41A9AB6F9E3EEAB71262792774662-- 

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message