On 4/23/07, Sergey Beryozkin <[EMAIL PROTECTED]> 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.

Cheers,
- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Reply via email to