Hi Dan, > I don't think InterceptorProvider is one of the things that is looked up this > way. You likely need a BusLifecycleListener, Feature, > ClientLifecycleListener, > or ServerLifecycleListener depending on what you need to add the > interceptors to.
Hmm ... but in my use case adding of interceptors is triggered by the policy assertion. Seems that InterceptorProvider is right choice for this case. I would like to instantiate InterceptorProvider as OSGi service instead bus-extensions mechanism, because it makes easy injection of other OSGi services, working with OSGi config props, etc. Any chance to do achieve that? Regards, Andrei. > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Montag, 26. August 2013 20:03 > To: Andrei Shakirin > Cc: [email protected] > Subject: Re: extensions dynamically added/removed from exited bus > > > On Aug 26, 2013, at 2:00 PM, Andrei Shakirin <[email protected]> wrote: > > > Hi Dan, > > > >> Just register your OSGi service as normal, but use the appropriate > >> CXF interface as the interface for your exposed OSGi service. That really > should > >> be all you need to do. When the runtime calls into the Bus to get the > >> extension of that interface (either bus.getExtension(Interface.class) > >> or via the ConfiguredBeanLocator), it should find it in the OSGi services. > > > > I have tried that in CXF 2.7.7 for InterceptorProviders. Bundle exposes my > interceptor provider as OSGi service (implemented CXF InterceptorProvider > interface): > > > > I don't think InterceptorProvider is one of the things that is looked up this > way. You likely need a BusLifecycleListener, Feature, > ClientLifecycleListener, > or ServerLifecycleListener depending on what you need to add the > interceptors to. > > Dan > > > > tesbext-security-interceptor-provider (334) provides: > > ----------------------------------------------------- > > osgi.service.blueprint.compname = securityContextInterceptorProvider > > objectClass = org.apache.cxf.interceptor.InterceptorProvider > > service.id = 716 > > > > Unfortunately my interceptor provider is not picked up by the runtime. > > > > As soon as I add bus-extensions.txt containing: > > > > org.sopera.csg.tesbext.security.interceptor.provider.SecurityContextIn > > terceptorProvider::true into the project, interceptor provider works. > > > > Seems that both mechanisms are not really equal. > > Any suggestions where I can dig? > > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Daniel Kulp [mailto:[email protected]] > >> Sent: Freitag, 23. August 2013 15:29 > >> To: [email protected]; Andrei Shakirin > >> Subject: Re: extensions dynamically added/removed from exited bus > >> > >> > >> On Aug 23, 2013, at 8:53 AM, Andrei Shakirin <[email protected]> > wrote: > >> > >>>> If the extensions are not really loaded via a > >>>> META-INF/bus-extension.txt > >> and > >>>> instead are OSGi services, you may be able to accomplish a bit more. > >> When > >>>> the bundle stops and the service is stopped, it should be able to > >>>> get a blueprint lifecycle event and then go ahead an unregister > >>>> anything that is may have registered, but I'm not 100% sure that > >>>> would work completely correctly. > >>> > >>> I know from Christian that you have added new functionality to > >>> register > >> extensions as OSGi services (not via META-INF/bus-extension.txt). > >>> Could you point on test or sample how to do that? > >> > >> Just register your OSGi service as normal, but use the appropriate > >> CXF interface as the interface for your exposed OSGi service. That really > should > >> be all you need to do. When the runtime calls into the Bus to get the > >> extension of that interface (either bus.getExtension(Interface.class) > >> or via the ConfiguredBeanLocator), it should find it in the OSGi services. > >> > >> Dan > >> > >> > >> > >> > >> > >>> > >>> Regards, > >>> Andrei. > >>> > >>>> -----Original Message----- > >>>> From: Daniel Kulp [mailto:[email protected]] > >>>> Sent: Donnerstag, 1. August 2013 00:53 > >>>> To: [email protected]; iris ding > >>>> Subject: Re: extensions dynamically added/removed from exited bus > >>>> > >>>> > >>>> On Jul 29, 2013, at 5:17 AM, iris ding <[email protected]> wrote: > >>>> > >>>>> Hi , > >>>>> > >>>>> Can we think CXF will not support such usage or in other words, > >>>>> CXF has not taken such function into consideration from it's > >>>>> initial design and such use cases should not be encouraged in CXF > >>>>> -- If user want to make new/removed extensions take effect in > >>>>> existed bus, they need to re-create the bus, Is this understanding > right? > >>>> > >>>> Pretty much yes. Since extensions can do all kinds of things (set > >>>> properties, add interceptors, etc...) which would be difficult to > >>>> "undo", it's not something we've tackled. > >>>> > >>>> If the extensions are not really loaded via a > >>>> META-INF/bus-extension.txt > >> and > >>>> instead are OSGi services, you may be able to accomplish a bit more. > >> When > >>>> the bundle stops and the service is stopped, it should be able to > >>>> get a blueprint lifecycle event and then go ahead an unregister > >>>> anything that is may have registered, but I'm not 100% sure that > >>>> would work completely correctly. > >>>> > >>>> > >>>> -- > >>>> Daniel Kulp > >>>> [email protected] - http://dankulp.com/blog Talend Community > Coder - > >>>> http://coders.talend.com > >>> > >> > >> -- > >> Daniel Kulp > >> [email protected] - http://dankulp.com/blog Talend Community Coder - > >> http://coders.talend.com > > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
