Dan Diephouse wrote:
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 whatI'm inferring from the code - a policy expert may correct me :-).
That's correct - it is what the code should be doing according to http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Optional_Policy_Assertions <http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Optional_Policy_Assertions>
- 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 theassertion is optional, it creates a new ExactlyOne policy component with twoAlls. 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 myinterceptor. But my interceptor is not away of the 2nd empty All-- so itdoesn'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 myinexperienced 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 apeek. 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, butI'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?
Why does your interceptor need to be aware of it ?The policy may have been specified in normalised form in WSDL already - so your interceptor (or the policy framework its behalf) must browse all alternatives anyway, and check for two alternatives A and B that differ by nothing else except in that where one has an optional mtom assertion the other ones has no such assertion, and all other assertions are identical in these two alternatives (or where one is missing in A it is present in B as a required assertion). In other words you'd have to reverse the normalisation process and instead 'make it as compact as possible' so that no matter which way the policy was expressed the resulting behaviour is the same.
The problem seems related to who selects a policy alternative and when the selection is made. So far, the policy framework takes the approach to make that choice as early as possible (i.e. when message type and operation are known). The rationale behind this is to not add interceptors to the chain(s) when they are not needed. Also, at the moment the framework simply chooses the first alternative that can potentially be supported, not taking into account that some assertions are more costly to support than others. This can be changed to a more 'be prepared for any choice of alternative' approach, as is already do on the inbound chains (where the underlying message type and operation are not known upfront). Or, to be more flexible, we could a choice between early and deferred alternative selection.
If an assertion provider/interceptor wants exclusive rights on the interpretation of an optionality attribute in an assertion, it should define a corresponding attribute in its own namespace rather then depending on wsp:Optional.
Andrea.
> > 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
