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.SecurityContextInterceptorProvider::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
