cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Questions While Implementing MTOM Policy
Date Tue, 24 Apr 2007 02:02:31 GMT
On 4/23/07, Sergey Beryozkin <> wrote:
>  Hi Dan
> > on the Client side, its all or nothing.
> I'm not sure what you mean. If the service's WSDL has an MTOM assertion
> attached, then :
> * if the assertion is not optional then the client-side interceptor knows
> it has to do MTOM, because this is what the service requires
> * if the assertion is optional then this interceptor can do some reasoning
> on whether to do MTOM or not...
> You're saying that it's not possible to do it at the moment, which is not
> a big problem per se, it's just limits the scope of what the client can do.
> In this case, one option is to configuire the client side explicitly to do
> MTOM if the service has the optional MTOM assertion.
> But this option (configuring the client) is not really required
> because this will make "MTOM always".
> On the client side one still can avoid the configuration (assuming the
> client runtime is policy aware) by just updating the MTOM handler to always
> do MTOM when it sees the service's MTOM assertion, whether it's optional or
> not.
> I'm also thinking that perhaps a custom version of the DataHandlers or
> JAXB marchallers can be provided to let the MTOM handler to do some
> reasoning when seeing am optional MTOM assertion, what do you reckon ?

What I was saying is that right now there is no way for us to detect that we
should switch to MTOM based on the size of the attachment. Part of the issue
is that we make the decision about whether we are going to stream the
message as soon as the interceptor chain starts. We don't make the decision
about a specific attachment until we're serializing the message and JAXB
makes some calls to AttachmentMarshallers. To determine whether or not MTOM
should be enabled dynamically on the client side would require us to
traverse the JAXB objects beforehand.

- Dan

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message