You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jesse Pangburn <Je...@infor.com> on 2013/09/10 00:57:17 UTC
RE: how to determine/debug effective ws policy used?
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: users@cxf.apache.org; 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:Jesse.Pangburn@infor.com]
Sent: Wednesday, June 05, 2013 3:36 PM
To: Daniel Kulp; users@cxf.apache.org
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:dkulp@apache.org]
Sent: Wednesday, June 05, 2013 1:55 PM
To: users@cxf.apache.org; Jesse Pangburn
Subject: Re: how to determine/debug effective ws policy used?
On Jun 5, 2013, at 4:46 PM, Jesse Pangburn <Je...@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.Pangburn@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
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
RE: how to determine/debug effective ws policy used?
Posted by Jesse Pangburn <Je...@infor.com>.
Hi,
Patch is attached to new issue created for it: https://issues.apache.org/jira/browse/CXF-5268
I've added it to my 2.7.6 source, compiled, and tested. Now when the WSDL has policies on the messages beneath an operation, those policies are automatically computed with this fix and merged with any binding policy. These policies are typically which elements are to be signed/encrypted in request/response messages. The fix is triggered by the same setting that enabled automatic WS-Addressing computation from outbound message content for Dispatch users:
disp.getRequestContext().put("find.dispatch.operation", Boolean.TRUE);
thanks,
Jesse
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Tuesday, September 10, 2013 2:14 PM
To: users@cxf.apache.org; Jesse Pangburn
Subject: Re: how to determine/debug effective ws policy used?
On Sep 9, 2013, at 6:57 PM, Jesse Pangburn <Je...@infor.com> wrote:
> 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?
Sure. Feel free to submit a patch for it. I cannot imagine it would be a problem, but I could then run a series of extra tests and such for it.
Dan
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Jesse Pangburn
> Sent: Friday, June 28, 2013 3:05 PM
> To: users@cxf.apache.org; 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:Jesse.Pangburn@infor.com]
> Sent: Wednesday, June 05, 2013 3:36 PM
> To: Daniel Kulp; users@cxf.apache.org
> 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:dkulp@apache.org]
> Sent: Wednesday, June 05, 2013 1:55 PM
> To: users@cxf.apache.org; Jesse Pangburn
> Subject: Re: how to determine/debug effective ws policy used?
>
>
> On Jun 5, 2013, at 4:46 PM, Jesse Pangburn <Je...@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.Pangburn@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
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: how to determine/debug effective ws policy used?
Posted by Daniel Kulp <dk...@apache.org>.
On Sep 9, 2013, at 6:57 PM, Jesse Pangburn <Je...@infor.com> wrote:
> 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?
Sure. Feel free to submit a patch for it. I cannot imagine it would be a problem, but I could then run a series of extra tests and such for it.
Dan
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Jesse Pangburn
> Sent: Friday, June 28, 2013 3:05 PM
> To: users@cxf.apache.org; 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:Jesse.Pangburn@infor.com]
> Sent: Wednesday, June 05, 2013 3:36 PM
> To: Daniel Kulp; users@cxf.apache.org
> 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:dkulp@apache.org]
> Sent: Wednesday, June 05, 2013 1:55 PM
> To: users@cxf.apache.org; Jesse Pangburn
> Subject: Re: how to determine/debug effective ws policy used?
>
>
> On Jun 5, 2013, at 4:46 PM, Jesse Pangburn <Je...@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.Pangburn@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
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com