[
https://issues.apache.org/jira/browse/CAMEL-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422931#comment-13422931
]
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: https://issues.apache.org/jira/browse/CAMEL-5466
> 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 virtual.properties 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
