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