camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ari Mando (JIRA)" <>
Subject [jira] [Commented] (CAMEL-5466) new virtual endpoint component
Date Thu, 26 Jul 2012 06:58:35 GMT


Ari Mando commented on CAMEL-5466:

Yes, several large customers I have consulted for have insisted on XML routes, not necessarily
ideal, but their teams implementing these routes have very little Java experience, think middleware
admin teams, they're not developers. Fuse IDE doesn't support java routes, blar blar blar.

Additionally, your solution doesn't necessarily address internalization of redundant information
(most of the URI for example) and externalization of configurable endpoint data (ie 100's
of queuenames) in it's current form. Obviously, your snippet could me made to have these features.
But your solution is neat and I think I'll use that for Java solutions too in the future.
But I still see a functional difference. No big deal.  

I've just worked on a new system which would theoretically require 1000's of xml routes very
soon, identical except the consumer queue name. Consider having to turn on a new store queue
for corporate chain that has 1000's of stores. How does that work in your approach? You could
implement externalized values in your java solution (from a properties file) but you have
to list the full URI for each route? When I've done this approach in the past I've always
had property files with lots of url's which have a lot of identical endpoint configuration
information, maintenance nightmare.

In the current demo code you can turn on a jms consumer route by just updating a properties
file, it currently requires a route restart. Easy for admins. If source list could be sourced
from another camel endpoint, even better. I'm planning to update the virtual component to
dynamically reconfigure it's template source, hopefully I get some time soon and look at extending
the XML DSL as I described originally. 

I debated in my head whether this was virtual routing or template route, names, names names.
But thinking this through just now I've realized the approach I've demonstrated uses a XML
virtual notation around the route, but a templating mechanism to the endpoint URI's. 

> new virtual endpoint component
> ------------------------------
>                 Key: CAMEL-5466
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>    Affects Versions: 2.9.2
>            Reporter: Ari Mando
>             Fix For: 2.9.3
>         Attachments: camel-virtual.tar.gz
> I had the recurring need for a virtual endpoint in camel routes. Often I need to define
the same route, but just with different endpoint locations, typically queues.
> The supplied component allows for:
>     <route>
>         <from uri="virtual://source-queue?real=amq://@?"/>
>         <to uri="virtual://destination-queue?real=amq2://@?"/>
>     </route>
> Then in a file:
> *source-queue,destination-queue
> queue1,queue4
> queue2,queue5
> queue3,queue6
> The above properties file would be like adding 3 routes. 
> The supplied impl is a bit rough, it needs some more work. The first cut was sufficient
for the usecase I needed it for.
> I already thought it should be really like:
> <virtual id="test" uri="file://queues.xml">
>     <route>
>         <from uri="virtual://source-queue?real=amq://@?"/>
>         <to uri="virtual://destination-queue?real=amq2://@?"/>
>     </route>
> </virtual>
> then an xml file:
> <endpointValues>
>     <header>
>         <value>source-queue</value>
>         <value>destination-queue</value>
>     </headers>
>     <entry>
>         <value>queue1,queue4</value>
>         <value>queue5,queue6</value>
>     </entry>
> </endpointValues> 
> Using the DSL would allow multiple virtual routes with different config being pulled
from other camel endpoints. 
> Dynamic routing! Call it virtual routing or template routing.
> Tasks to be finished on it:
> * implement threading (concurrentConsumers)
> * move to high level dsl model
> * unit tests
> * source configuration from enrichment uri call
> * more robust error handling

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message