You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2013/08/01 00:53:05 UTC
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
Re: extensions dynamically added/removed from exited bus
Posted by iris ding <ir...@gmail.com>.
Thanks a lot, Daniel!
--
View this message in context: http://cxf.547215.n5.nabble.com/extensions-dynamically-added-removed-from-exited-bus-tp5730582p5732472.html
Sent from the cxf-dev mailing list archive at Nabble.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
RE: extensions dynamically added/removed from exited bus
Posted by Andrei Shakirin <as...@talend.com>.
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 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.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: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 Andrei Shakirin <as...@talend.com>.
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?
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.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: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
Re: extensions dynamically added/removed from exited bus
Posted by Daniel Kulp <dk...@apache.org>.
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.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 <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
RE: extensions dynamically added/removed from exited bus
Posted by Andrei Shakirin <as...@talend.com>.
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: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
Re: extensions dynamically added/removed from exited bus
Posted by Daniel Kulp <dk...@apache.org>.
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
RE: extensions dynamically added/removed from exited bus
Posted by Andrei Shakirin <as...@talend.com>.
Hi Dan,
> 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?
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