Hi I feel we're still looking at the same issue from different perspectives :-)
> To determine whether or not MTOM should be enabled dynamically on the client > side would require us to traverse the JAXB objects beforehand. My point is that the presence of the MTOM policy assertion in the service's WSDL/EPR (directly or indirectly through the extermal attachment) is all what is needed for a policy aware client runtime to enable MTOM dynamically. This is one of the purposes of any policy assertion - to mimiize the client configuration, if possible. The decision is made at the start of the interceptor chain, but I reckon at that moment of time the client runtime is already aware of the service endpoint's capabilities/requirements... Another thing I was trying to say that the service would likely make the MTOM not a required thing to do for the client, it will make it an optional assertion. So I was saying that in this case, the client runtime, given that the service does not strictly require it to do MTOM, may try to do some advanced reasoning as to whether to do it or not, judging on the size of the message, and some other factors. I understand from your explanation that it's not possible to do it on the CXF client side at the moment. But even in this case the client runtime is still aware that the service supports MTOM so client may do it dynamically. Am I still missing the point ? Imagine a cool demo : CXF client runtime consumes a CXF-enabled service, this service does not do MTOM so the client doesn'd do it either, now the same client consumes a NET-enabled service (with the same interface) which either requires or states that it will accept MTOMs, so CXF client just sends MTOMed message to the NET service, and all without the explicit MTOM configuration :-) Would you agree it can work ? In some cases the (MTOM) client configuration may need to be supplied even for policy-aware client runtimes, say when the client it talks to a policy-unaware service which is known to require messages be MTOMed... Cheers, Sergey ----- Original Message ----- From: Dan Diephouse To: Sergey Beryozkin Cc: [email protected] Sent: Tuesday, April 24, 2007 3:02 AM Subject: Re: Questions While Implementing MTOM Policy 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
