[
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15588123#comment-15588123
]
Antonin Stefanutti commented on CAMEL-10391:
--------------------------------------------
{quote}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.{quote}
_standard_ CDI behaviour for beans discovery is defined by [Type
discovery|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#type_discovery_steps]
and [Beans
discovery|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_discovery_steps].
If Camel CDI is to fit into that _standard_ CDI behaviour, {{RouteBuilder}}
beans without explicit scope defined (i.e. {{@Dependent}}) should be deployed
as beans. That answers the previous point discussed.
Then, for the binding of {{RouteBuilder}} beans to the Camel contexts, Camel
CDI does not _"make other beans de-facto application scoped"_. It just assumes
the scope defined by the user. Note that it is possible to inject
{{@Dependent}} beans into {{@ApplicationScoped}} beans and that if was
necessary to enforce a particular scope for {{RouteBuilder}} beans, maybe a
{{@CamelContextScoped}} would be better as some users have expressed the need
to share a {{RouteBuilder}} beans across multiple Camel contexts.
{quote}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.{quote}
That behaviour, that is adding {{RouteBuilder}} beans with implicit scope to
Camel contexts, wasn't changed in 2.17, as the following test from 2.16.4
shows:
https://github.com/apache/camel/blob/camel-2.16.4/tests/camel-itest-cdi/src/main/java/org/apache/camel/itest/cdi/RoutesContextA.java#L35.
So there must be something else that broke your use case.
{quote}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.{quote}
I'm aware of two users so far having that need. As per your comment after, CDI
is designed with immutability in mind, that is the container configuration is
setup at deployment time (not compile time as extensions can change the
behaviour). While you have the ability to do programmatic lookup, that's pretty
much it when it comes to dynamically interacting with the container at runtime.
To synthesize, it is possible to meet your need with the use of a custom
qualifier. However, that forces you to use that qualifier when you need to
retrieve instances. e.g.:
{code}
@Inject
@YourCustomQualifier
RouteBuilder builder;
{code}
Instead of:
{code}
@Inject
RouteBuilder builder;
{code}
Or to write {{CDI.current().select(RouteBuilder.class,
YourCustomQualifier.class).get()}} instead of
{{CDI.current().select(RouteBuilder.class).get()}}.
I agree this is cumbersome and I more incline towards providing a configuration
API as Camel Spring Boot does rather than hindering the default convention
based on scope assumptions. Note that for the time being, that use case is not
even possible with Spring Boot
(https://github.com/apache/camel/blob/e275446a4768231a76c76e24985b796865550e3b/components/camel-spring-boot/src/main/java/org/apache/camel/spring/boot/RoutesCollector.java#L78).
> 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)
