And if we get enough up votes maybe it'll get put in. It shouldn't be too difficult technically and can be put in without breaking anyone. Now, what happens when the flag gets turned on will be interesting.
On Tue, Feb 2, 2016 at 11: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 >> >>> >> >> >> >> >> >> >
