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
