I’m looking forward to a noop option in future Camel releases which could further reduce the need for custom logic or “workarounds” like the multicast EIP.

The new SQL component options in the upcoming Camel 2.11 sound indeed like an interesting alternative to the Timer endpoints and the SqlExecutor#selectNewTransfers method as described in the article. The new option “useIterator” looks like an appropriate alternative to the “<split/>” usage, too.

The named parameters are interesting as well. Wouldn’t it be even nicer if their resolving process would consider the Exchange’s properties, too?
Here is a simple (untestet) example what I mean:

<route>
  <setProperty name="prop1"><simple>${TransferId}</simple></setProperty>
  <!-- ${body}: contains the SOAP message -->
  <to uri="sql:UPDATE TRANSFER SET RESPONSE_XML = # WHERE ID = :prop1"/>
</route>

I took the liberty of adding a link to this blog entry from the Camel articles page (our link collection, takes a while to sync the change).
http://camel.apache.org/articles

From Camel 2.11 onwards the SQL component now also supports consumer side, so you don’t need to trigger this with the timer component anymore.

Though a good idea with the “noop” so you can execute the SQL but dont change the message body. I will log a ticket to get this implement in the SQL component.

I agree about the parameter mappings. Its been improved in 2.11, to allow using named parameters. But so far it only grabs from body/headers. Not sure if there is a good way to define a syntax that don’t get to verbose in the DSL.

Some people use a template language to do the mapping and build dynamic queries. For example with freemarker / velocity etc.

PS: I personally like the spring jdbc template for SQL stuff. Its very flexible and you can do all in the Java code.

Another alternative is MyBatis when you have more extensive mapping needs as its excellent for that.

Looking forward to the next blogs.

/Claus Ibsen
Apache Camel committer

Great article which will help me develop a full-fledged test driven software development life cycle. I’d love to see the part 2 of this article.

Thanks so much for your efforts.

1. “In general, any hash-based collection is problematic” – that is wrong.

Let’s consider more simple case, array of Comparable objects. Suppose you have an array of Comparable objects, e.g. orderable by phone number:
[{"444", "IBM"}, {"555", "MS"}, {"333", "MGM"}]

You call Arrays.sort(phoneNumbers) and the array becomes sorted ascending. Suppose it looks like follows:
[{"333", "MGM"}, {"444", "IBM"}, {"555", "MS"}]
Then you modify the phone number of one of the objects: “555″ -> “111″:
[{"333", "MGM"}, {"444", "IBM"}, {"111", "MS"}]
The order is broken.

If you suppose that the last element has the biggest number, it is wrong now. If you suppose that the first element has the smallest number, it is wrong now.

Would you say “In general, any Comparable array is problematic”?

I guess no. The same about hash-based collections. They are not problematic. You just use them not properly and your expectations are wrong.

2. You describe HashSet.contains() and equals(), but you fail to see the essential contract of hashCode():
“If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.”

It is bad that you have not provided your implementation of equals(). Does it use both name and number? Or only name? Or only number? Or none (default from Object)?
Suppose you use both name and number.

- If your equals() uses number, than changing the number also changes the behaviour of equals(). Then the behaviour of the set is perfectly CORRECT. Just see the documentation:
“The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons …”.
After you modified the number “in a manner that affects equals comparisons”, you CANNOT expect any particular behaviour of any methods, including contains(). It means in particular that contains() can now return ANY value (true/false) for ANY object. Your expectation that contains(obj) will still return true is WRONG.

- If you equals() does not use ‘number’ (suppose you use ‘name’ only), then you are really allowed to expect that contains(obj) returns true. But in this case you have another error. Namely, your hashCode() violates the contract. If equals() doesn’t use the number attribute and if two objects are equal, they MUST have the same value of the hashCode() -> it means that hasCode() cannot depend on the number -> it means your hashCode() is wrong, it is not allowed to use the number -> if you fix the hashCode() according to the contract then the problem with HashSet disappears too.

- The same, but shorter:
if your modification changes hashCode(), then it affects equals() too, (otherwise it would violate the hashCode() contract that equal objects have the same hash code).
But if equals() changes, then according to the Set contract “The behavior of a set is not specified”.
It means you cannot expect any particular result from contains(obj).

Conclusion:
Your problem is not the HashSet, but your violation of several contracts:
- You ignore the contract between hashCode() and equals()
- You ignore the contract that “behavior of a set is not specified” if your modification affects equals()
- As a consequence of these your errors you erroneously suppose a design flaw in the hash-based collections
- You don’t see that the same behaviour exists for other implementations like TreeSet

Basically, you should not modify objects during the “life cycle” of the set. Namely, there should not be cahnges that affect equals().

Solution:
I don’t know what problem are you trying to solve. That’s why I don’t have ready solution for you.
- If you have a collection of companies and they are distinguished by the name, then equals() and hashCode() should only contain name, not a number. Then modifying the number will not cause any problems with Set.
- May be you need a unique ID (or a primary key in DB) to distinguish the objects
- May be you need a special kind of collection. Then forget hashCode(), keep in mind equals() only, and answer following question:
– If one object in the collection is modified and becomes equal to another one, should the collection remove one of duplicates automatically? Which one?
– If not remove automatically, then how should then work the remove() method? Should it remove all objects that equal to it, or only one of them? Which one?