Hi
after spending quite a bit of time on debugging the issue I think I've traced where the problem is. Given that Policy with two assertions below we eventually get a normalized policy, with a single ExactlyOnce and one alternative <All> with those two simple assertions inside, this is stored with EndpointPolicyImpl. Next, we get an EffectivePolicyImpl but there we end up with two alternative, one is a proper All with WSA & RM, another one is empty. This is not too bad but PolicyEngine in its supportsAlernative method returns "true" for an empty alternative such as <All/> and given that EffectivePolicyImpl uses a MinimalSelector by default, this empty alternative is actually overriding a previous valid one on the basis that it's size (0) is less than that of the valid one. I propose two fixes : 1. PolicyEngine.supportsAlernative has to return false for an empty alternative. 2. MinimalSelector should ignore empty alternatives Any objections ? I'm going apply the to the snapshot and experiment if it fixes the issue cheers, Sergey On Wed, Jul 21, 2010 at 7:50 PM, Daniel Kulp <[email protected]> wrote: > > Sergey, > > Not sure what would cause this. My suggestion would be to stick a > breakpoint > at the end of the PolicyIn and Out interceptor's handleMessage calls and > have > it print the interceptor chain. If the RM policy is enabled, it SHOULD > have > added the RM interceptors. That would at least tell you if it's a > policy > issue or an RM issue. > > Dan > > > On Wednesday 21 July 2010 12:22:01 pm Sergey Beryozkin wrote: > > Hi > > > > I'm looking into the following issue. > > WSDL fragment : > > > > <wsdl:binding name="SimpleServiceSoapBinding" type="tns:SimpleService"> > > <wsp:Policy> > > <wswa:UsingAddressing xmlns:wswa=" > > http://www.w3.org/2006/05/addressing/wsdl"/> > > <wsrmp:RMAssertion xmlns:wsrmp=" > > http://schemas.xmlsoap.org/ws/2005/02/rm/policy"/> > > </wsp:Policy> > > </wsdl:binding> > > > > When the client invokes a simple echo() operation, the following is > > happening on the wire : > > > > 1. WS-RM CreateSequence request is sent and a successful response > > containing the sequence id/etc is sent back > > 2. Actual echo() request is sent with WS-A and WSRM headers included > > > > However the server replies with no WS-A/WS-RM headers and thus a runtime > > policy verification fails on the client side. > > > > Note that no Spring is used in this case. > > > > Obviously, the client recognizes that the above policy needs to be > applied > > and the server initially responds well to a WS-RM only request. It > appears > > though it is happening due to WS-RM interceptors installed by default on > > the server side. > > > > Question is : is it a bug that the server does not apply a policy to the > > outbound message (it is probably not even enforcing it on the inbound > > message too) in a WSDL-first with no Spring case ? Also, why the client > > does recognize the policy requirement but the server does not ? > > > > it's been awhile since I looked into the Ws-Policy code so some initial > > feedback will help :-) > > > > thanks, Sergey > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
