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
>
