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 Thu, 12 Sep 2013 08:20:09 GMT
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.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 <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


Mime
View raw message