Christian -
I don’t know about a class loader issue, but I do know when I run the route
configured as you have it below, I’m not getting a proxy to the service. I
know this because if I stop the bundle containing the OSGi service, the Camel
context keeps running - I don’t get a ServiceUnavailableException after the
timeout. In fact, it keeps using whatever is injected into the RouteBuilder.
I think that’s where the class loader thing came from - it appear to be using
the implementation of the service directly - not via a Blueprint proxy.
> On Feb 2, 2016, at 1:37 PM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> I am actually not sure if you have a classloader problem here.
>
> In your original route you use:
>
> .bean(blueprintServiceReference,false)
>
> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
> this.blueprintServiceReference = blueprintServiceReference;
> }
>
> This will simply call the service proxy that was injected by blueprint when
> the route starts.
> This should pick up changing services according to the rules of blueprint. So
> I don't think the Camel registry is involved at all in this case. It would
> only be involved when refering to the service via its interface name.
>
> The routebuilder is found by a ref too. So I doubt the class loader is
> involved there.
>
> Christian
>
> On 02.02.2016 17:40, Quinn Stevenson wrote:
>> Thank You Christian -
>>
>> Yes - I pointed out that if I used the Bean Component, everything seemed to
>> work as I expected.
>>
>> The problem I have is I use beans in filter blocks as well, and there I
>> can’t use the 'to( “bean://<name” )’ construct. I need to keep the original
>> message bodies and just filter, and when I use the method(…) invocation,
>> it’s hit or miss if it honors dynamic services (i.e. picks-up new instances
>> when the implementation is replaced). It’s very sensitive to how the bean
>> with the service reference is declared.
>>
>> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
>> strategy to get around this, but it worked the same way as the method( … )
>> DSL - it didn’t pickup new service instances when the services were replaced.
>>
>>
>>
>>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <ch...@die-schneider.net>
>>> wrote:
>>>
>>> There is a much simpler way to use an OSGi service with blueprint.
>>> Simply use the bean component of camel. It resolves beans against the camel
>>> registry.
>>> When you define your camel context using blueprint then the camel registry
>>> automatically includes all blueprint beans.
>>>
>>> So you can do this in java dsl:
>>> to("bean:echo-service")
>>>
>>> It will find the bean with this id in blueprint. In your case it will be
>>> the service reference.
>>>
>>> Christian
>>>
>>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>>> When I use an OSGi Service registered using Blueprint from a Java route
>>>> (built using a Java RouteBuilder), the Camel route isn’t detecting the
>>>> when the service is not available, and it isn’t updating when the service
>>>> implementation changes.
>>>>
>>>> The simple setup I’m using has a Java interface for the OSGi service in
>>>> one bundle, and implementation of that interface which uses Blueprint to
>>>> register the service in another bundle, and simple RouteBuilder that uses
>>>> the service in a third bundle. The implementation of the service is
>>>> injected into the RouteBuilder using Blueprint, and the Camel context is
>>>> configured in Blueprint in a fourth bundle.
>>>>
>>>> After all these bundles are installed and started in Karaf, the run and
>>>> the hashCode of service is logged every time the Camel timer fires and
>>>> triggers an exchange. If I stop the bundle that registers the service
>>>> using Blueprint, the route continues to log the same hashCode when it
>>>> calls the OSGi service. I would expect a ServiceUnavailableException
>>>> after a timeout.
>>>>
>>>> Additionally, when I restart the bundle that registers the service object,
>>>> I continue to get the same hashCode. I would expect to get a new hashCode
>>>> value.
>>>>
>>>> Am I doing something wrong? Do I need to do something different do get
>>>> the dynamic behavior I’m looking for?
>>>>
>>>>
>>>> The code looks like this:
>>>>
>>>> Java Interface (service-interface bundle):
>>>> public interface Echo {
>>>> String execute(String body);
>>>> }
>>>>
>>>> Java Implementation:
>>>> public class EchoServiceOne implements Echo {
>>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>>
>>>> @Override
>>>> public String execute(String body) {
>>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
>>>> this.hashCode() );
>>>> return body;
>>>> }
>>>> }
>>>>
>>>>
>>>> Blueprint Registering the service (service-one bundle):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>>>>
>>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>>> <service-properties>
>>>> <entry key="instance" value="one" />
>>>> </service-properties>
>>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
>>>> </service>
>>>>
>>>> </blueprint>
>>>>
>>>> Java RouteBuilder (route-builder bundle):
>>>> public class VerySimpleBuilder extends RouteBuilder {
>>>> Echo blueprintServiceReference;
>>>>
>>>> @Override
>>>> public void configure() throws Exception {
>>>> from("timer://very-simple-builder?period=5000").routeId(
>>>> "very-simple-route" )
>>>> .setBody( simple( "${exchangeProperty[" +
>>>> Exchange.TIMER_FIRED_TIME + "]}") )
>>>> .log("Calling Service via Reference: ${body}" )
>>>> .bean(blueprintServiceReference,false)
>>>> .to( "mock://result")
>>>> .log("Finished" );
>>>> }
>>>>
>>>> public Echo getBlueprintServiceReference() {
>>>> return blueprintServiceReference;
>>>> }
>>>>
>>>> public void setBlueprintServiceReference(Echo
>>>> blueprintServiceReference) {
>>>> this.blueprintServiceReference = blueprintServiceReference;
>>>> }
>>>> }
>>>>
>>>> Blueprint constructing the Camel context (camel-context bundle):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>>
>>>> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0";
>>>> xsi:schemaLocation="
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>>> http://camel.apache.org/schema/blueprint
>>>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd";
>>>> <reference id="echo-service"
>>>> interface="com.pronoia.test.osgi.service.Echo" filter="instance=one"
>>>> timeout="2000" />
>>>>
>>>> <bean id="very-simple-route-builder"
>>>> class="com.pronoia.test.camel.builder.VerySimpleBuilder">
>>>> <property name="blueprintServiceReference" ref="echo-service" />
>>>> </bean>
>>>>
>>>> <camelContext id="very-simple-context"
>>>> xmlns="http://camel.apache.org/schema/blueprint";>
>>>> <routeBuilder ref="very-simple-route-builder" />
>>>> </camelContext>
>>>>
>>>> </blueprint>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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
>
