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.SecurityContextIn
>>> 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
