camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Adding Components Dynamically
Date Thu, 13 Dec 2007 16:11:43 GMT
On 13/12/2007, ewhauser <> wrote:
> Hi,
> I have a use case where we would like to have end users define BAM rules
> that can be read by Camel.  I would like to persist their criteria to a
> database and then build the BAM rules dynamically at runtime.  I might have
> the need to do this with routes as well, but I am not entirely sure yet.

That sounds fine - it should be trivial to create ActivityBuilder or
RouteBuilder instances at runtime whenever you like and add them to a

> I was investigating approaches for handling this, and I was thinking
> something like:
> 1. GUI writes rules to the database and publishes a message to a topic
> saying that rules have changed
> 2. Have a subscriber read the rules from DB
> 3. Get the CamelContext from the container and remove any rules that are
> have changes or are deleted
> 4. Add the rules to the CamelContext

I guess it all comes down to how you specify the rules (what code,
XML, SQL data is used).

You could always write rules using Java code and/or Spring XML and
make an OSGi bundle and deploy that into the database, then
version/schedule them to go live on different dates/times etc? e.g.
roll back / forward etc.

Or if you can find some data in a database to represent the things
which change, you could have a generic rulebase populate itself from
some query or something?

> This all certainly seems possible from an API standpoint, but can you alter
> the CamelContext while you have active brokers processing messages?  If yes,
> are there any pitfalls to this approach?

You can for sure. The simplest approach is to use one CamelContext per
rulebase; then you can start & stop the whole thing easily in one

e.g. think of starting/stopping a Spring ApplicationContext; its kinda
the same thing - as you deploy/undeploy multiple contexts it can get a
bit confusing remembering whats what - whereas if you do it at the
CamelContext / ApplicationContext its nice and simple.

The same granularity of CamelContext works nicely with OSGI bundles too.


Open Source Integration

View raw message