You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Tim Jones <ti...@mccarthy.co.nz> on 2016/02/09 01:31:19 UTC
OsgiServiceRegistry caching service references, why?
I have looked at the code in org.apache.camel.core.osgi.OsgiServiceRegistry
(camel-core-osgi-2.15.4) and it appears to cache the service references.
This means that if I uninstall/install the bundle supplying the service it
wont automagically 'pick up' the new service.
For what reason(s) are the service references cached?
Note - after modifying OsgiServiceRegistry and removing the cache a new
service is picked up and behaves more like I would expect in a dynamic OSGi
environment.
--
View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
Ok. I will submit a pull request at some stage over the next few days.
On Tue, Feb 9, 2016 at 9:31 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> <ri...@gmail.com> wrote:
> > Hi,
> >
> > Instead of the cache containing the actual service objects it could it
> > contain a org.osgi.util.tracker.ServiceTracker. This would then cache and
> > track the service internally. Each time the service is requested via the
> > registry, #ServiceTracker.getService() could be called. Let me know your
> > thoughts, and if people agree I could try to create a patch.
> >
>
> Yeah we use service tracker to track components and whatnot.
>
> I have said it many times, we love contributions
> http://camel.apache.org/contributing
>
> >
> > On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> >> Hi
> >>
> >> Yeah it was created that way - i guess maybe the though was that osgi
> >> reference lookup is expensive?
> >>
> >> I guess we can reach out to the OSGi folks and see what they say. It
> >> would make the code simpler without a local cache.
> >>
> >>
> >> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
> >> > I have looked at the code in
> >> org.apache.camel.core.osgi.OsgiServiceRegistry
> >> > (camel-core-osgi-2.15.4) and it appears to cache the service
> references.
> >> > This means that if I uninstall/install the bundle supplying the
> service
> >> it
> >> > wont automagically 'pick up' the new service.
> >> >
> >> > For what reason(s) are the service references cached?
> >> >
> >> > Note - after modifying OsgiServiceRegistry and removing the cache a
> new
> >> > service is picked up and behaves more like I would expect in a dynamic
> >> OSGi
> >> > environment.
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >>
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> >> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Tim Jones <ti...@mccarthy.co.nz>.
I am not sure if I completely understand the conversation but please note my
original issue was found using camel-scr i.e. Declarative Services so please
make sure any solution is compatible.
--
View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5777553.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Tim Jones <ti...@mccarthy.co.nz>.
Quinn,
I have sent an email to you with a link to Dropbox with the necessary files
--
View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5778142.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Tim -
I can’t seem to get the patch to create the projects correctly. Could you put a zip or something out there?
> On Feb 23, 2016, at 8:32 AM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> Thank You Tim - I’ll take a look.
>
> No - the sample I put together is using camel-scr. When a @Reference injected service goes away, the camel context is stopped. When it comes back, the context is restarted - so I’m not seeing any caching.
>
> It’s part of a much larger sample I was working on - I’ll see if I can distill it down and get it to you if you’re interested.
>
>
>> On Feb 22, 2016, at 9:23 PM, Tim Jones <ti...@mccarthy.co.nz> wrote:
>>
>> Hi Quinn,
>>
>> I have added a patch as part of
>> https://issues.apache.org/jira/browse/CAMEL-9631 which does not contain a
>> solution but only an integrated test to highlight the issue.
>>
>> I am puzzled as to how you are able to pick up the new implementation, more
>> than likely I am doing something wrong (you might be able to pick the eyes
>> out of the patch), but hey if it works then great. You aren't running a
>> refresh command after you start the bundle are you?
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5778084.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thank You Tim - I’ll take a look.
No - the sample I put together is using camel-scr. When a @Reference injected service goes away, the camel context is stopped. When it comes back, the context is restarted - so I’m not seeing any caching.
It’s part of a much larger sample I was working on - I’ll see if I can distill it down and get it to you if you’re interested.
> On Feb 22, 2016, at 9:23 PM, Tim Jones <ti...@mccarthy.co.nz> wrote:
>
> Hi Quinn,
>
> I have added a patch as part of
> https://issues.apache.org/jira/browse/CAMEL-9631 which does not contain a
> solution but only an integrated test to highlight the issue.
>
> I am puzzled as to how you are able to pick up the new implementation, more
> than likely I am doing something wrong (you might be able to pick the eyes
> out of the patch), but hey if it works then great. You aren't running a
> refresh command after you start the bundle are you?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5778084.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Tim Jones <ti...@mccarthy.co.nz>.
Hi Quinn,
I have added a patch as part of
https://issues.apache.org/jira/browse/CAMEL-9631 which does not contain a
solution but only an integrated test to highlight the issue.
I am puzzled as to how you are able to pick up the new implementation, more
than likely I am doing something wrong (you might be able to pick the eyes
out of the patch), but hey if it works then great. You aren't running a
refresh command after you start the bundle are you?
--
View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5778084.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Tim -
Did you get a sample put together?
I tried to reproduce what you’re seeing, but I can’t seem to make it happen.
I created a camel-scr route (using the camel-archetype-scr), added a reference to an OSGi service, and created two bundles that register implementations of this service (they just log different stuff).
I deploy everything, start one of the service bundles and the camel-scr route. Then I stop the active service bundle and start the other one and the route picks-up the new implementation. I guess this could be because camel-scr stops the route when the dependency goes away and then restarts it once it comes back.
How exactly are you calling/using the service?
> On Feb 11, 2016, at 1:06 PM, Tim Jones <ti...@mccarthy.co.nz> wrote:
>
> Quinn,
>
> I will post something on Monday when back at work. However it shouldn't be
> hard to replicate if you uninstall the bundle providing the service and
> install a modified bundle offering the same service but with different
> functionality (e.g. perhaps just output something different to the console).
> Because the service from the original bundle has been cached it will be that
> service that is called, not the service from the newly installed modified
> bundle.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5777617.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Brad Johnson <br...@mediadriver.com>.
Part of the issue with crafting good examples or good code for that matter
are the exigencies of testing with PojoSR and then using the same code in
development. I'll commonly work around PojoSR only to find code doesn't
work when deployed in Karaf or vice versa. Since tests can't work across
multiple camel contexts it means any test stub bundles have to work without
camel whereas the actual implementations will likely rely on it heavily. So
any classloader/proxy differences are going to rear their ugly heads.
A small example of some of the differences that arise are the use of
private packages in bundles with PojoSR. Note that I've commented the
private out because if that is in there PojoSR will not find the class to
bootstrap to the service.
<configuration>
<manifestLocation>target/META-INF</manifestLocation>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<!--
<Private-Package>${project.groupId}.${project.artifactId}.internal*</Private-Package>
-->
</instructions>
</configuration>
For example:
<service ref="myService" interface="org.foo.MyService" />
<bean id="myService" class="org.foo.internal.FooTestStubServiceImpl"/>
That will fail to load if is used in test scope in another project if the
FooTestStubServiceImpl is actually private. In Karaf, of course, it would
be correctly registered. Taking out the private statement will now
bootstrap the test correctly and the injected type will be of type
com.sun.proxy.$Proxy40.
But for that test to have worked we need to break the encapsulation of the
bundle and are not relying on correctly constructed bundle whose internals
are hidden from the world. Obviously our actual implementation bundle
would be structured differently. And that means it is going to be
fundamentally different in its construction.
That may seem a minor thing and in many cases it is but there are a lot of
these little gotchas around that mean that the way one tests is
fundamentally out of synch with the way one bundles as uses code. It also
starts to drive design decisions in awkward directions. One changes how
one makes POMs, bundles, and tests and end up with bundles that aren't
truly swappable or that have differences. I can't tell you how many times
I go to deploy and have to change blueprint, POMs, and write @Ignore on
tests to get things working. Then I have to go back and rewrite all tests
to make them work.
This becomes exacerbated by the multiple classloader mechanisms and proxy
mechanics that exist in Camel/Karaf/Blueprint. It becomes difficult to
think about design when questioning how an annotation is going to be dealt
with during classloading during CBTS testing versus how it is going to be
dealt with during actual deployment.
On Thu, Feb 11, 2016 at 2:06 PM, Tim Jones <ti...@mccarthy.co.nz> wrote:
> Quinn,
>
> I will post something on Monday when back at work. However it shouldn't be
> hard to replicate if you uninstall the bundle providing the service and
> install a modified bundle offering the same service but with different
> functionality (e.g. perhaps just output something different to the
> console).
> Because the service from the original bundle has been cached it will be
> that
> service that is called, not the service from the newly installed modified
> bundle.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5777617.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Tim Jones <ti...@mccarthy.co.nz>.
Quinn,
I will post something on Monday when back at work. However it shouldn't be
hard to replicate if you uninstall the bundle providing the service and
install a modified bundle offering the same service but with different
functionality (e.g. perhaps just output something different to the console).
Because the service from the original bundle has been cached it will be that
service that is called, not the service from the newly installed modified
bundle.
--
View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5777617.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I don’t know the guts of how all this works, but Tim’s question/comment concerns me a little because we use camel-scr currently and we haven’t seen any issues with dynamic service behavior that I know of. I’ve asked a colleague of mine to check and make sure, but I thought camel-scr was working fine for us.
It seems to me it would be appropriate to create another JIRA describing Tim’s issue. If one update corrects both issues, that’s great - but at lease we’ll know.
Tim - do you have a simple sample that demonstrates the issue?
> On Feb 11, 2016, at 3:00 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I think that should work fine. Are you willing to create a pull request for this?
>
> Christian
>
>
> On 11.02.2016 01:05, Richard Davidson 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 <
>> quinn@pronoia-solutions.com> wrote:
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Christian Schneider <ch...@die-schneider.net>.
I think that should work fine. Are you willing to create a pull request
for this?
Christian
On 11.02.2016 01:05, Richard Davidson 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 <
> quinn@pronoia-solutions.com> wrote:
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: OsgiServiceRegistry caching service references, why?
Posted by Brad Johnson <br...@mediadriver.com>.
Richard,
I ran into similar issues recently when I was using services with route
builders. I'd see non-proxied hard classes showing up. Restarts on ;the
bundle(s) would then cause failures because the service class was being
referenced. It makes sense now that I'm following the discussion since I
was unaware of the difference in the proxying mechanics going on between
OSGi (which I guess are non-existent) and the Blueprint. I also
inadvertently ran into a similar issue with this when I misconfigured
something and the package scanner in the route builder jumped the tracks
and used the SU classloader. I'm not sure if that's what contribute to some
of the other bugs that Quinn has noticed as well.
https://issues.apache.org/jira/browse/CAMEL-9562
It certainly does seem to be a loophole that needs to be closed or at least
closeable.
The only real solution I've found to any of this is to fall back to using
blueprint almost exclusively and to stay away from route builders,
annotations and the Java DSL in general. That's unfortunate as I'd prefer
to work in the Java DSL as would my clients but keeping the stars and moons
aligned is too difficult.
On Wed, Feb 10, 2016 at 6:10 PM, Richard Davidson <
richard.davidson.uk@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.uk@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 <
> > quinn@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.uk@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 <
> >> > chris@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 <
> >> >>> chris@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 <
> >> >>>>> chris@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
> >> >>
> >> >>
> >>
> >>
> >
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <ri...@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.uk@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 <
>> quinn@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.uk@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 <
>>>> chris@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 <
>>>>>> chris@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 <
>>>>>>>> chris@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
>>>>>
>>>>>
>>>
>>>
>>
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
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.uk@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 <
> quinn@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.uk@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 <
>> > chris@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 <
>> >>> chris@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 <
>> >>>>> chris@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
>> >>
>> >>
>>
>>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
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 <
quinn@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.uk@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 <
> > chris@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 <
> >>> chris@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 <
> >>>>> chris@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
> >>
> >>
>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <ri...@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 <
> chris@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 <
>>> chris@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 <
>>>>> chris@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
>>
>>
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
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 <
chris@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 <
>> chris@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 <
>>>> chris@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
>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <
> chris@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 <
>>> chris@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
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
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 <
chris@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 <
>> chris@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
>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <
> chris@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
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
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 <
chris@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
>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: OsgiServiceRegistry caching service references, why?
Posted by Brad Johnson <br...@mediadriver.com>.
That's my understanding of how it should work as well. Obviously invoking
a proxy with no implementation would be a problem but the swap should
happen without pain.
On Tue, Feb 9, 2016 at 1:32 PM, Quinn Stevenson <quinn@pronoia-solutions.com
> 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.
>
> > On Feb 9, 2016, at 10:32 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
> >
> > Richard, how much of a performance hit do you think it would be to do a
> > look up of the service via a tracker? Since I live in I/O bound
> > environments that sort of hit is usually acceptable as long as it isn't
> too
> > extreme. That's especially true if it brings better stability and
> dynamic
> > class handling. If I'm understanding the proposed mechanics this would
> > make the hot swapping and service references more stable. When
> > Camel/blueprint/OSGi proxy and interface to a concrete implementation
> and a
> > hot swap happens, does it create a new proxy or does it swap the
> > implementation that the proxy holds? The latter would be a preferred
> > mechanism I'd think. The bundle holding the reference to a proxied
> service
> > then doesn't ever lose the reference since it is just pointing to the
> > proxy. But the internal implementation might be set to a different class
> > e.g. switching from a test stub bundle to an implementation bundle.
> >
> > If we are going to change any of the classloader mechanics please put
> > guards around the classloaders in blueprint so that we can have a setting
> > to short circuit some of the slop bucket classloading that goes on there.
> > From the comments in the code it was put in place to accommodate JBI but
> it
> > has resulted in some unpredictable behavior when loading
> > classes/services. That should be relatively easy and painless to put in
> > place. I've put a Jira ticket in for that as well. But if there is
> going
> > to be some work on the blueprint/osgi classloaders now would be a good
> time
> > to address that as well. A simple boolean with a strict OSGi mode that,
> > when set to true, disallows SU classloader mechanics but would be false
> by
> > default.
> >
> > Does OSGi manage the other registries? In other words, when I fire up a
> > context and it creates a simple registry in Camel is that simple registry
> > managed by the OSGi registry? Should it be? I haven't wandered into that
> > section of code.
> >
> > On Tue, Feb 9, 2016 at 9:53 AM, Quinn Stevenson <
> quinn@pronoia-solutions.com
> >> wrote:
> >
> >> That sounds good to me - I rely pretty heavily on the
> >> ServiceUnavailableException after the proxy times-out, so I didn’t want
> >> this behavior to change (or at least I need to know if it’s going to
> >> change).
> >>
> >> Is looking-up the service in the OSGi Registry expensive? I thought the
> >> OSGi internals cached those services for us.
> >>
> >>
> >>> On Feb 9, 2016, at 8:15 AM, Richard Davidson <
> >> richard.davidson.uk@gmail.com> wrote:
> >>>
> >>> I am not sure what the order the registries are chained together. I
> need
> >> to
> >>> test whether the blueprint or the OSGI registry is first, From looking
> at
> >>> the code:
> >>> {code}
> >>>
> >>> public static Registry wrapRegistry(CamelContext camelContext,
> >> Registry
> >>> registry, BundleContext bundleContext) {
> >>>
> >>> ObjectHelper.notNull(bundleContext, "BundleContext");
> >>>
> >>> LOG.debug("Setting up OSGi ServiceRegistry");
> >>>
> >>> OsgiServiceRegistry osgiServiceRegistry = new
> OsgiServiceRegistry(
> >>> bundleContext);
> >>>
> >>> // Need to clean up the OSGi service when camel context is
> closed.
> >>>
> >>> camelContext.addLifecycleStrategy(osgiServiceRegistry);
> >>>
> >>> CompositeRegistry compositeRegistry = new CompositeRegistry();
> >>>
> >>> compositeRegistry.addRegistry(osgiServiceRegistry);
> >>>
> >>> compositeRegistry.addRegistry(registry);
> >>>
> >>> return compositeRegistry;
> >>>
> >>> }
> >>> {code}
> >>>
> >>> I think the OSGI registry would be first in the chain as it is first in
> >> the
> >>> composite registry. If this is true then the the OSGI registry would be
> >>> checked first, and if it didn't exist in the OSGI registry then it
> would
> >>> try blueprint. I think this is wrong and the OSGI registry should be
> >> added
> >>> to the end of the chain, so blueprint etc is tried first. However
> making
> >>> this change would change existing functionality and could cause issues
> >> for
> >>> existing deployments.
> >>>
> >>> Another point to note is that the service tracker change only works of
> >> the
> >>> processor looks up the registry every-time to get the service. If it
> >> holds
> >>> on to the service reference and the service goes away, requests will
> >> fail.
> >>>
> >>> In my view adding service trackers to OsgiServiceRegistry is an
> >> improvement
> >>> on what exists today, but I would still strongly advise using blueprint
> >>> proxies instead, as the reference to the service can be cached in the
> >>> processor.
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <
> >> quinn@pronoia-solutions.com
> >>>> wrote:
> >>>
> >>>> I normally use Blueprint to use OSGi Services. In that case, I should
> >>>> wind up with a Blueprint service proxy. Would using a ServiceTracker
> >> with
> >>>> a Blueprint proxy be necessary? I think the Blueprint proxy already
> >> does
> >>>> that for me.
> >>>>
> >>>>
> >>>>> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>>>>
> >>>>> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> >>>>> <richard.davidson.uk@gmail.com <mailto:richard.davidson.uk@gmail.com
> >>
> >>>> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Instead of the cache containing the actual service objects it could
> it
> >>>>>> contain a org.osgi.util.tracker.ServiceTracker. This would then
> cache
> >>>> and
> >>>>>> track the service internally. Each time the service is requested via
> >> the
> >>>>>> registry, #ServiceTracker.getService() could be called. Let me know
> >>>> your
> >>>>>> thoughts, and if people agree I could try to create a patch.
> >>>>>>
> >>>>>
> >>>>> Yeah we use service tracker to track components and whatnot.
> >>>>>
> >>>>> I have said it many times, we love contributions
> >>>>> http://camel.apache.org/contributing <
> >>>> http://camel.apache.org/contributing>
> >>>>>
> >>>>>>
> >>>>>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Yeah it was created that way - i guess maybe the though was that
> osgi
> >>>>>>> reference lookup is expensive?
> >>>>>>>
> >>>>>>> I guess we can reach out to the OSGi folks and see what they say.
> It
> >>>>>>> would make the code simpler without a local cache.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz>
> >> wrote:
> >>>>>>>> I have looked at the code in
> >>>>>>> org.apache.camel.core.osgi.OsgiServiceRegistry
> >>>>>>>> (camel-core-osgi-2.15.4) and it appears to cache the service
> >>>> references.
> >>>>>>>> This means that if I uninstall/install the bundle supplying the
> >>>> service
> >>>>>>> it
> >>>>>>>> wont automagically 'pick up' the new service.
> >>>>>>>>
> >>>>>>>> For what reason(s) are the service references cached?
> >>>>>>>>
> >>>>>>>> Note - after modifying OsgiServiceRegistry and removing the cache
> a
> >>>> new
> >>>>>>>> service is picked up and behaves more like I would expect in a
> >> dynamic
> >>>>>>> OSGi
> >>>>>>>> environment.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> View this message in context:
> >>>>>>>
> >>>>
> >>
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> >>>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Claus Ibsen
> >>>>>>> -----------------
> >>>>>>> http://davsclaus.com @davsclaus
> >>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Claus Ibsen
> >>>>> -----------------
> >>>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> >>>>> Camel in Action 2: https://www.manning.com/ibsen2 <
> >>>> https://www.manning.com/ibsen2>
> >>>>
> >>
> >>
>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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.
> On Feb 9, 2016, at 10:32 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> Richard, how much of a performance hit do you think it would be to do a
> look up of the service via a tracker? Since I live in I/O bound
> environments that sort of hit is usually acceptable as long as it isn't too
> extreme. That's especially true if it brings better stability and dynamic
> class handling. If I'm understanding the proposed mechanics this would
> make the hot swapping and service references more stable. When
> Camel/blueprint/OSGi proxy and interface to a concrete implementation and a
> hot swap happens, does it create a new proxy or does it swap the
> implementation that the proxy holds? The latter would be a preferred
> mechanism I'd think. The bundle holding the reference to a proxied service
> then doesn't ever lose the reference since it is just pointing to the
> proxy. But the internal implementation might be set to a different class
> e.g. switching from a test stub bundle to an implementation bundle.
>
> If we are going to change any of the classloader mechanics please put
> guards around the classloaders in blueprint so that we can have a setting
> to short circuit some of the slop bucket classloading that goes on there.
> From the comments in the code it was put in place to accommodate JBI but it
> has resulted in some unpredictable behavior when loading
> classes/services. That should be relatively easy and painless to put in
> place. I've put a Jira ticket in for that as well. But if there is going
> to be some work on the blueprint/osgi classloaders now would be a good time
> to address that as well. A simple boolean with a strict OSGi mode that,
> when set to true, disallows SU classloader mechanics but would be false by
> default.
>
> Does OSGi manage the other registries? In other words, when I fire up a
> context and it creates a simple registry in Camel is that simple registry
> managed by the OSGi registry? Should it be? I haven't wandered into that
> section of code.
>
> On Tue, Feb 9, 2016 at 9:53 AM, Quinn Stevenson <quinn@pronoia-solutions.com
>> wrote:
>
>> That sounds good to me - I rely pretty heavily on the
>> ServiceUnavailableException after the proxy times-out, so I didn’t want
>> this behavior to change (or at least I need to know if it’s going to
>> change).
>>
>> Is looking-up the service in the OSGi Registry expensive? I thought the
>> OSGi internals cached those services for us.
>>
>>
>>> On Feb 9, 2016, at 8:15 AM, Richard Davidson <
>> richard.davidson.uk@gmail.com> wrote:
>>>
>>> I am not sure what the order the registries are chained together. I need
>> to
>>> test whether the blueprint or the OSGI registry is first, From looking at
>>> the code:
>>> {code}
>>>
>>> public static Registry wrapRegistry(CamelContext camelContext,
>> Registry
>>> registry, BundleContext bundleContext) {
>>>
>>> ObjectHelper.notNull(bundleContext, "BundleContext");
>>>
>>> LOG.debug("Setting up OSGi ServiceRegistry");
>>>
>>> OsgiServiceRegistry osgiServiceRegistry = new OsgiServiceRegistry(
>>> bundleContext);
>>>
>>> // Need to clean up the OSGi service when camel context is closed.
>>>
>>> camelContext.addLifecycleStrategy(osgiServiceRegistry);
>>>
>>> CompositeRegistry compositeRegistry = new CompositeRegistry();
>>>
>>> compositeRegistry.addRegistry(osgiServiceRegistry);
>>>
>>> compositeRegistry.addRegistry(registry);
>>>
>>> return compositeRegistry;
>>>
>>> }
>>> {code}
>>>
>>> I think the OSGI registry would be first in the chain as it is first in
>> the
>>> composite registry. If this is true then the the OSGI registry would be
>>> checked first, and if it didn't exist in the OSGI registry then it would
>>> try blueprint. I think this is wrong and the OSGI registry should be
>> added
>>> to the end of the chain, so blueprint etc is tried first. However making
>>> this change would change existing functionality and could cause issues
>> for
>>> existing deployments.
>>>
>>> Another point to note is that the service tracker change only works of
>> the
>>> processor looks up the registry every-time to get the service. If it
>> holds
>>> on to the service reference and the service goes away, requests will
>> fail.
>>>
>>> In my view adding service trackers to OsgiServiceRegistry is an
>> improvement
>>> on what exists today, but I would still strongly advise using blueprint
>>> proxies instead, as the reference to the service can be cached in the
>>> processor.
>>>
>>>
>>>
>>>
>>> On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <
>> quinn@pronoia-solutions.com
>>>> wrote:
>>>
>>>> I normally use Blueprint to use OSGi Services. In that case, I should
>>>> wind up with a Blueprint service proxy. Would using a ServiceTracker
>> with
>>>> a Blueprint proxy be necessary? I think the Blueprint proxy already
>> does
>>>> that for me.
>>>>
>>>>
>>>>> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>
>>>>> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
>>>>> <richard.davidson.uk@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Instead of the cache containing the actual service objects it could it
>>>>>> contain a org.osgi.util.tracker.ServiceTracker. This would then cache
>>>> and
>>>>>> track the service internally. Each time the service is requested via
>> the
>>>>>> registry, #ServiceTracker.getService() could be called. Let me know
>>>> your
>>>>>> thoughts, and if people agree I could try to create a patch.
>>>>>>
>>>>>
>>>>> Yeah we use service tracker to track components and whatnot.
>>>>>
>>>>> I have said it many times, we love contributions
>>>>> http://camel.apache.org/contributing <
>>>> http://camel.apache.org/contributing>
>>>>>
>>>>>>
>>>>>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Yeah it was created that way - i guess maybe the though was that osgi
>>>>>>> reference lookup is expensive?
>>>>>>>
>>>>>>> I guess we can reach out to the OSGi folks and see what they say. It
>>>>>>> would make the code simpler without a local cache.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz>
>> wrote:
>>>>>>>> I have looked at the code in
>>>>>>> org.apache.camel.core.osgi.OsgiServiceRegistry
>>>>>>>> (camel-core-osgi-2.15.4) and it appears to cache the service
>>>> references.
>>>>>>>> This means that if I uninstall/install the bundle supplying the
>>>> service
>>>>>>> it
>>>>>>>> wont automagically 'pick up' the new service.
>>>>>>>>
>>>>>>>> For what reason(s) are the service references cached?
>>>>>>>>
>>>>>>>> Note - after modifying OsgiServiceRegistry and removing the cache a
>>>> new
>>>>>>>> service is picked up and behaves more like I would expect in a
>> dynamic
>>>>>>> OSGi
>>>>>>>> environment.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>
>>>>
>> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
>>>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> http://davsclaus.com @davsclaus
>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2 <
>>>> https://www.manning.com/ibsen2>
>>>>
>>
>>
Re: OsgiServiceRegistry caching service references, why?
Posted by Brad Johnson <br...@mediadriver.com>.
Richard, how much of a performance hit do you think it would be to do a
look up of the service via a tracker? Since I live in I/O bound
environments that sort of hit is usually acceptable as long as it isn't too
extreme. That's especially true if it brings better stability and dynamic
class handling. If I'm understanding the proposed mechanics this would
make the hot swapping and service references more stable. When
Camel/blueprint/OSGi proxy and interface to a concrete implementation and a
hot swap happens, does it create a new proxy or does it swap the
implementation that the proxy holds? The latter would be a preferred
mechanism I'd think. The bundle holding the reference to a proxied service
then doesn't ever lose the reference since it is just pointing to the
proxy. But the internal implementation might be set to a different class
e.g. switching from a test stub bundle to an implementation bundle.
If we are going to change any of the classloader mechanics please put
guards around the classloaders in blueprint so that we can have a setting
to short circuit some of the slop bucket classloading that goes on there.
>From the comments in the code it was put in place to accommodate JBI but it
has resulted in some unpredictable behavior when loading
classes/services. That should be relatively easy and painless to put in
place. I've put a Jira ticket in for that as well. But if there is going
to be some work on the blueprint/osgi classloaders now would be a good time
to address that as well. A simple boolean with a strict OSGi mode that,
when set to true, disallows SU classloader mechanics but would be false by
default.
Does OSGi manage the other registries? In other words, when I fire up a
context and it creates a simple registry in Camel is that simple registry
managed by the OSGi registry? Should it be? I haven't wandered into that
section of code.
On Tue, Feb 9, 2016 at 9:53 AM, Quinn Stevenson <quinn@pronoia-solutions.com
> wrote:
> That sounds good to me - I rely pretty heavily on the
> ServiceUnavailableException after the proxy times-out, so I didn’t want
> this behavior to change (or at least I need to know if it’s going to
> change).
>
> Is looking-up the service in the OSGi Registry expensive? I thought the
> OSGi internals cached those services for us.
>
>
> > On Feb 9, 2016, at 8:15 AM, Richard Davidson <
> richard.davidson.uk@gmail.com> wrote:
> >
> > I am not sure what the order the registries are chained together. I need
> to
> > test whether the blueprint or the OSGI registry is first, From looking at
> > the code:
> > {code}
> >
> > public static Registry wrapRegistry(CamelContext camelContext,
> Registry
> > registry, BundleContext bundleContext) {
> >
> > ObjectHelper.notNull(bundleContext, "BundleContext");
> >
> > LOG.debug("Setting up OSGi ServiceRegistry");
> >
> > OsgiServiceRegistry osgiServiceRegistry = new OsgiServiceRegistry(
> > bundleContext);
> >
> > // Need to clean up the OSGi service when camel context is closed.
> >
> > camelContext.addLifecycleStrategy(osgiServiceRegistry);
> >
> > CompositeRegistry compositeRegistry = new CompositeRegistry();
> >
> > compositeRegistry.addRegistry(osgiServiceRegistry);
> >
> > compositeRegistry.addRegistry(registry);
> >
> > return compositeRegistry;
> >
> > }
> > {code}
> >
> > I think the OSGI registry would be first in the chain as it is first in
> the
> > composite registry. If this is true then the the OSGI registry would be
> > checked first, and if it didn't exist in the OSGI registry then it would
> > try blueprint. I think this is wrong and the OSGI registry should be
> added
> > to the end of the chain, so blueprint etc is tried first. However making
> > this change would change existing functionality and could cause issues
> for
> > existing deployments.
> >
> > Another point to note is that the service tracker change only works of
> the
> > processor looks up the registry every-time to get the service. If it
> holds
> > on to the service reference and the service goes away, requests will
> fail.
> >
> > In my view adding service trackers to OsgiServiceRegistry is an
> improvement
> > on what exists today, but I would still strongly advise using blueprint
> > proxies instead, as the reference to the service can be cached in the
> > processor.
> >
> >
> >
> >
> > On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <
> quinn@pronoia-solutions.com
> >> wrote:
> >
> >> I normally use Blueprint to use OSGi Services. In that case, I should
> >> wind up with a Blueprint service proxy. Would using a ServiceTracker
> with
> >> a Blueprint proxy be necessary? I think the Blueprint proxy already
> does
> >> that for me.
> >>
> >>
> >>> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <cl...@gmail.com> wrote:
> >>>
> >>> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> >>> <richard.davidson.uk@gmail.com <ma...@gmail.com>>
> >> wrote:
> >>>> Hi,
> >>>>
> >>>> Instead of the cache containing the actual service objects it could it
> >>>> contain a org.osgi.util.tracker.ServiceTracker. This would then cache
> >> and
> >>>> track the service internally. Each time the service is requested via
> the
> >>>> registry, #ServiceTracker.getService() could be called. Let me know
> >> your
> >>>> thoughts, and if people agree I could try to create a patch.
> >>>>
> >>>
> >>> Yeah we use service tracker to track components and whatnot.
> >>>
> >>> I have said it many times, we love contributions
> >>> http://camel.apache.org/contributing <
> >> http://camel.apache.org/contributing>
> >>>
> >>>>
> >>>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> Yeah it was created that way - i guess maybe the though was that osgi
> >>>>> reference lookup is expensive?
> >>>>>
> >>>>> I guess we can reach out to the OSGi folks and see what they say. It
> >>>>> would make the code simpler without a local cache.
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz>
> wrote:
> >>>>>> I have looked at the code in
> >>>>> org.apache.camel.core.osgi.OsgiServiceRegistry
> >>>>>> (camel-core-osgi-2.15.4) and it appears to cache the service
> >> references.
> >>>>>> This means that if I uninstall/install the bundle supplying the
> >> service
> >>>>> it
> >>>>>> wont automagically 'pick up' the new service.
> >>>>>>
> >>>>>> For what reason(s) are the service references cached?
> >>>>>>
> >>>>>> Note - after modifying OsgiServiceRegistry and removing the cache a
> >> new
> >>>>>> service is picked up and behaves more like I would expect in a
> dynamic
> >>>>> OSGi
> >>>>>> environment.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>
> >>
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> >>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Claus Ibsen
> >>>>> -----------------
> >>>>> http://davsclaus.com @davsclaus
> >>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> -----------------
> >>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> >>> Camel in Action 2: https://www.manning.com/ibsen2 <
> >> https://www.manning.com/ibsen2>
> >>
>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
That sounds good to me - I rely pretty heavily on the ServiceUnavailableException after the proxy times-out, so I didn’t want this behavior to change (or at least I need to know if it’s going to change).
Is looking-up the service in the OSGi Registry expensive? I thought the OSGi internals cached those services for us.
> On Feb 9, 2016, at 8:15 AM, Richard Davidson <ri...@gmail.com> wrote:
>
> I am not sure what the order the registries are chained together. I need to
> test whether the blueprint or the OSGI registry is first, From looking at
> the code:
> {code}
>
> public static Registry wrapRegistry(CamelContext camelContext, Registry
> registry, BundleContext bundleContext) {
>
> ObjectHelper.notNull(bundleContext, "BundleContext");
>
> LOG.debug("Setting up OSGi ServiceRegistry");
>
> OsgiServiceRegistry osgiServiceRegistry = new OsgiServiceRegistry(
> bundleContext);
>
> // Need to clean up the OSGi service when camel context is closed.
>
> camelContext.addLifecycleStrategy(osgiServiceRegistry);
>
> CompositeRegistry compositeRegistry = new CompositeRegistry();
>
> compositeRegistry.addRegistry(osgiServiceRegistry);
>
> compositeRegistry.addRegistry(registry);
>
> return compositeRegistry;
>
> }
> {code}
>
> I think the OSGI registry would be first in the chain as it is first in the
> composite registry. If this is true then the the OSGI registry would be
> checked first, and if it didn't exist in the OSGI registry then it would
> try blueprint. I think this is wrong and the OSGI registry should be added
> to the end of the chain, so blueprint etc is tried first. However making
> this change would change existing functionality and could cause issues for
> existing deployments.
>
> Another point to note is that the service tracker change only works of the
> processor looks up the registry every-time to get the service. If it holds
> on to the service reference and the service goes away, requests will fail.
>
> In my view adding service trackers to OsgiServiceRegistry is an improvement
> on what exists today, but I would still strongly advise using blueprint
> proxies instead, as the reference to the service can be cached in the
> processor.
>
>
>
>
> On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <quinn@pronoia-solutions.com
>> wrote:
>
>> I normally use Blueprint to use OSGi Services. In that case, I should
>> wind up with a Blueprint service proxy. Would using a ServiceTracker with
>> a Blueprint proxy be necessary? I think the Blueprint proxy already does
>> that for me.
>>
>>
>>> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>
>>> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
>>> <richard.davidson.uk@gmail.com <ma...@gmail.com>>
>> wrote:
>>>> Hi,
>>>>
>>>> Instead of the cache containing the actual service objects it could it
>>>> contain a org.osgi.util.tracker.ServiceTracker. This would then cache
>> and
>>>> track the service internally. Each time the service is requested via the
>>>> registry, #ServiceTracker.getService() could be called. Let me know
>> your
>>>> thoughts, and if people agree I could try to create a patch.
>>>>
>>>
>>> Yeah we use service tracker to track components and whatnot.
>>>
>>> I have said it many times, we love contributions
>>> http://camel.apache.org/contributing <
>> http://camel.apache.org/contributing>
>>>
>>>>
>>>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Yeah it was created that way - i guess maybe the though was that osgi
>>>>> reference lookup is expensive?
>>>>>
>>>>> I guess we can reach out to the OSGi folks and see what they say. It
>>>>> would make the code simpler without a local cache.
>>>>>
>>>>>
>>>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
>>>>>> I have looked at the code in
>>>>> org.apache.camel.core.osgi.OsgiServiceRegistry
>>>>>> (camel-core-osgi-2.15.4) and it appears to cache the service
>> references.
>>>>>> This means that if I uninstall/install the bundle supplying the
>> service
>>>>> it
>>>>>> wont automagically 'pick up' the new service.
>>>>>>
>>>>>> For what reason(s) are the service references cached?
>>>>>>
>>>>>> Note - after modifying OsgiServiceRegistry and removing the cache a
>> new
>>>>>> service is picked up and behaves more like I would expect in a dynamic
>>>>> OSGi
>>>>>> environment.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>
>> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2 <
>> https://www.manning.com/ibsen2>
>>
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
I am not sure what the order the registries are chained together. I need to
test whether the blueprint or the OSGI registry is first, From looking at
the code:
{code}
public static Registry wrapRegistry(CamelContext camelContext, Registry
registry, BundleContext bundleContext) {
ObjectHelper.notNull(bundleContext, "BundleContext");
LOG.debug("Setting up OSGi ServiceRegistry");
OsgiServiceRegistry osgiServiceRegistry = new OsgiServiceRegistry(
bundleContext);
// Need to clean up the OSGi service when camel context is closed.
camelContext.addLifecycleStrategy(osgiServiceRegistry);
CompositeRegistry compositeRegistry = new CompositeRegistry();
compositeRegistry.addRegistry(osgiServiceRegistry);
compositeRegistry.addRegistry(registry);
return compositeRegistry;
}
{code}
I think the OSGI registry would be first in the chain as it is first in the
composite registry. If this is true then the the OSGI registry would be
checked first, and if it didn't exist in the OSGI registry then it would
try blueprint. I think this is wrong and the OSGI registry should be added
to the end of the chain, so blueprint etc is tried first. However making
this change would change existing functionality and could cause issues for
existing deployments.
Another point to note is that the service tracker change only works of the
processor looks up the registry every-time to get the service. If it holds
on to the service reference and the service goes away, requests will fail.
In my view adding service trackers to OsgiServiceRegistry is an improvement
on what exists today, but I would still strongly advise using blueprint
proxies instead, as the reference to the service can be cached in the
processor.
On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <quinn@pronoia-solutions.com
> wrote:
> I normally use Blueprint to use OSGi Services. In that case, I should
> wind up with a Blueprint service proxy. Would using a ServiceTracker with
> a Blueprint proxy be necessary? I think the Blueprint proxy already does
> that for me.
>
>
> > On Feb 9, 2016, at 2:31 AM, Claus Ibsen <cl...@gmail.com> wrote:
> >
> > On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> > <richard.davidson.uk@gmail.com <ma...@gmail.com>>
> wrote:
> >> Hi,
> >>
> >> Instead of the cache containing the actual service objects it could it
> >> contain a org.osgi.util.tracker.ServiceTracker. This would then cache
> and
> >> track the service internally. Each time the service is requested via the
> >> registry, #ServiceTracker.getService() could be called. Let me know
> your
> >> thoughts, and if people agree I could try to create a patch.
> >>
> >
> > Yeah we use service tracker to track components and whatnot.
> >
> > I have said it many times, we love contributions
> > http://camel.apache.org/contributing <
> http://camel.apache.org/contributing>
> >
> >>
> >> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >>
> >>> Hi
> >>>
> >>> Yeah it was created that way - i guess maybe the though was that osgi
> >>> reference lookup is expensive?
> >>>
> >>> I guess we can reach out to the OSGi folks and see what they say. It
> >>> would make the code simpler without a local cache.
> >>>
> >>>
> >>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
> >>>> I have looked at the code in
> >>> org.apache.camel.core.osgi.OsgiServiceRegistry
> >>>> (camel-core-osgi-2.15.4) and it appears to cache the service
> references.
> >>>> This means that if I uninstall/install the bundle supplying the
> service
> >>> it
> >>>> wont automagically 'pick up' the new service.
> >>>>
> >>>> For what reason(s) are the service references cached?
> >>>>
> >>>> Note - after modifying OsgiServiceRegistry and removing the cache a
> new
> >>>> service is picked up and behaves more like I would expect in a dynamic
> >>> OSGi
> >>>> environment.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> >>>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> -----------------
> >>> http://davsclaus.com @davsclaus
> >>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com <http://davsclaus.com/> @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2 <
> https://www.manning.com/ibsen2>
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I normally use Blueprint to use OSGi Services. In that case, I should wind up with a Blueprint service proxy. Would using a ServiceTracker with a Blueprint proxy be necessary? I think the Blueprint proxy already does that for me.
> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> <richard.davidson.uk@gmail.com <ma...@gmail.com>> wrote:
>> Hi,
>>
>> Instead of the cache containing the actual service objects it could it
>> contain a org.osgi.util.tracker.ServiceTracker. This would then cache and
>> track the service internally. Each time the service is requested via the
>> registry, #ServiceTracker.getService() could be called. Let me know your
>> thoughts, and if people agree I could try to create a patch.
>>
>
> Yeah we use service tracker to track components and whatnot.
>
> I have said it many times, we love contributions
> http://camel.apache.org/contributing <http://camel.apache.org/contributing>
>
>>
>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Yeah it was created that way - i guess maybe the though was that osgi
>>> reference lookup is expensive?
>>>
>>> I guess we can reach out to the OSGi folks and see what they say. It
>>> would make the code simpler without a local cache.
>>>
>>>
>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
>>>> I have looked at the code in
>>> org.apache.camel.core.osgi.OsgiServiceRegistry
>>>> (camel-core-osgi-2.15.4) and it appears to cache the service references.
>>>> This means that if I uninstall/install the bundle supplying the service
>>> it
>>>> wont automagically 'pick up' the new service.
>>>>
>>>> For what reason(s) are the service references cached?
>>>>
>>>> Note - after modifying OsgiServiceRegistry and removing the cache a new
>>>> service is picked up and behaves more like I would expect in a dynamic
>>> OSGi
>>>> environment.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
Re: OsgiServiceRegistry caching service references, why?
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
<ri...@gmail.com> wrote:
> Hi,
>
> Instead of the cache containing the actual service objects it could it
> contain a org.osgi.util.tracker.ServiceTracker. This would then cache and
> track the service internally. Each time the service is requested via the
> registry, #ServiceTracker.getService() could be called. Let me know your
> thoughts, and if people agree I could try to create a patch.
>
Yeah we use service tracker to track components and whatnot.
I have said it many times, we love contributions
http://camel.apache.org/contributing
>
> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi
>>
>> Yeah it was created that way - i guess maybe the though was that osgi
>> reference lookup is expensive?
>>
>> I guess we can reach out to the OSGi folks and see what they say. It
>> would make the code simpler without a local cache.
>>
>>
>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
>> > I have looked at the code in
>> org.apache.camel.core.osgi.OsgiServiceRegistry
>> > (camel-core-osgi-2.15.4) and it appears to cache the service references.
>> > This means that if I uninstall/install the bundle supplying the service
>> it
>> > wont automagically 'pick up' the new service.
>> >
>> > For what reason(s) are the service references cached?
>> >
>> > Note - after modifying OsgiServiceRegistry and removing the cache a new
>> > service is picked up and behaves more like I would expect in a dynamic
>> OSGi
>> > environment.
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
>> > Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
RE: OsgiServiceRegistry caching service references, why?
Posted by "Siano, Stephan" <st...@sap.com>.
Hi,
To me this looks like a good idea.
Best regards
Stephan
-----Original Message-----
From: Richard Davidson [mailto:richard.davidson.uk@gmail.com]
Sent: Dienstag, 9. Februar 2016 10:15
To: users@camel.apache.org
Subject: Re: OsgiServiceRegistry caching service references, why?
Hi,
Instead of the cache containing the actual service objects it could it
contain a org.osgi.util.tracker.ServiceTracker. This would then cache and
track the service internally. Each time the service is requested via the
registry, #ServiceTracker.getService() could be called. Let me know your
thoughts, and if people agree I could try to create a patch.
On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah it was created that way - i guess maybe the though was that osgi
> reference lookup is expensive?
>
> I guess we can reach out to the OSGi folks and see what they say. It
> would make the code simpler without a local cache.
>
>
> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
> > I have looked at the code in
> org.apache.camel.core.osgi.OsgiServiceRegistry
> > (camel-core-osgi-2.15.4) and it appears to cache the service references.
> > This means that if I uninstall/install the bundle supplying the service
> it
> > wont automagically 'pick up' the new service.
> >
> > For what reason(s) are the service references cached?
> >
> > Note - after modifying OsgiServiceRegistry and removing the cache a new
> > service is picked up and behaves more like I would expect in a dynamic
> OSGi
> > environment.
> >
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Richard Davidson <ri...@gmail.com>.
Hi,
Instead of the cache containing the actual service objects it could it
contain a org.osgi.util.tracker.ServiceTracker. This would then cache and
track the service internally. Each time the service is requested via the
registry, #ServiceTracker.getService() could be called. Let me know your
thoughts, and if people agree I could try to create a patch.
On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah it was created that way - i guess maybe the though was that osgi
> reference lookup is expensive?
>
> I guess we can reach out to the OSGi folks and see what they say. It
> would make the code simpler without a local cache.
>
>
> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
> > I have looked at the code in
> org.apache.camel.core.osgi.OsgiServiceRegistry
> > (camel-core-osgi-2.15.4) and it appears to cache the service references.
> > This means that if I uninstall/install the bundle supplying the service
> it
> > wont automagically 'pick up' the new service.
> >
> > For what reason(s) are the service references cached?
> >
> > Note - after modifying OsgiServiceRegistry and removing the cache a new
> > service is picked up and behaves more like I would expect in a dynamic
> OSGi
> > environment.
> >
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: OsgiServiceRegistry caching service references, why?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah it was created that way - i guess maybe the though was that osgi
reference lookup is expensive?
I guess we can reach out to the OSGi folks and see what they say. It
would make the code simpler without a local cache.
On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <ti...@mccarthy.co.nz> wrote:
> I have looked at the code in org.apache.camel.core.osgi.OsgiServiceRegistry
> (camel-core-osgi-2.15.4) and it appears to cache the service references.
> This means that if I uninstall/install the bundle supplying the service it
> wont automagically 'pick up' the new service.
>
> For what reason(s) are the service references cached?
>
> Note - after modifying OsgiServiceRegistry and removing the cache a new
> service is picked up and behaves more like I would expect in a dynamic OSGi
> environment.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2