Hi. Sorry, I may have caused more confusion!. You are correct that if the blueprint registry is used, it will create a proxy, and the service can come and go in the background without any issues. The issue on this ticket is to do with the OsgiServiceRegistry in camel. When camel tries to lookup a component it goes to its registry. This is typically a composite registry which looks up a chain of other registries. When using camel through blueprint the chain is:
OsgiServiceRegistry -> BlueprintContainerRegistry The OsgiServiceRegistry does not use blueprint in any way and looks up services in the actual OSGi registry using BundleContext.getService(). It uses the 'name' as the interface to lookup. As the camel OsgiServiceRegistry is first in the chain it will always be checked first. If it can't get the service, it will return null and the blueprint registry will be called. The examples below describe the behaviour: For each scenario I have exported an OSGI service with the interface 'com.test.camel.test.Hello'. <b>Scenario 1</b> If I use the following blueprint, the blueprint registry is used and the service is therefore a proxy: <raw> <reference id="helloBean" interface="com.test.camel.test.Hello" /> <camelContext id="blueprintContext" trace="false" xmlns="http://camel.apache.org/schema/blueprint";> <route id="timerToLog"> <from uri="timer:foo?period=1000" /> <setBody> <method ref="helloBean" method="hello" /> </setBody> <log loggingLevel="INFO" message="The message contains ${body}" /> </route> </camelContext> </raw> <b>Scenario 2</b> If I use the following route the OSGi registry is used and a direct reference to the bean in the OSGI registry is obtained via the OSGIServiceRegistry in camel. <raw> <camelContext id="blueprintContext" trace="false" xmlns="http://camel.apache.org/schema/blueprint";> <route id="timerToLog"> <from uri="timer:foo?period=1000" /> <setBody> <method ref="com.test.camel.test.Hello" method="hello" /> </setBody> <log loggingLevel="INFO" message="The message contains ${body}" /> </route> </camelContext> </raw> <b>Scenario 3</b> If I lookup up a bean name that is available in both registries then I will use the OsgiServiceRegistry, and I will not get a blueprint proxy. <raw> <reference id="com.test.camel.test.Hello" interface="com.test.camel.test.Hello" /> <camelContext id="blueprintContext" trace="false" xmlns="http://camel.apache.org/schema/blueprint";> <route id="timerToLog"> <from uri="timer:foo?period=1000" /> <setBody> <method ref="com.test.camel.test.Hello" method="hello" /> </setBody> <log loggingLevel="INFO" message="The message contains ${body}" /> </route> </camelContext> </raw> The OsgiServiceRegistry currently caches the service object so if the bundle exporting com.test.camel.test.Hello restarts, then I think the route will fail, but I have not tested this. So I think there are two potential issues: 1. The OsgiServiceRegistry needs to track services. 2. I think the BlueprintContainerRegistry should be first in the chain before the OsgiServiceRegistry. This will mean if the service / bean is present in blueprint it will always take predence over the bean in the OsgiServiceRegistry. On Wed, Feb 10, 2016 at 8:01 AM, Christian Schneider < ch...@die-schneider.net> wrote: > If you inject a blueprint reference to a service into a RouteBuilder class > then I would expect that the camel registry is not involved at all > and you would be able to use the service proxy injected by blueprint > inside the route. > > When the service disappears the blueprint proxy should run into > ServiceUnavailableException. > > @Claus: Can you confirm this or am I overlooking something? > This is related to this issue > https://issues.apache.org/jira/browse/CAMEL-9570 > > Christian > > > On 09.02.2016 20:32, Quinn Stevenson wrote: > >> In reference to the Blueprint proxy - if I use the Camel Bean component >> to call the service (i.e. to( “bean://my-bean” ), and I do NOT inject the >> service reference into the route builder, I get the dynamic swap of the >> service implementation. That (along with reading the Blueprint specs) lead >> to me to believe that the service proxy isn’t swapped - just the underlying >> service reference. >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
