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. > >>>>> > >>> > >>> > >> > >
