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 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  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 
> configurable.

This message was sent by Atlassian JIRA

Reply via email to