cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <ashaki...@talend.com>
Subject RE: extensions dynamically added/removed from exited bus
Date Mon, 26 Aug 2013 18:19:52 GMT
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 <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.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 <ashakirin@talend.com>
> wrote:
> >>
> >>>> If the extensions are not really loaded via a
> >>>> META-INF/bus-extension.txt
> >> and
> >>>> instead are OSGi services, you may be able to accomplish a bit more.
> >> When
> >>>> the bundle stops and the service is stopped, it should be able to
> >>>> get a blueprint lifecycle event and then go ahead an unregister
> >>>> anything that is may have registered, but I'm not 100% sure that
> >>>> would work completely correctly.
> >>>
> >>> I know from Christian that you have added new functionality to
> >>> register
> >> extensions as OSGi services (not via META-INF/bus-extension.txt).
> >>> Could you point on test or sample how to do that?
> >>
> >> Just register your OSGi service as normal, but use the appropriate
> >> CXF interface as the interface for your exposed OSGi service.  That really
> should
> >> be all you need to do.   When the runtime calls into the Bus to get the
> >> extension of that interface (either bus.getExtension(Interface.class)
> >> or via the ConfiguredBeanLocator), it  should find it in the OSGi services.
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> Regards,
> >>> Andrei.
> >>>
> >>>> -----Original Message-----
> >>>> From: Daniel Kulp [mailto:dkulp@apache.org]
> >>>> Sent: Donnerstag, 1. August 2013 00:53
> >>>> To: dev@cxf.apache.org; iris ding
> >>>> Subject: Re: extensions dynamically added/removed from exited bus
> >>>>
> >>>>
> >>>> On Jul 29, 2013, at 5:17 AM, iris ding <irisdingbj@gmail.com>
wrote:
> >>>>
> >>>>> Hi ,
> >>>>>
> >>>>> Can we think CXF will not support such usage or in other words,
> >>>>> CXF has not taken such function into consideration from it's
> >>>>> initial design and such use cases should not be encouraged in CXF
> >>>>> -- If user want to make new/removed extensions take effect in
> >>>>> existed bus, they need to re-create the bus, Is this understanding
> right?
> >>>>
> >>>> Pretty much yes.  Since extensions can do all kinds of things (set
> >>>> properties, add interceptors, etc...) which would be difficult to
> >>>> "undo", it's not something we've tackled.
> >>>>
> >>>> If the extensions are not really loaded via a
> >>>> META-INF/bus-extension.txt
> >> and
> >>>> instead are OSGi services, you may be able to accomplish a bit more.
> >> When
> >>>> the bundle stops and the service is stopped, it should be able to
> >>>> get a blueprint lifecycle event and then go ahead an unregister
> >>>> anything that is may have registered, but I'm not 100% sure that
> >>>> would work completely correctly.
> >>>>
> >>>>
> >>>> --
> >>>> Daniel Kulp
> >>>> dkulp@apache.org - http://dankulp.com/blog Talend Community
> Coder -
> >>>> http://coders.talend.com
> >>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> >> http://coders.talend.com
> >
> 
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com


Mime
View raw message