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