Hi Dan, I can submit a patch to make this change if necessary? Just hoping for some feedback if this is a bad idea for some reason?
Thanks, Jesse -----Original Message----- From: Jesse Pangburn Sent: Friday, June 28, 2013 3:05 PM To: [email protected]; Daniel Kulp Subject: RE: how to determine/debug effective ws policy used? Hi Dan, Just wonder if you've had a chance to see if this code should be changed as I suggested, or if it is incorrect and will cause some other problem? Thanks, Jesse -----Original Message----- From: Jesse Pangburn [mailto:[email protected]] Sent: Wednesday, June 05, 2013 3:36 PM To: Daniel Kulp; [email protected] Subject: RE: how to determine/debug effective ws policy used? Hi Dan, As always, thanks for your excellent help! That did work. However, there's a setting that I thought was supposed to take care of this issue in Dispatch: disp.getRequestContext().put("find.dispatch.operation", Boolean.TRUE); This was the fix I used to make it properly set the SOAPAction header based on the payload name when WS-Addressing is not enabled. Previously (you may recall), I found that SOAPAction was only set when WS-Addressing was not enabled. This resolved that issue. What I'm wondering is how come this same setting doesn't already take care of this WSDL operation issue too? If it's set true then it's already going in and locating the "dispatchedOpName". This is the relevant code: <String, QName> payloadOPMap = createPayloadEleOpNameMap(client.getEndpoint().getBinding().getBindingInfo()); if (findDispatchOp && !payloadOPMap.isEmpty()) { String payloadElementName = null; if (obj instanceof javax.xml.transform.Source) { XMLStreamReader reader = null; try { reader = StaxUtils.createXMLStreamReader((javax.xml.transform.Source)obj); Document document = StaxUtils.read(reader); createdSource = new StaxSource(StaxUtils.createXMLStreamReader(document)); payloadElementName = getPayloadElementName(document.getDocumentElement()); } catch (Exception e) { // ignore, we are trying to get the operation name } finally { StaxUtils.close(reader); } } if (obj instanceof SOAPMessage) { payloadElementName = getPayloadElementName((SOAPMessage)obj); } if (this.context != null) { payloadElementName = getPayloadElementName(obj); } if (payloadElementName != null) { QName dispatchedOpName = payloadOPMap.get(payloadElementName); if (null != dispatchedOpName) { BindingOperationInfo bop = client.getEndpoint().getBinding().getBindingInfo() .getOperation(opName); BindingOperationInfo dbop = client.getEndpoint().getBinding().getBindingInfo() .getOperation(dispatchedOpName); if (bop != null) { // set the actual binding operation object to this dispatch operation bop.setProperty("dispatchToOperation", dbop); } } } } I see it just sets this "dispatchToOperation" property on the BindingOperationInfo object for the default "Invoke" placeholder opName. Why not just set the opName to the newly determined dispatchedOpName at this point? Then all subsequent code will execute with the opName set to the correct one from the WSDL instead of the default "Invoke". I changed that section to: if (bop != null) { // set the actual binding operation object to this dispatch operation bop.setProperty("dispatchToOperation", dbop); // update the opName while we're at it opName = dispatchedOpName; } This solved the problem without manually setting the MessageContext.WSDL_OPERATION, probably because it gets set correctly on down the line from this updated opName. I assume there must be something wrong with doing this, which is why that property was set instead of just updating the opName in the first place? Thanks, Jesse -----Original Message----- From: Daniel Kulp [mailto:[email protected]] Sent: Wednesday, June 05, 2013 1:55 PM To: [email protected]; Jesse Pangburn Subject: Re: how to determine/debug effective ws policy used? 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
