Hi guys, I'm back from the short holidays. I will take a look at this issue soon. Stay tuned!
Laters! On Mon, Feb 9, 2015 at 9:28 AM, Christian Bauer <[email protected]> wrote: > https://issues.apache.org/jira/browse/CAMEL-8325 > > On February 8, 2015 7:35:56 PM GMT+01:00, Claus Ibsen <[email protected]> > wrote: >>On Fri, Feb 6, 2015 at 10:43 AM, Christian Bauer >><[email protected]> wrote: >>> Hi everyone, >>> >>> recently we had a typo in one of our route definitions that resulted >>in a duplicate route ID but no error message and unexpected replacement >>of an existing route. This is the bootstrap order found in some Camel >>examples: >>> >>> CamelContext context = new DefaultCamelContext(); >>> >>> context.addRoutes(new RouteBuilder() { >>> @Override >>> public void configure() throws Exception { >>> from("direct:foo").routeId("foo").stop(); >>> } >>> }); >>> >>> context.addRoutes(new RouteBuilder() { >>> @Override >>> public void configure() throws Exception { >>> from("direct:bar").routeId("foo").stop(); >>> } >>> }); >>> >>> context.start(); >>> >>> You'll get a duplicate route ID exception. >>> >>> If instead you start the context before you add the routes, you won't >>get an exception and the "direct:bar" route will simply replace the >>"direct:foo" route, as they have the same ID. This is consistent with >>the Javadoc of the API and probably a useful feature. >>> >>> However if like in our case you use camel-spring-boot, the >>RouteCollector will add routes after the Camel context has started. You >>won't detect duplicate route IDs but instead any later discovered >>RouteBuilder will override existing routes with the same ID. >>> >> >>Ah yeah I guess maybe camel-spring-boot calls start on CamelContext to >>soon. >> >>As currently you can add your own duplication route id detection and >>fail. >> >> >> >>> I'm no Spring expert but it seems the CamelContext start should be >>deferred in the Spring Boot integration code: The >>CamelBeanPostProcessor factory method triggers CamelContext creation >>(due to injection in the factory method) and starts SpringCamelContext >>during the BeanPostProcessor initialization phase in Spring >>(InitializingBean). Any necessary transitive bean creation will >>therefore also happen in that phase. We see a lot of Spring warnings >>(actually INFO, but it probably should be WARN) that some >>BeanPostProcessors had to be skipped, because we are starting inside a >>BeanPostProcessor call. >>> >> >>Yeah I think it should start later. In camel-spring we only start >>camel at the end when we receive an event from spring itself about the >>context created/refresh. >> >>Maybe if Henryk got some time he could dive in and look as well. >> >>But anyone is of course welcome to help. We love contributions. >>And you are welcome to log a JIRA ticket, it does indeed appear as the >>start() is invoked too soon, which can also cause other side-effects. >> >>eg start should only be called after all the configuration has been >>done. >> >> >>> One of those is for example our custom BeanPostProcessor which adds >>discovered EventNotifiers to the CamelContext, something the Spring >>Boot integration doesn't provide yet. We think this has to be done >>before the CamelContext is started, after looking at the >>ManagementStrategy code. Hence you can't do this with the >>CamelConfiguration interface of camel-spring-boot, the context has >>already been started at that point. >>> >>> Our solution was a simple integration class for Spring Boot that >>starts the context later, after configuration. Would be great to know >>if we are missing something, although we'll probably stay on 2.14 >>anyway for this project due end of March. >>> >>> Cheers, >>> Christian >>> >>> >>> >>> >>> >> >> >> >>-- >>Claus Ibsen >>----------------- >>Red Hat, Inc. >>Email: [email protected] >>Twitter: davsclaus >>Blog: http://davsclaus.com >>Author of Camel in Action: http://www.manning.com/ibsen >>hawtio: http://hawt.io/ >>fabric8: http://fabric8.io/ -- Henryk Konsek http://henryk-konsek.blogspot.com
