Hi The interesting bit here is that it would help looking at this normalized expression, and indeed at any other policy expression, being primarily targeted at the client runtime. Specifically, the optionality hint tells the client (by causing two alternatives created in the normalized form) that it may or may not choose the MTOM serialization when sending a given message to a service.
On the service side the optionality hint does not imply that the service may choose not to support MTOM. By exposing the MTOM assertion the service guarantees MTOM will be supported. So how the service will know that the MTOM processing should be done or not ? One message flowing to this service may be MTOMed (one client decided to do it) and the other one won't be MTOMed (the other client decided not to ot it may just be MTOM-unaware). The only hint is the MIME type of the incoming message. Given that, the only thing the MTOM-policy interceptor can really do is to check the in MIME type, and if it points to the fact MTOM is used then set the mtom.enabled property for the actual MTOM handler (unless this handler checls the MIME type itself). MTOM policy interceptor can only do the policy validation on a given message if the MTOM policy assertion is not marked as optional. Cheers, Sergey > OK, yeah ignore whatever I just said about optional not needing a prefix. > The attribute does need to be qualified, I read the schema wrong. > > W.r.t to normalization, I think what is supposed to happen is this: If an > element is optional (i.e. <OptimizedMimeSerialization > wsp:Optional="true"/>), then that expression becomes equivalent to > > <ExactlyOne> > <All><OptimizedMimeSerialization></All> > <All/> > </ExactlyOne> > > This would be considered the normalized expression. Or at least this is what > I'm inferring from the code - a policy expert may correct me :-). > > - Dan > > On 4/20/07, Christopher Moesel <[EMAIL PROTECTED]> wrote: >> >> Hi Dan, >> >> I'm not sure we're looking at the same code... I'm looking at the >> PrimitiveAssertion.java at http://preview.tinyurl.com/2qtfy3. >> >> If you look at the normalize method on line 94, you'll see that if the >> assertion is optional, it creates a new ExactlyOne policy component with two >> Alls. The first All contains the result of cloneMandatory() which >> constructs a clone with optional set to false. The second All is >> empty. This new PolicyComponent is what is returned. The non-optional >> assertion in the first All is what ends up being exposed to my >> interceptor. But my interceptor is not away of the 2nd empty All-- so it >> doesn't know this is really optional. >> >> Hopefully that makes a little more sense? Again, I'm also pretty >> unfamiliar with the normalization, so it's possible this is the intended >> behavior. >> >> When I get back to work on Monday I'll hack on it a little more and send >> along a patch if it might help-- I am developing it inside the CXF code >> base. >> >> Gotta go-- wife says it's time to stop working. ;) >> >> -Chris >> >> >> -----Original Message----- >> From: Dan Diephouse [mailto:[EMAIL PROTECTED] >> Sent: Fri 4/20/2007 5:42 PM >> To: [email protected] >> Subject: Re: Questions While Implementing MTOM Policy >> >> Hi Christopher, >> >> It sounds like a possible bug. The normalization logic looks right (for my >> inexperienced eyes). It only adds a second All if optional is false. Do >> you >> know where optional gets set to false? Only place I see that called is >> JaxbAssertionBuilder:104... >> >> I'm not sure if you're doing this in your own build or within in the CXF >> build, but you could possibly send a patch along and I'll try to take a >> peek. Or, you can take a gander at fixing normalization yourself. I'll be >> honest, I'm not that familiar with how normalization works yet in CXF, but >> I'll see if I can help. >> >> - Dan >> >> On 4/20/07, Christopher Moesel <[EMAIL PROTECTED]> wrote: >> > >> > I fit in a little more work... It's almost their, except that even >> > though I set my policy assertion to wsp:Optional="true", by the time it >> > makes it to the interceptor, the optional attribute is false. >> > >> > If I debug, I can see that when the PrimitiveAssertion is built, it >> > correctly sets the "optional" attribute to true. But somewhere down the >> > line, the assertion is "normalized" and the optional flag gets reset to >> > false. This appears to be happening in the PrimitiveAssertion.normalize >> > method. The PolicyComponent returned is an ExactlyOne that contains two >> > Alls. The first All has a PrimitiveAssertion with optional set to >> > false. The second All is empty. >> > >> > Is this the intended behavior? Is this a translation of optional=true >> > to an ExactlyOne with one required Assertion and one empty Assertion? >> > If so, how can I tell the difference between that and optional=false >> > from within an interceptor? >> > >> > Or does that question not even make sense? ;) >> > >> > -Chris >> > >> > -----Original Message----- >> > From: Christopher Moesel [mailto:[EMAIL PROTECTED] >> > Sent: Friday, April 20, 2007 4:16 PM >> > To: [email protected] >> > Subject: RE: Questions While Implementing MTOM Policy >> > >> > Thanks Dan-- that information has helped me get a bit further. I'm >> > afraid I won't be able to do any more work on it until Monday though... >> > I'll let you know how things are going... >> > >> > -Chris >> > >> > -----Original Message----- >> > From: Dan Diephouse [mailto:[EMAIL PROTECTED] >> > Sent: Friday, April 20, 2007 3:15 PM >> > To: [email protected] >> > Subject: Re: Questions While Implementing MTOM Policy >> > >> > Hi Christopher, >> > >> > A zip of the module or a paste of the interceptor, mtom-policy.xml file, >> > and >> > interceptor provider would be extremely helpful. >> > >> > Re question #2 - is your question how do I apply this mtom policy to my >> > service? I think the two mechanisms we have right now are WSDL Policy >> > Attachments and creating an external policy. I'm working on a third >> > where we >> > can embed it in an <endpoint>/<client> configuration. >> > >> > Here's a small example of how to load an external policy file: >> > >> > <bean class=" >> > org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider" >> > > >> > <constructor-arg ref="cxf"/> >> > <property name="location" >> > value="org/apache/cxf/systest/ws/policy/addr-external.xml"/> >> > </bean> >> > >> > And then the external file: >> > >> > <attachments xmlns:wsp="http://www.w3.org/2006/07/ws-policy"; xmlns:wsa=" >> > http://www.w3.org/2005/08/addressing";> >> > <wsp:PolicyAttachment> >> > <wsp:AppliesTo> >> > <wsa:EndpointReference> >> > >> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort >> > </wsa:Address> >> > </wsa:EndpointReference> >> > </wsp:AppliesTo> >> > <wsp:Policy> >> > <wsam:Addressing xmlns:wsam=" >> > http://www.w3.org/2007/01/addressing/metadata";> >> > <wsp:Policy/> >> > </wsam:Addressing> >> > </wsp:Policy> >> > </wsp:PolicyAttachment> >> > </attachments> >> > >> > This is part of the policy system tests. How are you configuring your >> > service right now? Via the API? Via Spring? >> > - Dan >> > >> > On 4/20/07, Christopher Moesel <[EMAIL PROTECTED]> wrote: >> > > >> > > A Quick Update: >> > > >> > > I moved the bean configurations from the >> > > META-INF/cxf/cxf-extension-mtom-policy.xml file to my service's own >> > > Spring configuration file. Now I can see that my >> > MTOMAssertionBuilder, >> > > MTOMPolicyInterceptorProvider, and MTOMPolicyInterceptors are at least >> > > instantiated (which is further than I got before). >> > > >> > > But, the handleMessage method on my MTOMPolicyInterceptor is never >> > > called when I make a request to the service, so something still >> > doesn't >> > > seem to be registered right. >> > > >> > > So two questions now: >> > > >> > > 1) Why wasn't my META-INF/cxf/cxf-extension-mtom-policy.xml file >> > never >> > > loaded by the framework? >> > > >> > > 2) How do I get my service to actually build those assertions and >> > > intercept the messages? >> > > >> > > Thanks, >> > > Chris >> > > >> > > -----Original Message----- >> > > From: Christopher Moesel [mailto:[EMAIL PROTECTED] >> > > Sent: Friday, April 20, 2007 2:40 PM >> > > To: [email protected] >> > > Subject: Questions While Implementing MTOM Policy >> > > >> > > Hello, >> > > >> > > I'm trying to implement a plugin for the MTOM Policy specification. >> > > This is essentially a policy that states whether or not MTOM should be >> > > used (or is optional). I intend on contributing it back to CXF, so I >> > > figure I'm OK sending this to the dev list. ;) >> > > >> > > I've created a MTOMAssertionBuilder that uses PrimitiveAssertions, a >> > > MTOMPolicyInterceptor (that at this point just prints out if it is >> > > asserted), and a MTOMPolicyInterceptorProvider. >> > > >> > > I've registered the MTOMAssertionBuilder and >> > > MTOMPolicyInterceptorProvider in >> > > META-INF/cxf/cxf-extension-mtom-policy.xml and created a corresponding >> > > META-INF/cxf/cxf.extension file. According to the documentation, this >> > > is all that is needed to register them in CXF. >> > > >> > > When I try my service (that has the ws-policy and ws-mtom-policy jars >> > in >> > > its classpath), none of my MTOM policy classes seem to be called. Do >> > I >> > > need to do something else to register them with my service, or is >> > having >> > > the policy assertion in the port of my WSDL file enough? It seems I >> > > must be missing something important. >> > > >> > > If it would be helpful, I can zip up the module and send it along. >> > > >> > > Thanks! >> > > Chris >> > > >> > >> > >> > >> > -- >> > Dan Diephouse >> > Envoi Solutions >> > http://envoisolutions.com | http://netzooid.com/blog >> > >> >> >> >> -- >> Dan Diephouse >> Envoi Solutions >> http://envoisolutions.com | http://netzooid.com/blog >> >> > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
