Customer comments:
==================
This test case exercises the camel transaction support with File Component. It demonstrates that the 1.4.0 release does not handle failures correctly in transactional routes whose starting endpoint is a file poller.

Notes:

a) this is currently configured for a mysql database (in the context defn)
b) the location of the file dir is hardwired in the context and the java test class.

Problems:

• There are no redelivery attempts.
• The behaviour is not transactional - writes to the database are not rolled back.
• Failure on file 2 does not prevent files 3 & 4 being processed.

Support comments:
=================
All behavior described by the customer was reproduced on test environment. Part of these problems were already
observed in the link above. Looks like the association of transaction support with a route scoped error handler is
not working as expected.

I am not sure the third problem (Failure on file 2 does not prevent files 3 & 4 being processed.) is a problem.
In my opinion each file created in the source directory creates a distinct exchange in the camel route so each
one is related to a distinct transaction.

The customer reported the files were moved in transaction roll back scenarios. I was unable to reproduce this
behavior. When an exception was raised by the ExceptionThrowerProcessor, the files were not moved to the
destination directory. But something strange happened in these cases: the ".lock" files are not removed
from the source directory. Not sure if this is excepted behavior. Maybe this is a way to prevent the file component to
keep trying to process a defective file but I am not sure.

The diagnose:
=============
There is a bug in errorHandler component that is reproduced by this test case. The errorHandler is not retrying
to deliver the messages and the transaction is not being rolled back after an exception is raised be a processor.