Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 209.85.162.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Q5Riij8/Rxmf8uSPyu/3Jg7IKa6RWTGLoXloIfFdjR86chJ7A7QeO+6U4KS18EjFSUJMsps3UC0HKCfOWAzF4QF5bC0XYp2rcnVdGJcvUNiGs+V6YpE8XZ5hQuf7gyhM35al80AcmHOnco6RlNT2Uas/9iso34xLsUwBV6kUNrQ=
Message-ID: <ec6e67fd0712130811w50e2ab71x44b8bae7be5c3c36@mail.gmail.com>
Date: Thu, 13 Dec 2007 16:11:43 +0000
From: "James Strachan" <james.strachan@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: Adding Components Dynamically
In-Reply-To: <14317514.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <14317514.post@talk.nabble.com>

On 13/12/2007, ewhauser <ewhauser@gmail.com> 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
CamelContext.


> 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
unit.

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.

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com