Ok, I forgot about implicit type conversion. I can see that if
RemoteFile gets routed to,
for example, a bean method with signature public void
processFile(InputStream input),
that Camel will convert RemoteFile to BufferedInputStream. I also was
able to get
a valid java.io.File instance by calling .convertBodyTo(File.class);
Ok, I'm good to go...
Thanks,
Chris
On Fri, Apr 12, 2013 at 12:25 PM, Chris Wolf cwolf.a...@gmail.com wrote:
I read the documentation:
http://camel.apache.org/ftp.html
and want to FTP large files, as such, I don't want the entire file
loaded into memory - I thought the localWorkDirectory option would
allow this. That web page says,
It will download the remote file directly to a local file stream. The
java.io.File handle is then used as the Exchange body.
Well, that's not what I'm seeing - what I see is that the body is of type
, BodyType:org.apache.camel.component.file.remote.RemoteFile
, Body:[Body is file based: RemoteFile[giant_dataset.csv]]
...but I expected it to be of type java.io.File, like the local
file:// component and like the ftp documentation says.
When stepping through the code, I see that the file *is* being
downloaded to the work dir.
If I look at the various fields of RemoteFile in the debugger, I don't
see anything indicating a file path which includes the local work
directory.
So how, exactly, does the localWorkDirectory mechanism work and is it
true that it won't load the whole file into memory? Why isn't the
exchange body of type java.io.File or java.io.InputStream? - I'm
confused - please help...
-Chris
