You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andrei Shakirin <as...@talend.com> on 2013/09/12 10:20:09 UTC
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 <as...@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 <as...@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: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 <as...@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 <ir...@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
Re: extensions dynamically added/removed from exited bus
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 1, 2013, at 10:40 AM, Andrei Shakirin <as...@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 <as...@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 <as...@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
>>>>>>> <as...@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 <ir...@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
RE: extensions dynamically added/removed from exited bus
Posted by Andrei Shakirin <as...@talend.com>.
Hi Dan,
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?
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 <as...@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 <as...@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
> > >>>> <as...@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 <ir...@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