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
