[ https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15587412#comment-15587412 ]
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 (v6.3.4#6332)