On Jun 5, 2013, at 4:46 PM, Jesse Pangburn <[email protected]> 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:[email protected]]
> Sent: Tuesday, June 04, 2013 4:22 PM
> To: [email protected]
> 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
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
