Hi Dennis,

> On 13 Oct 2016, at 14:22, Dennis Bohnstedt Hansen <d...@miracle.dk> wrote:
> Hi
> I'm having soms problems with camel-test-cdi in 2.17 (tested in 2.17.0,
> 2.17.1 and 2.17.2).
> I have two projects containing similar routes and test cases, but the
> behaviour is very different, and i'm unsure which is the intended
> behaviour. In both projects, my RouteBuilders are annotated with the
> following annotations, and are picked up by Wildfly with camel-wildfly
> added.
> @Startup
> @ApplicationScoped
> @ContextName("foo-context")
> In my jUnit tests however, the routes of project 1 are only picked up, when
> i add the RouteBuilder to @Beans(...) like this:
> @RunWith(CamelCdiRunner.class)
> @Beans(classes = {MyFooRouteBuilder.class})
> ... But in project 2, the routes are picked up (by Weld i guess) without
> adding @Beans, and if i add @Beans i get the following error from Weld:
> org.jboss.weld.exceptions.DeploymentException: Exception List with 1
> exceptions:
> Exception 0 :
> org.apache.camel.FailedToStartRouteException: Failed to start route
> MyFooRouteRoute because of duplicate id detected: MyFooRouteRoute. Please
> correct ids to be unique among all your routes.
> at
> org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:963)
> at
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3295)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3018)
> I've gone though the classpath, and it seems to be fairly similar with
> regards to Camel, Weld and Injection, which leaves med with a couple of
> questions:
> 1) Which is the intended behaviour? I've found an email from @astefanutti (
> http://camel.465427.n5.nabble.com/Came-CDI-tests-start-non-test-routes-td5783324.html),
> that says that all routes should be loaded by default in test cases, but
> that does not seem desirable in larger projects.

For the time being, CamelCdiRunner bootstrap a Weld SE container with its 
discovery mode enabled, that is every explicit beans archive (that is with a 
beans.xml) that’s available in the classpath gets added to the deployment. 
@Beans annotations can then be used to add additional classes to that 
deployment, for example for test classes (generally test classes are not 
packaged in bean archives).

> 2) If the default behaviur is "load all", how do i keep that from
> happening, without changing my business-code?

The idea behind the CamelCdiRunner is to provide the simplest way to bootstrap 
your application in a SE CDI container for you to test. So it relies on what's 
available in the classpath. Besides, you can still rely on CDI features like 
alternatives and decorators, should you modify your application logic for 
testing purpose.

In case your classpath is too complex, the idea is to use Arquillian which 
leverages ShrinkWrap in order to build your test deployments as documented in 

That being said, we may want to improve CamelCdiRunner to meet your need, 
provided that it does not hinder the original intent, that is simplicity and 
convention over configuration.

> 3) If Weld and Camel versions are the same - where do i look for the
> error??!?

Not sure I understand the question here :(

Let us know if that helps.

[1]: http://camel.apache.org/cdi-testing.html#CDITesting-Arquillian


Reply via email to