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):

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

Reply via email to