On Monday 26 July 2010 12:31:31 pm Sergey Beryozkin wrote: > > 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.
Not really. IMO, the "correct" thing would be to somehow compare the possible alternatives with the AssertionMap of the incoming request to figure out which alternative is "most assertable" based on the assertions of the incoming request. For example, there COULD be a policy that was use "either security or RM". To select the correct policy on the outgoing side, you would really need to look at the incoming assertions. Unfortunately , that starts getting really complex and requires a bunch of API changes. :-( Dan > > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog
