cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: extensions dynamically added/removed from exited bus
Date Mon, 26 Aug 2013 18:03:03 GMT

On Aug 26, 2013, at 2:00 PM, Andrei Shakirin <ashakirin@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.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:dkulp@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 <ashakirin@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:dkulp@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 <irisdingbj@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
>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>>> http://coders.talend.com
>>> 
>> 
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>> http://coders.talend.com
> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message