Here's one little interesting tid bit. But my BundleListner is notified when the bundle is actually restarted or uninstalled. But the update-strategy=reload is not causing a bundle starting/stopping event to be sent.
Maybe as designed but I'll have to dig a bit more. Or it may be a bug. On Sat, Feb 27, 2016 at 2:48 PM, Brad Johnson <brad.john...@mediadriver.com> wrote: > Quinn, > > So thanks for the heads up on that. I probably will use the > ServiceFactory mechanism to make this work right. > > On Sat, Feb 27, 2016 at 2:32 PM, Brad Johnson < > brad.john...@mediadriver.com> wrote: > >> Yeah, I'm obviously going to have to try another mechanic. This current >> mechanism using the OSGi framework to register services works fine but it >> will not update. >> >> The first two lines are from a bundle getting the class name and >> registering it via OSGi. >> Registering: >> JBossFuse:karaf@root> Setting clazz: >> foo.internal.impl.InvoiceDocumentServiceImpl >> Instantiating the InvoiceDocumentServiceImpl >> >> This is in the receiving bundle getting the registered service fine. >> Interface type: foo.api.InvoiceDocumentService >> Interface type: org.apache.aries.proxy.weaving.WovenProxy >> >> Changing the name triggering reload. >> Setting clazz: foo.internal.test.InvoiceDocumentServiceTestStub >> >> But the old proxied class is still being used by the client and I'm not >> receiving BundleEvents in my BundleListener on the side that registered >> it. It may be because I'm using the OSGi framework to do that and not >> blueprint or camel's registries specifically. >> >> On Sat, Feb 27, 2016 at 2:02 PM, Quinn Stevenson < >> qu...@pronoia-solutions.com> wrote: >> >>> I’m pretty sure that’s how the Blueprint proxy works. >>> >>> You can use Blueprint to reference services exposed via pure OSGi, >>> Declarative Services and Blueprint - all of them are proxied. So the proxy >>> would have to be on the caller, not the server. >>> >>> You may be able to do what you’re after by registering a factory as a >>> service, and then calling a method on your factory to return the object you >>> want - just a thought. >>> >>> >>> > On Feb 27, 2016, at 12:56 PM, Brad Johnson < >>> brad.john...@mediadriver.com> wrote: >>> > >>> > Your observation about the caller being the proxied side is >>> interesting. I >>> > hadn't really thought about it before. Conceptually I'd always assumed >>> > that it would be the registration that would proxy the >>> > interface/implementation and that whomever grabbed got that. When the >>> > service would change then the proxy could stay the same but the >>> internally >>> > delegated class would be different. Interesting. >>> > >>> > On Sat, Feb 27, 2016 at 1:30 PM, Brad Johnson < >>> brad.john...@mediadriver.com> >>> > wrote: >>> > >>> >> I think you're right from what I'm seeing. I'll probably have to >>> resort >>> >> to an Activator and register the service. I'm just making this so >>> that I >>> >> can change the cfg file and switch the internal implementation between >>> >> three different types: test, impl, or remote. Test just serves up >>> dummy >>> >> data, impl is what it sound like and remote is an implementation with >>> a >>> >> ProducerTemplate that in turn delegates calls to URIs for easy >>> >> distribution. >>> >> >>> >> I can make that easy enough if I just use a Class.forName on a passed >>> in >>> >> String and delegate to it but I'm trying to color within the lines. >>> >> >>> >> On Sat, Feb 27, 2016 at 1:18 PM, Quinn Stevenson < >>> >> qu...@pronoia-solutions.com> wrote: >>> >> >>> >>> I don’t believe the way the service is exposed has any bearing on >>> when a >>> >>> proxy is created - the proxy is created by the <reference ….>, not >>> the >>> >>> <service> >>> >>> >>> >>> Also, if you’re trying to achieve a service with the properties of an >>> >>> OSGi Service Factory (i.e. one service instance per calling bundle), >>> I >>> >>> don’t think what you have will work - you’ll wind up with a single >>> instance >>> >>> of the service in the container. See this JIRA for a little more >>> info as >>> >>> to why. https://issues.apache.org/jira/browse/KARAF-4284 >>> >>> <https://issues.apache.org/jira/browse/KARAF-4284> >>> >>> >>> >>> <https://issues.apache.org/jira/browse/KARAF-4284?filter=-2> >>> >>>> On Feb 26, 2016, at 2:35 PM, Brad Johnson < >>> brad.john...@mediadriver.com> >>> >>> wrote: >>> >>>> >>> >>>> Just a quick follow up to that question, the class is not proxied in >>> >>> CBTS >>> >>>> but that may be an impedance mismatch between the test harness and >>> an >>> >>>> actual OSGi container and not indicative of how it will be handled >>> by >>> >>>> blueprint in Karaf. >>> >>>> >>> >>>> On Fri, Feb 26, 2016 at 3:23 PM, Ranx <brad.john...@mediadriver.com >>> > >>> >>> wrote: >>> >>>> >>> >>>>> If I create a service factory instantiated in blueprint like this: >>> >>>>> >>> >>>>> <bean id="service" class="fo.bar.ServiceFactory" >>> >>>>> factory-method="createService" > >>> >>>>> <argument value="${serviceClassImpl}"/> >>> >>>>> >>> >>>>> </bean> >>> >>>>> <service ref="service" interface="foo.api.MyOSGiService" /> >>> >>>>> >>> >>>>> And inside the factory just do a Class.forName to instantiate and >>> >>> return >>> >>>>> it, >>> >>>>> will the service reference itself be proxied? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> View this message in context: >>> >>>>> http://camel.465427.n5.nabble.com/ServiceFactory-tp5778336.html >>> >>>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>> >>>>> >>> >>> >>> >>> >>> >> >>> >>> >> >
