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? Completely refuse from Spring and support only blueprint? Use other technology to control lifecycle? Regards, Andrei. -----Original Message----- From: Daniel Kulp [mailto:[email protected]] Sent: 15 December 2011 16:42 To: [email protected] 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.ServiceRegistryFeature" > /> <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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
