cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: cxf:bus overrides dynamically added interceptors by features
Date Fri, 16 Dec 2011 14:54:48 GMT
On Friday, December 16, 2011 8:24:12 AM Andrei Shakirin wrote:
> Thanks for info Dan!
> 
> I will test it with 2.5.1-SNAPSHOT.
> 
> Btw: do you have already any thoughts how to harmonize the stuff in next
> 2.6.X, 3.X version?

I think 2.5.1 should have them acting the same.   The lifecycles of the Bus 
objects for the two cases should be more unified.  

The main problem was that Blueprint was actually configuring a BlueprintBus 
directly as a bean (good).    Spring was not.   It was configuring an object 
that then had the bus injected in and then it would configure the Bus.   Thus, 
you ended up with different behaviors depending on when that bean was created 
relative to other beans.

Also, in Blueprint, the Bus.initialize method was being called right when the 
bus was created and after injection.  (basically, the init-method on the bean 
definition).    Thus, the lifecycle event would fire prior to other beans that 
depend on the bus get it injected.   This is generally how spring/blueprint 
beans are supposed to behave.     With spring, it wasn't being called until 
the entire context was done initializing.   

Anyway, 2.5.1 should unify this a bit.

> Completely refuse from Spring and support only
> blueprint? 

LOL.  :-)

Dan


> Use other technology to control lifecycle?
> 
> Regards,
> Andrei.
> 
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 15 December 2011 16:42
> To: users@cxf.apache.org
> Cc: Andrei Shakirin
> Subject: Re: cxf:bus overrides dynamically added interceptors by features
> 
> 
> I think this is now fixed with 2.5.1-SNAPSHOT (final testing before doing
> release right now).       I also assume you are using Spring and not
> blueprint with that config.
> 
> I spent a ton of time last week trying to rationalize some of the lifecycle
> stuff and parsing things and some of what you are describing falls into the
> issues I was seeing last week and tried to fix.   There were all kinds of
> issues with server/client lifecycle events firing before the bus events,
> features/interceptors overwriting each other, etc...    What's worse, the
> behavior was quit different for Spring and Blueprint.   2.5.1 brings things
> more inline with each other and hopefully fixes a bunch of this.
> 
> Dan
> 
> On Thursday, December 15, 2011 11:04:42 AM Andrei Shakirin wrote:
> > Hi,
> > 
> > I faced one effect by using policies:
> > 
> > WS-Addressing Policy feature is configured in client spring
> > configuration:
> > 
> > <jaxws:client id="FlightReservationClient"
> > 
> > xmlns:serviceNamespace="http://www.eclipse.org/swordfish/samples/Fligh
> > tRese
> > rvation"
> > serviceClass="org.eclipse.swordfish.samples.flightreservation.FlightRe
> > serva tion" serviceName="serviceNamespace:FlightReservationService"
> > endpointName="serviceNamespace:FlightReservationSOAP"
> > address="http://localhost:9040/services/FlightReservationService">
> > 
> >              <jaxws:features>
> >              
> >                     <bean
> > 
> > class="org.talend.ps.rudi.resolver.serviceregistry.ServiceRegistryFeatur
> > e" /> <policy:policies>
> > 
> >                            <wsp:Policy
> > 
> > xmlns:wsp="http://www.w3.org/ns/ws-policy"> <wsam:Addressing
> > xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" />
> > </wsp:Policy>> 
> >                     </policy:policies>
> >              
> >              </jaxws:features>
> >        
> >        </jaxws:client>
> > 
> > In the same file custom out interceptor is configured:
> >        <cxf:bus>
> >        
> >              <cxf:outInterceptors>
> >              
> >                     <ref
> >                     bean="AgreedPolicyInterceptor"
> >                     />
> >              
> >              </cxf:outInterceptors>
> >        
> >        </cxf:bus>
> > 
> > As far as PolicyFeature is defined in client configuration,
> > PolicyEngineImpl adds some interceptors into  chain:
> > bus.getInInterceptors().add(PolicyInInterceptor.INSTANCE);
> > bus.getOutInterceptors().add(PolicyOutInterceptor.INSTANCE);
> > bus.getInFaultInterceptors().add(ClientPolicyInFaultInterceptor.INSTAN
> > CE);
> > bus.getOutFaultInterceptors().add(ServerPolicyOutFaultInterceptor.INST
> > ANCE)
> > ;
> > bus.getInFaultInterceptors().add(PolicyVerificationInFaultInterceptor.
> > INSTA
> > NCE);
> > 
> > Effect is following: as far as I define custom interceptor in client
> > configuration, it overrides Policy interceptors added by
> > PolicyEngineImpl. After it policy doesn't work anymore. As soon as
> > comment my custom out interceptor - policy works.
> > Policy also works if custom interceptor is configured not in cxf:bus,
> > but in jaxws:outInterceptors inside the client.
> > 
> > Overriding happens in method
> > org.apache.cxf.interceptor.AbstractBasicInterceptorProvider.setOutInte
> > rcept
> > ors(): public void setOutInterceptors(List<Interceptor<? extends
> > Message>>
> > interceptors) { out = interceptors;
> > 
> >     }
> > 
> > It doesn't adds configured interceptors to existing, but just replaces
> > them. The same is true for in and fault interceptors.
> > 
> > The question is it work as designed?
> > 
> > Regards,
> > Andrei.
> 
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message