Just to flesh this out a bit: You need to create your own implementations of FileSystemView, and possibly File. You'd write an implementation of FileSystemFactory which returns your FileSystemView.
Then you would use a <filesystem> element in your <server/> to specify your custom FileSystemFactory. It sounds as if, except for certain "virtual" files, you want your server to act as normal. Therefore I guess you could have your customer FileSystemView forward method calls to an instance of the standard NativeFileSystem, except in the circumstance you define. On 3 March 2011 12:54, David Latorre <[email protected]> wrote: > I agree with nilkas here for your use case. Still, are you sure you > don't need to store the file? I think there are a number of reasons, > mainly traceability, for you to keep those files as 'a backup' or in > case the file cannot be parsed. I would rather have a copy of the > file that failed so I can check what the problem was. > > > Cheers, > > David > > > 2011/3/3 Niklas Gustavsson <[email protected]>: > > On Wed, Mar 2, 2011 at 8:03 PM, Pierre-Luc Pineault > > <[email protected]> wrote: > >> All I want is to parse a text file send by a user without storing the > file on the server. So, I see this is possible to get the data input stream > from request by Ftplet onUploadStart(session, request). So, I want to get > the stream and parse each line to store the data in a database. > >> For the momment i am working with onUploadEnd() and I delete the file > once parsed. But, the best way for us is to parse. > > > > While you probably can solve this from an Ftplet, I would recommend > > looking into writing a custom filesystem for this purpose. > > > > /niklas > > > -- "There is no way to peace; peace is the way"
