Will do - I’ll pull them from this thread. Thanks Again - this one is killing me right now
> On Feb 2, 2016, at 10:02 AM, Brad Johnson <brad.john...@mediadriver.com> > wrote: > > Tack the examples on to the issue to give it context.. That'll help folks > replicate it. > > On Tue, Feb 2, 2016 at 11:01 AM, Quinn Stevenson < > qu...@pronoia-solutions.com> wrote: > >> Thank You for opening the issue Brad - >> >> You beat me to it, but you’re explanation of the issue was much better >> than I could come up with - all I have are samples of what’s going on and >> no real explanation as to why :-) >> >> Thanks Again >> >> >>> On Feb 2, 2016, at 9:51 AM, Brad Johnson <brad.john...@mediadriver.com> >> wrote: >>> >>> https://issues.apache.org/jira/browse/CAMEL-9562 >>> >>> I've opened an issue. I think it is a relatively easy thing to add a >>> strict mode flag without breaking anyone. You're right that it is easy >>> enough to make it work right. But if I haven't set something up to work >>> correctly I don't want the classloader fixing it inadvertently. >>> >>> I haven't run into this before since for the past two years I've used >> Camel >>> blueprint XML exclusively and only used Java for a beans and service >>> calls. I was venturing into using route builders when I ran into this. >>> >>> On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson < >>> qu...@pronoia-solutions.com> 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 >>>>> >>>> >>>> >> >>
