cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nilupa Bandara <nilupa.manamp...@gmail.com>
Subject Re: WS-Policy is not applied to the outbound message on the server side (WSDL first)
Date Mon, 26 Jul 2010 21:31:24 GMT
On Fri, Jul 23, 2010 at 9:13 PM, Daniel Kulp <dkulp@apache.org> 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)

Sanka



>
> 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 <dkulp@apache.org> 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
> > > dkulp@apache.org
> > > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>



-- 
Nilupa Bandara

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message