You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2011/05/07 18:42:03 UTC
[jira] [Commented] (AXIS2-4602) JAX-WS MTOM issue
[ https://issues.apache.org/jira/browse/AXIS2-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030372#comment-13030372 ]
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].
[1] http://ws.apache.org/axiom/userguide/ch05.html#d0e1242
[2] http://ws.apache.org/axiom/apidocs/org/apache/axiom/ext/stax/datahandler/DataHandlerWriter.html
> JAX-WS MTOM issue
> -----------------
>
> Key: AXIS2-4602
> URL: https://issues.apache.org/jira/browse/AXIS2-4602
> 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 length):
> --MIMEBoundaryurn_uuid_6A41A9AB6F9E3EEAB71262792774662
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: <0....@apache.org>
> <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><dlwmin:getBinaryTestDataResponse xmlns:dlwmin="urn:ca.dmf.webservices"><return>f39/f39/f39/f39...</return></dlwmin:getBinaryTestDataResponse></soapenv:Body></soapenv:Envelope>
> --MIMEBoundaryurn_uuid_6A41A9AB6F9E3EEAB71262792774662--
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org