On Jun 5, 2013, at 4:46 PM, Jesse Pangburn <jesse.pangb...@infor.com> wrote:
> This appears to be a bug. I stepped through the debugger into the > PolicyOutInterceptor's handle method and found the following in the > BindingOperationInfo object: > [BindingOperationInfo: {http://cxf.apache.org/jaxws/dispatch}Invoke] > > This is the default value which gets overridden at some point with the actual > operation. I'm not sure why this is, but my guess is that this > PolicyOutInterceptor is running before the code that looks at the message > content and computes the operation from the WSDL. > > The result is that the effective policy is incorrectly calculated because the > operation is unknown at that point, so it's only using the policy for the > service's binding and not merging in the policy for the operation's output > message. Does anyone know how to fix this correctly? In general, with a Dispatch client, you may need to tell the client which operation you are invoking. dispatch.getRequestContext().put(MessageContext.WSDL_OPERATION, new QName("http://cxf.apache.org/greeter_control", "greetMeOneWay")); or similar. That will allow the client to not process the body contents at all to try and determine the operation. Dan > > BTW, in case anyone else is reading this looking for how to print out the > effective policy, the answer is to turn on logging for the > PolicyOutInterceptor class at FINEST level. > > Thanks, > Jesse > > -----Original Message----- > From: Jesse Pangburn [mailto:jesse.pangb...@infor.com] > Sent: Tuesday, June 04, 2013 4:22 PM > To: users@cxf.apache.org > Subject: how to determine/debug effective ws policy used? > > Hi, > I'm trying to learn how to correctly use WS-Policy with CXF (using version > 2.7.2) and would like to know if there's a way to log the effective policy > calculated for both consumer and provider? > > The problem is that I have a wsdl with 3 policies attached to different > points. The first policy contains an asymmetric binding to provide the X509 > keys for signing/encryption. The second two policies just have the places I > want signed/encrypted, like this: > <wsp:Policy wsu:Id="Output_Policy"> > <wsp:ExactlyOne> > <wsp:All> > <sp:EncryptedParts> > <sp:Body/> > </sp:EncryptedParts> > <sp:SignedParts> > <sp:Body/> > ... > > In the WSDL, I have the following binding which references the first policy: > <wsdl:binding name="Binding_MyService" type="tns:MyService"> > <wsp:PolicyReference URI="#main_policy"/> > > The operations reference the second two policies to say what to sign/encrypt > in each direction: > <wsdl:operation name="PatientRequests"> > <soap12:operation > soapAction="http://example.com/schemas/'myService/PatientRequests" > style="document"/> > <wsdl:input> > <wsp:PolicyReference URI="#Input_policy"/> > <soap12:body use="literal"/> > </wsdl:input> > <wsdl:output> > <wsp:PolicyReference URI="#Output_Policy"/> > <soap12:body use="literal"/> > </wsdl:output> > </wsdl:operation> > > I've setup a client (using CXF Dispatch) and a server (using CXF Provider). > If I make a bad URI in the policy reference for the operation, the client > does not complain but the server does throw an exception saying it can't find > policy "xyz" (or whatever I rename the PolicyReference to). Whether the URI > is right or not, the client doesn't do the signing/encryption but the server > errors out complaining that the Body is not signed or encrypted (correctly, > since the client failed to sign/encrypt). > > So it appears to me that the client is not properly calculating the effective > policy as the merge of the main policy and either the input/output policy > (depending on direction), but the server does correctly calculate the > effective policy. In the main policy, I also have WS-Addressing engaged and > when I trace the messages I see that the client is sending the right Action > header so it's correctly determining the operation from the message I'm > sending, so it should be able to determine the right policy (just as the > server does when it receives the message and calculates the policy based on > the Action header). > > Thanks, > Jesse -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com