Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 257A7178E7 for ; Sun, 8 Feb 2015 18:38:59 +0000 (UTC) Received: (qmail 18959 invoked by uid 500); 8 Feb 2015 18:38:58 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 18907 invoked by uid 500); 8 Feb 2015 18:38:58 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 18895 invoked by uid 99); 8 Feb 2015 18:38:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Feb 2015 18:38:58 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com designates 209.85.223.182 as permitted sender) Received: from [209.85.223.182] (HELO mail-ie0-f182.google.com) (209.85.223.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Feb 2015 18:38:33 +0000 Received: by iebtr6 with SMTP id tr6so11900263ieb.2 for ; Sun, 08 Feb 2015 10:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=vh1J2zkoWGifDkRlQbbg3agxioUQJVo4Lh1nlPtBeaQ=; b=zQTbAi4r8vyI6UhH3C3bRfmbIHc0POabTqjaSDCSnyVWaQOTOvANoQd/xMk4bRVem4 xjhMX7pGf5gbD/xWL2fXkDvXEfdK4EziZoEj7dOHlnnNEN0NTO1rC4zVsyIkcuLBC2yR V8Ir5U6TDVJner0cyzwjZKV77rNf6o6cmVBgX+m9nyu9XbwOdczeNlGIq0pulRiRgJIR SUdsnHLPwZ/N8c2b36GBxnhayyoxdQBQ9DL+9NrcQSP2by+9v+Vcujk8TvaNUgvzmAHg 5SLGrCWB8GkmRzPguJCLGLGY6M+DFuUx9PmBtfDrwuc0iI0S/GsEujbFSD3tN3utpvVY 5DfA== X-Received: by 10.50.93.70 with SMTP id cs6mr12860855igb.6.1423420576835; Sun, 08 Feb 2015 10:36:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.149.5 with HTTP; Sun, 8 Feb 2015 10:35:56 -0800 (PST) In-Reply-To: <8713C0A9-5CB3-45AC-871F-F58ECC28C71E@christianbauer.name> References: <8713C0A9-5CB3-45AC-871F-F58ECC28C71E@christianbauer.name> From: Claus Ibsen Date: Sun, 8 Feb 2015 19:35:56 +0100 Message-ID: Subject: Re: Duplicate route id detection and Spring Boot integration To: "users@camel.apache.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Feb 6, 2015 at 10:43 AM, Christian Bauer 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 e= xisting route. This is the bootstrap order found in some Camel examples: > > CamelContext context =3D 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:fo= o" 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 dupl= icate 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 deferr= ed in the Spring Boot integration code: The CamelBeanPostProcessor factory = method triggers CamelContext creation (due to injection in the factory meth= od) and starts SpringCamelContext during the BeanPostProcessor initializati= on phase in Spring (InitializingBean). Any necessary transitive bean creati= on will therefore also happen in that phase. We see a lot of Spring warning= s (actually INFO, but it probably should be WARN) that some BeanPostProcess= ors had to be skipped, because we are starting inside a BeanPostProcessor c= all. > 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 disco= vered EventNotifiers to the CamelContext, something the Spring Boot integra= tion doesn't provide yet. We think this has to be done before the CamelCont= ext 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 t= he context later, after configuration. Would be great to know if we are mis= sing something, although we'll probably stay on 2.14 anyway for this projec= t due end of March. > > Cheers, > Christian > > > > > --=20 Claus Ibsen ----------------- Red Hat, Inc. Email: cibsen@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/