Hi Dan, One more related question: what happens if required bus was created before my BusLifecycleListener is activated? Is there any way to get a list of all existing Buses?
Regards, Andrei. > -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: Donnerstag, 12. September 2013 10:20 > To: Daniel Kulp; [email protected] > Subject: RE: extensions dynamically added/removed from exited bus > > Hi Dan, > > Just confirm that proposed solution works! > > Thanks, > Andrei. > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Montag, 26. August 2013 20:40 > > To: [email protected]; Andrei Shakirin > > Subject: Re: extensions dynamically added/removed from exited bus > > > > > > On Aug 26, 2013, at 2:19 PM, Andrei Shakirin <[email protected]> > wrote: > > > > > 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? > > > > Not right now, no. We don't ever query the PolicyInterceptorProvider > things > > from the ConfiguredBeanLocator, although we probably could. Right now, > > we just query the PolicyInterceptorProviderLoader objects, but those > > are expected to kind of have a Bus constructor or similar that when > > created, would register all the PolicyInterceptorProvider things they know > about. > > > > Your best bet right now is to have an OSGi service registered as a > > BusCreationListener that when the Bus is created, would simply do: > > > > void busCreated(Bus b) { > > > > b.getExtension(PolicyInterceptorProviderRegistry.class).register(..... > > .); > > } > > > > to register your PolicyInterceptorProvider (which can be created in > > the OSGi context or whatever). > > > > > > Dan > > > > > > > > > > > > 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.SecurityConte > > >>> xt In 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 > > > > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog Talend Community Coder - > > http://coders.talend.com
