Richard - I’ll pull up my test project in the morning and put some more examples in the JIRA ticket. The ticket I created for this is https://issues.apache.org/jira/browse/CAMEL-9570
> On Feb 10, 2016, at 5:10 PM, Richard Davidson <richard.davidson...@gmail.com> > wrote: > > Quinn, regarding the other issues, it would be good to get as many examples > of the issues as possible. I plan have a go at fixing this tomorrow evening > so. Is there a JIRA ticket for this issue, or has it just been a discussion > on the mailing list? > > > On Thu, Feb 11, 2016 at 12:05 AM, Richard Davidson < > richard.davidson...@gmail.com> wrote: > >> No I plan to only proxy the service if it is available in the camel >> OsgiServiceRegistry and therefore not using blueprint. That way it can >> change in the background. >> Beans that are obtained in the BlueprintContainer registry will have a >> blueprint proxy and will be unchanged from what they where before. >> >> Thanks, >> Richard >> >> On Wed, Feb 10, 2016 at 11:55 PM, Quinn Stevenson < >> qu...@pronoia-solutions.com> wrote: >> >>> 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 >>>>> >>>>> >>> >>> >>
