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 Tue, 01 Oct 2013 16:26:53 GMT

On Oct 1, 2013, at 10:40 AM, Andrei Shakirin <ashakirin@talend.com> 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:ashakirin@talend.com]
>> Sent: Donnerstag, 12. September 2013 10:20
>> To: Daniel Kulp; dev@cxf.apache.org
>> 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:dkulp@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 <ashakirin@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:dkulp@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 <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.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: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
>>>> 
>>> 
>>> --
>>> 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