Hello,
What you want to do sound a bit like what we did in a project. I'm not
sure that this is a good solution or that it should be treated as
"best practice" (in fact I'm quite sure that this is not the best
solution) but this is how we solved it.
Route recipes are stored in a database. These recipes contain
information about the start and end enpoints (information used to
create the URL) and also information if some optional transformation
should be done in this route or not.
We then have a RouteBuilder implementation that takes a recipe as a
property. And in the configure we build the route based on the
information in the recipe. Right now the decision is done at
configure() time so a example from the configure() method would look
something like this:
----
RouteDefinition newRouteDef = from(recipe.getInput())
.routeId(recipe.getName());
if(recipe.recipe.getAmountOfRaisins() > 0) {
newRouteDef.process(new RaisinAdder(recipe.getAmountOfRaisins()));
}
/* more selections */
newRouteDef.to(recipe.getOutput());
return newRouteDef;
----
We then have one JPA route that polls the database for new or updated recipes.
If a new recipes is added we create a new RouteBuilder, set the recipe
property and add it to the context.
If a recipe has changed we first stop that route, remove the route and
the add it in the same way as above.
So far it works but we are only running about 10 routes per
installation. And I am a bit worried that this solution will not
scale very well since we create a completely new route for each
recipe.
As I said above I'm sure there are more elegant solutions to the problem.
// Pontus
On Thu, Jul 19, 2012 at 5:23 AM, Hadrian Zbarcea <hzbar...@gmail.com> wrote:
> The routing slip is a dynamic router that allows one to determine at runtime
> to what endpoints messages should be sent. It got nothing to do with the
> process of creating routes.
>
> The 2 choices are to either hardcode the logic described or the more elegant
> solution imo of defining a small dsl for that. I am going on a limb here and
> guess that there is some reason for generating the many routes. That reason
> I suspect could probably be expressed in a concise way, which would make a
> dsl appropriate.
>
> The requirements were quite vague but I hope my guesses are not way off. A
> bit more details may get you some sample code to get you started. Here are a
> few pointers:
>
> 1. To define a number of routes you would implement a RouteBuilder and its
> configure method.
> 2. Although virtually all examples show that you need to call
> from(x).to(y).blah()..., there is nothing that prevents you from
> implementing a method:
> protected void foo() {
> from(x).to(y).blah()...;
> }
> and call it within configure(), it'd have the same effect.
> 3. Next imagine that your method foo() actually takes some parameters, that
> would allow you to parameterize the route (you may have more than one such
> method).
> 4. Another thought is that you could actually use a Camel route (active only
> during startup) to extract the data from your store. Useful for unit testing
> and other goodies.
> 5. Bonus points for realizing that actually you can use a Camel Expression
> to evaluate the result of querying the data store and produce the value
> Object to parameterize the route.
> 6. An Expression may be useful to determine how many parameterized routes
> you need.
> 7. Add some syntactic sugar and you got your dsl.
>
> All of the above may sound complicated or advanced, but it's actually quite
> simple to implement.
>
> I hope this helps,
> Hadrian
>
>
>
>
> On 07/18/2012 06:55 PM, ychawla wrote:
>>
>> Would a routing slip work for you? You can dynamically configure where
>> your
>> message is going, not necessarily what your input is. However, depending
>> on
>> your requirements, this could suffice:
>>
>> http://camel.apache.org/routing-slip.html
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Dynamic-generation-of-Camel-routes-tp5716223p5716225.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
