If I’m understanding this correctly, you’re suggesting a proxy around the references for ALL services - whether Blueprint has already proxied them or not. Am I understanding you correctly? If I am, it seems a bit wasteful to re-do what Blueprint is already doing for us.
The other really strange part was when I brought the Bean Component into the mix. If I didn’t inject the reference into the route building and then called the bean using to( “bean://..” ), I’d get the ServiceUnavailableException I expect. But just injecting the reference breaks the behavior - even when use the Bean Component. I have some other strange examples of what works and what doesn’t if they’d help. I didn’t put them in the ticket because I didn’t want to confuse matters. > On Feb 10, 2016, at 8:15 AM, Richard Davidson <richard.davidson...@gmail.com> > wrote: > > Yes I agree. Creating a proxy like blueprint which wraps a service tracker > is the best option as it allows other beans in the context to keep the > reference to the service. Otherwise the beans would need to be totally > stateless and lookup the registry every time. > > On Wed, Feb 10, 2016 at 2:55 PM, Christian Schneider < > ch...@die-schneider.net> wrote: > >> Hi Richard, >> >> I thought the issue was created by you but it was by Quinn. >> >> I think we really have to avoid caching services. Especially as this can >> cause problems with classloader cleanup when a bundle is uninstalled. >> So I think we either need to put a proxy into the service registry like in >> blueprint or we need to react on the event when the service is removed and >> clean it from the registry. >> >> Christian >> >> >> On 10.02.2016 15:49, Richard Davidson wrote: >> >>> 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 >>>> >>>> >>>> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >>
