Importing routes into camel (spring) context

[Kevin Jackson <fo...@gmail.com>]

Hi,

I don't think it's currently possible to have a single camelContext
and use the <import> tag to pull in routing information into that
context.

The usecase is that we have a single application with many routes,
each route is specific to an entity and I would prefer to keep the
entity specific information in a separate context file and import it
into the main camelContext.  This would allow soft-deployment of code
and then activation of a route via deploying an entity specific
context.

Is this something that may be possible in the future?

Thanks,
Kev

Re: Importing routes into camel (spring) context

[Willem Jiang <wi...@gmail.com>]

CamelContext tag supports to use the routeBuilder to load the Java DSL 
RouteBuilder.
Maybe you can put the specific Routebuilder configure into a single 
spring configuration file, and import it into the Spring configuration 
with a single CamelContext.

Willem

Claus Ibsen wrote:
> Hi
> 
> Yes its not possible.
> Yes there is a ticket in JIRA to add such a feature
> 
> Java DSL allows you to use multiple route builders.
> 
> 
> On Tue, Mar 23, 2010 at 9:02 AM, Kevin Jackson <fo...@gmail.com> wrote:
>> Hi,
>>
>> I don't think it's currently possible to have a single camelContext
>> and use the <import> tag to pull in routing information into that
>> context.
>>
>> The usecase is that we have a single application with many routes,
>> each route is specific to an entity and I would prefer to keep the
>> entity specific information in a separate context file and import it
>> into the main camelContext.  This would allow soft-deployment of code
>> and then activation of a route via deploying an entity specific
>> context.
>>
>> Is this something that may be possible in the future?
>>
>> Thanks,
>> Kev
>>
> 
> 
> 

Re: Importing routes into camel (spring) context

[Claus Ibsen <cl...@gmail.com>]

Hi

Yes its not possible.
Yes there is a ticket in JIRA to add such a feature

Java DSL allows you to use multiple route builders.


On Tue, Mar 23, 2010 at 9:02 AM, Kevin Jackson <fo...@gmail.com> wrote:
> Hi,
>
> I don't think it's currently possible to have a single camelContext
> and use the <import> tag to pull in routing information into that
> context.
>
> The usecase is that we have a single application with many routes,
> each route is specific to an entity and I would prefer to keep the
> entity specific information in a separate context file and import it
> into the main camelContext.  This would allow soft-deployment of code
> and then activation of a route via deploying an entity specific
> context.
>
> Is this something that may be possible in the future?
>
> Thanks,
> Kev
>



-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Re: Importing routes into camel (spring) context

[Wayne Keenan <wa...@gmail.com>]

Hi,

You might want to look at springs  classpath*:  mechanism.

I am using it to pull in in all the spring xml files that match a particular
pattern fo my app; some spring files may have their own camelContext, so
although you dont have a single camelContext you do get discrete config
files. This may or may not fit your situation,  e.g.:

    <!-- import al Spring config files -->
    <import resource="classpath*:*-camel-spring.xml"/>



Regards
Wayne

On Tue, Mar 23, 2010 at 8:02 AM, Kevin Jackson <fo...@gmail.com> wrote:

> Hi,
>
> I don't think it's currently possible to have a single camelContext
> and use the <import> tag to pull in routing information into that
> context.
>
> The usecase is that we have a single application with many routes,
> each route is specific to an entity and I would prefer to keep the
> entity specific information in a separate context file and import it
> into the main camelContext.  This would allow soft-deployment of code
> and then activation of a route via deploying an entity specific
> context.
>
> Is this something that may be possible in the future?
>
> Thanks,
> Kev
>