File consumer + POJO splitter

[John Landahl <jo...@landahl.org>]

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?

Re: File consumer + POJO splitter

[Claus Ibsen <cl...@gmail.com>]

On Thu, Apr 15, 2010 at 1:45 AM, John Landahl <jo...@landahl.org> wrote:
> On Tue, Apr 13, 2010 at 7:26 PM, Willem Jiang <wi...@gmail.com> wrote:
>> 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.
>
> That may be, but how is it that /not/ doing this results in errors in
> the File component?
>

What version of Camel are you using?


-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Re: File consumer + POJO splitter

[John Landahl <jo...@landahl.org>]

On Tue, Apr 13, 2010 at 7:26 PM, Willem Jiang <wi...@gmail.com> wrote:
> 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.

That may be, but how is it that /not/ doing this results in errors in
the File component?

Re: File consumer + POJO splitter

[Willem Jiang <wi...@gmail.com>]

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