In the 1.6 codeline it was possible to define routebuilders as beans in a
Spring context and have them wired into the camel context upon intialization
e.g.

<bean id="simpleHttpRoute" class="org.simple.SimpleHttpToFileRoute" />

This bean would have been added to the context when the following block of
code in in the  installRoutes method of the CamelContextFactoryBean was
executed

 protected void installRoutes() throws Exception {
        if (autowireRouteBuilders != null &&
autowireRouteBuilders.booleanValue()) {
            Map builders =
getApplicationContext().getBeansOfType(RouteBuilder.class, true, true);
            if (builders != null) {
                for (Object builder : builders.values()) {
                    getContext().addRoutes((RouteBuilder) builder);
                }
            }
        }

In the 2.0 codeline, this section has been removed (as part of a fix for the
following issue/feature http://bit.ly/n6ojs ) and the context defined routes
do not get added. I was wondering what the reason was for dropping this? Was
it considered harmful? 

I know the package scan can be used to initialise RouteBuilders it finds in
packages, but it can be annoying to exclude routes from this mechanism, for
instance where you have test RouteBuilders that happen to live in the same
package in the test src tree, or where there are routes that complicate
testing with setup and noise. Also in situations where you configure the
RouteBean explicitly e.g. to inject values from properties files, it is much
cleaner to define the routes as beans. 

Short of adding my own CamelContextAwareBean to do the same, Is there a
different mechanism to do setup Routes this way?

Thanks in advance

Stephen.
-- 
View this message in context: 
http://www.nabble.com/Autowiring-RouteBuilders-defined-as-beans-in-Spring.-tp23970613p23970613.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to