Yeah, thanks. That worked spankin'. I'm still curious about why an update reload didn't fire any OSGi bundle events though.
Brad On Sat, Feb 27, 2016 at 3:02 PM, Brad Johnson <brad.john...@mediadriver.com> wrote: > 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. >>>> >>>>> >>>> >>> >>>> >>> >>>> >> >>>> >>>> >>> >> >
