Hi Dan On Fri, Jul 23, 2010 at 8:13 PM, Daniel Kulp <[email protected]> wrote:
> > Sergey, > > Any idea where the second (empty) alternative is coming from? Is it due > to > optional=true policies? > > I've forgotten that optional assertions get normalized into a policy with two alternatives, one of them being empty. Will resumed investigating the issue tomorrow > 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. that would probably be a right solution anyway given that as far as the server is concerned it has to prioritize on the non-empty alternative > 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. > > For this specific issue I like the idea of restricting the server side to choosing a non-empty alternative as it seems the simplest option and yet the correct one too. cheers, Sergey > 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 >
