camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonin Stefanutti (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context
Date Wed, 19 Oct 2016 09:06:58 GMT

    [ 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)

Mime
View raw message