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
