Hi Dan, Just confirm that proposed solution works!
Thanks, Andrei. > -----Original Message----- > From: Daniel Kulp [mailto:dk...@apache.org] > Sent: Montag, 26. August 2013 20:40 > To: dev@cxf.apache.org; Andrei Shakirin > Subject: Re: extensions dynamically added/removed from exited bus > > > On Aug 26, 2013, at 2:19 PM, Andrei Shakirin <ashaki...@talend.com> 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:dk...@apache.org] > >> Sent: Montag, 26. August 2013 20:03 > >> To: Andrei Shakirin > >> Cc: dev@cxf.apache.org > >> Subject: Re: extensions dynamically added/removed from exited bus > >> > >> > >> On Aug 26, 2013, at 2:00 PM, Andrei Shakirin <ashaki...@talend.com> > 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.SecurityContext > >>> 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:dk...@apache.org] > >>>> Sent: Freitag, 23. August 2013 15:29 > >>>> To: dev@cxf.apache.org; Andrei Shakirin > >>>> Subject: Re: extensions dynamically added/removed from exited bus > >>>> > >>>> > >>>> On Aug 23, 2013, at 8:53 AM, Andrei Shakirin <ashaki...@talend.com> > >> 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:dk...@apache.org] > >>>>>> Sent: Donnerstag, 1. August 2013 00:53 > >>>>>> To: dev@cxf.apache.org; iris ding > >>>>>> Subject: Re: extensions dynamically added/removed from exited > bus > >>>>>> > >>>>>> > >>>>>> On Jul 29, 2013, at 5:17 AM, iris ding <irisdin...@gmail.com> 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 > >>>>>> dk...@apache.org - http://dankulp.com/blog Talend Community > >> Coder - > >>>>>> http://coders.talend.com > >>>>> > >>>> > >>>> -- > >>>> Daniel Kulp > >>>> dk...@apache.org - http://dankulp.com/blog Talend Community > Coder - > >>>> http://coders.talend.com > >>> > >> > >> -- > >> Daniel Kulp > >> dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > >> http://coders.talend.com > > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
