Aside from proving that your code works the major goal of any unit test is to provide a living document that shows how to actually use your code. Just writing a test to prove that everything is groovy is not enough. One day you, or another developer may want to add more functionality and it is your unit tests that show what it is capable of. That said I believe the major goal of any unit test is to clearly express what you code can do....
You have to be careful doing the obvious thing sometimes because it doesn’t always give you the result to want. For instance, I had a requirement to add a header to a message generated in an Apache Camel route. Seemed simple to be so I added this: <setHeader headerName="NEW_HEADER"> <constant>true</constant> </setHeader> The hidden issue with this is that the header will be a java.lang.String and it will have the value of “true”....
One of the key benefits of a SEDA queue is the ability to buffer requests and tasks within an Apache Camel route. You split up your processing into discrete tasks and then wire these tasks together using SEDA queues. You can then tune the number of consumers you have running against the queues to get the throughput that you need. To be able to do this tuning you need to know the back pressure on the consumers, i....
One of the nice things that Spring allows you to do is to add property placeholders to your configuration files and then define the values at runtime. The options are endless as to what you might want to use this feature for. One thing you cannot do though is to use a spring property placeholder inside Camel XML. You can find more details about why here http://camel.apache.org/how-do-i-use-spring-property-placeholder-with-camel-xml.html. Looking specifically at aggregators, imagine you wanted to do this:...