On Mon, Jul 26, 2010 at 11:31 PM, Nilupa Bandara <[email protected] > wrote:
> > > On Fri, Jul 23, 2010 at 9: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? >> > > To which policies do you refer by 'optional=true' policies ? (None of the > assertions are marked as optional in the policy expression defined in the > WSDL in question) > And I guess they refer to some internal policies of CXF framework and where can I locate them ? > >> 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 >> > > > > -- > Nilupa Bandara > > -- Nilupa Bandara
