[ 
https://issues.apache.org/jira/browse/CAMEL-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423530#comment-13423530
 ] 

Ari Mando commented on CAMEL-5466:
----------------------------------

Will do. Yes I agree with your points.

I was thinking about the java side also just now, to your original point. I 
used the virtual component in a message migration tool recently, boot strapped 
from java as an executable jar. The main line was very short, including:

context.addRoutes(new RouteBuilder() {
                            public void configure() {
                                
from("virtual://source-queue?real=activemqold://@")
                                        
.to("virtual://destination-queue?real=activemqnew://@");
                            }
                        });

I think that reads more simpler and more concise then your looped routerbuilder 
approach, the component handles the externalization, it's deadly simple. The 
program is one java file and needs a only a property file with queuenames 
(actually another app property file too). In your java approach you would need 
to have several classes and you still have to build in the external config 
mechanism into your app code.  
                
> 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.
> For example the following simple route will move messages between queues:
>     <route>
>         <from 
> uri="virtual://source-queue?real=activemq://@?username=username@amp;password=password"/>
>         <to 
> uri="virtual://destination-queue?real=activemq://@?username=username@amp;password=password"/>
>     </route>
> Then in a virtual.properties file you would list the substitution template 
> values:
> *source-queue,destination-queue
> queue1-in,queue1-out
> queue2-in,queue2-out
> queue3-in,queue3-out
> The above properties file would be like adding 3 routes, the first being like:
>  <route>
>         <from 
> uri="virtual://source-queue?real=activemq://queue1-in?username=username@amp;password=password"/>
>         <to 
> uri="virtual://destination-queue?real=activemq2://queue1-out?username=username@amp;password=password"/>
>     </route>
> 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) and other scaling concerns
> * move to high level dsl model
> * unit tests
> * source configuration from enrichment uri call
> * more robust error handling
> * handling of ScheduledConsumers,async etc
> * expression (regex style) uri templating (current only @ value substituion)

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

        

Reply via email to