Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of sergey.beryozkin@iona.com
 designates 62.221.12.33 as permitted sender)
Message-ID: <04db01c7875e$b63fab50$c301020a@sberyoz>
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>, "Dan Diephouse" <dan@envoisolutions.com>
References: <D1AE8A943CFBEE408A89F87397B024D401D02B5D@tewk-mbpf2>
Subject: Re: Questions While Implementing MTOM Policy
Date: Wed, 25 Apr 2007 18:25:25 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

Hi Chris

I've seen the merge email, this is great.

I don't understand your comment about being unable to determine if the assertion was optional or not...Can you please explain why do 
you need to know it ?

Specifically, how the service with the optional MTOM assertion can serve both MTOMed and not-MTOMed requests ?

I was trying to highlight eartlier that wsp:optional is targeted at the client, not at the service provider...

wsp:optional can not indicate to the service that it may choose not to support MTOMed requests. If CXF did it that way then it would 
not pass the WS-Policy interoperabilty....

Thanks, Sergey


----- Original Message ----- 
From: "Christopher Moesel" <Christopher_Moesel@avid.com>
To: <cxf-dev@incubator.apache.org>; "Dan Diephouse" <dan@envoisolutions.com>
Sent: Monday, April 23, 2007 7:24 PM
Subject: RE: Questions While Implementing MTOM Policy


JIRA Issue w/ partially working patch for WS-MTOMPolicy support on the
server side:
https://issues.apache.org/jira/browse/CXF-593

As noted before, the broken part has to do with my inability to
determine if the assertion is optional from within the interceptor.

-Chris

-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Monday, April 23, 2007 1:52 PM
To: Dan Diephouse; cxf-dev@incubator.apache.org
Subject: Re: Questions While Implementing MTOM Policy

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 ?

Cheers, Sergey
  ----- Original Message ----- 
  From: Dan Diephouse
  To: cxf-dev@incubator.apache.org
  Cc: Sergey Beryozkin
  Sent: Monday, April 23, 2007 3:54 PM
  Subject: Re: Questions While Implementing MTOM Policy


  On 4/23/07, Sergey Beryozkin <sergey.beryozkin@iona.com> wrote:
    By the way, the issue Chris is trying to solve (finding out if the
MTOM policy expression was set as optional or not) is the real issue for
the client runtime.
    MTOM interceptor on the client side can check if it's required, if
yes, then use MTOM, if not, then consider whether to use it or not
anyway by checking the size of the outgoing message against the default
or preconfigured value, etc... This is will be a no client configuration
story (for MTOM)...

  Its not possible to check the size of the outgoing message or even
just the attachment. The DataHandler API doesn't expose it (and nor does
the JAXB AttachmentMarhsaller APIs), so on the Client side, its all or
nothing.


  - Dan


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