Hi Christian, The original ticket was not logged by me, I just commented on the behaviour. The original issue described at the start of the ticket in which the service object is being cached exists for scenario 2 and scenario 3. Both these scenarios find the bean in the OsgiServiceRegistry, so the BlueprintContainerRegistry is not used.
On Wed, Feb 10, 2016 at 1:47 PM, Christian Schneider < ch...@die-schneider.net> wrote: > Hi Richard, > > now I understand your problem. So the problem is only with Scenario 3. > Can you update the issue to reflect this? > > So does the example you mentioned in the issue (which would probably be > scenario4) really not work? > I am pretty sure it should work. > > Christian > > > On 10.02.2016 12:51, Richard Davidson wrote: > >> 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 >>> >>> >>> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
