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