Sverker Abrahamsson commented on CAMEL-10391:
Given that RouteBuilders that are automatically added to context will be on
application level the _emphasis_standard_emphasis_ CDI behavior is that they
should be @ApplicationScoped. It is defenitly not a CDI behavior to make other
beans de-facto application scoped.
Regarding the backwards compatibility, it broke that for my applications when
this behavior was introduced in 2.17 and I was surprised as I didn't expect it.
That is a quite recent version and shouldn't be too much of a hazzle for those
affected to add the annotation.
With that said, I'm all for convension IF there is a possibility to override it
by configuration in a reasonable way. Don't get me wrong, I think that if used
correctly it's beautiful to be able to automatically add routes to context by
using qualifers. What I'm against is that non-qualified, and not application
scoped RouteBuilders are automatically added to default context and that it is
autostarted. I was fine with having to bootstrap it, as at least before there
were certain things that had to be done before the context was started but it
seems that now it is possible to do it also after.
With the EJB standards I often face the difficulty that they are designed with
the belief that you know the application settings at compile time, or at least
at packaging or deploy time while in real world applications it depends on what
the user/admin sets up in the application through some user friendly interface
(which is not having to edit xml files) and it is excepted that the application
will change its behavior when user commits those settings without having to
restart the application.
For example, I have an application which consumes files from watchfolders that
the user configures through a webui. Those settings are stored in the db, and I
need to create RouteBuilders and other resources dynamically as I don't have
that information even at deploy time. Likewise most of my JMS queues needs to
be created dynamically, which I earlier did by calling the MBean but now I have
to look at how to do that programatically through the CLI, and I can't utilize
MDB's to consume from those queues so I have to dynamically instantiate beans
or camel routes to consume from them. I wish that aspect had been considered
when these standards were created.
> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
> Issue Type: Improvement
> Components: camel-cdi
> Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
> Reporter: Sverker Abrahamsson
> Assignee: Antonin Stefanutti
> Camel-CDI will find every class in a deployment which extends RouteBuilder
> and automatically add them to the context. This is a major issue for me as I
> usually wants to instantiate my RouteBuilders programatically setting various
> parameters, with CDI support.
> This behaviour was introduced with
> from [~antonin.stefanutti] and we had a good discussion about the issue on
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but
> never came up with a good solution for it. I have patched camel-cdi to use a
> marker annotation @DoNotAddToCamelContext to work around it but I don't want
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class,
> even though I don't agree that it is a good idea but it could very well be
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm
> thinking about if there could be an annotation like
> @CamelContextStartup(false) or maybe even a more general
> @CamelContextConfig(autostart=false) if there are other things that should be
This message was sent by Atlassian JIRA