Hi,
I think it should be a best practice to copy the inMessage header if
return a list of new created Messages within the split method.
Willem
John Landahl wrote:
I've discovered strange behavior (at least to me) when using a file
consumer connected to a POJO splitter. Here's my route:
from("file:input").
split().method("fileSplitter", "split").
to("mock:out")
If my POJO returns a list of newly created messages (via "new
DefaultMessage()" as shown in the examples), the File component
appears to forget its various path settings, which results in the
following error when fileSplitter.split() finishes:
ERROR GenericFileOnCompletion - Caused by:
[org.apache.camel.component.file.GenericFileOperationFailedException -
Cannot rename file: GenericFile[foo] to: GenericFile[/.camel/]]
For some reason it's trying to write to "/.camel", when it should be
writing to "input/.camel". It has forgotten its original path
("input").
However, if my POJO creates copies of the original message from the
File component (exchange.in.copy()), everything works as expected
because all the CamelFile* headers are there. It's as if the File
component needs to read the various headers (CamelFilePath,
CamelFileParent, etc.) from the next component's message(s) to know
how to proceed. But surely that can't be...
As a splitter, shouldn't my POJO be able to return a list of newly
created objects? Or should they always be copies of the input message?
