Sergey, Any idea where the second (empty) alternative is coming from? Is it due to optional=true policies?
If so, then either of those proposals would definitely change the behavior of things, especially on the client side. We kind of ran into this with the TCK. For example, if the addressing policy is "optional", with the current behavior, the client would not bother sending the addressing headers. Doing the addressing stuff slows things down so choosing the "empty" alternative is a good thing. I wondering if it's possible to allow the empty on outgoing on the client, but not on the server. Either that or we would need a new selector that somehow would take the incoming policy into affect when calculating the outgoing policy. For example, if the addressing/rm assertions were asserted on incoming side, then chose an alternative that has those. Might be a bit more complicated to write. Plus, the PolicyEngine would have to updated to allowing pulling the selector off the endpoint/message or similar. Another idea might be to have the PolicyEngine have two AlternativeSelectors, one for the requestor based requests that would be truely minimal and one for the other cases that would ignore the minimal. Dan On Friday 23 July 2010 1:19:53 pm Sergey Beryozkin wrote: > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog
