On Oct 1, 2013, at 10:40 AM, Andrei Shakirin <[email protected]> wrote:
> 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? The Karaf command have a list-busses thing that can list all the busses that have been created. If you look into the code for that, you should be able to see how it's done. I think it's just looking up all the osgi services that implement Bus.class. Dan > > 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 > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
