[
https://issues.apache.org/jira/browse/AXIS2-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760174#action_12760174
]
Cathal Callaghan commented on AXIS2-3591:
-----------------------------------------
Hi Satya,
In order to enable MTOM over JMS with Axis2 you must ensure the following
properties are set on your client:
/* enable MTOM - all binary elements will be serialised as MTOM attachments */
options.setProperty(Constants.Configuration.ENABLE_MTOM, Constants.VALUE_TRUE);
/* send JMS messages as byte messages, Axis2 only allows the use of MTOM with
byte messages in JMS */
options.setProperty(JMSConstants.JMS_MESSAGE_TYPE,
JMSConstants.JMS_BYTE_MESSAGE);
/* use doom axiom tree - this is required when using MTOM and rampart together,
if not set
* MTOM will be ignored and all binary data will be sent unoptimised in the SOAP
envelope */
options.setProperty(WSSHandlerConstants.USE_DOOM, Constants.VALUE_TRUE);
If you ensure that these properties are set, you already have
Constants.Configuration.ENABLE_MTOM set, you should have no problem.
Thanks,
Cathal
> MTOM doesnt work over JMS
> -------------------------
>
> Key: AXIS2-3591
> URL: https://issues.apache.org/jira/browse/AXIS2-3591
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: transports
> Affects Versions: 1.3
> Environment: OS: Windows XP Pro 2002 Service Pack 2
> Reporter: Cathal Callaghan
> Attachments: JMSSender.java
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Performing MTOM optimization over the JMS transport does not work correctly.
> There are three main issues involved here:
> 1) MessageContext.setDoingMTOM()
> For the JMS transport a call to MessageContext.setDoingMTOM() will always
> return false. This is due to the fact that, unlike the HTTP transport, the
> JMS transport never checks whether enableMTOM has been set in config or
> programmatically. This means that a JMS message containing binary content
> will never be optimized.
> 2) JMSByteMessage always sent as soap1.1 format
> The OMOutputFormat class defaults its soap version to soap1.1. The HTTP
> transport sets this according to the soap namespace used in the soap
> envolope. JMS however does not do this and the byte message is always sent as
> soap1.1
> 3) contentType of JMS message is never set
> The contentType of a JMS message is never set. This passes unnoticed on the
> server when attachments are not involved. However when a message contains
> attachments the expected contentType of 'multipart/related' is never present
> and the message is perceived as a non soap/xml message which is incorrect.
> I have attached a working solution for the above issue so can submit if agreed
> Thanks,
> Cathal Callaghan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
