Hola Francisco, I'd opt for option #2 - would you be able to submit a patch?
TIA, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Apr 10, 2013 at 10:03 PM, Francisco Carriedo Scher < fcarrie...@gmail.com> wrote: > Hello there! > > Last week I was seeking for an extended funtionalities of the fileupload > library, only to find that such functionalities are not available yet ( > http://www.mail-archive.com/user@commons.apache.org/msg08530.html). The > two > extended functionalities are: > > - calculating the checksum (MD5, SHA1,...) on the fly as a file is > written to disk (just one time writing to disk and no need to have the > whole file in memory). > - allow the end user to specify the output stream where the data > received in the request should be dumped to. > > I see two possible approaches to get such functionalities: > > - Exposing the iterator used in the loop at FileUploadBase.java:341 > within the library to the user and then he can process each part of the > request using methods in the library (profiting the existing logic in > the > library). This approach would provide the two functionalities in a row, > as > the stream of the file to be saved to disk can be provided by the user, > i.e.: he is able to wrap it with a DigestOutputStream and with a > FileOutputStream pointing to the end destination of the data on the file > system for example. > - Extending the existing classes (DiskFileItemFactory, DiskFileItem) to > provide separately the desired functionality, with no modification in > the > library. > > Although I understand that the second choice would ensure to profit all the > existing correctness in the existing library I find the first one very > flexible and would like to get some critics for this approach as i can > imagine that there might be drawbacks I am missing. > > Thank you very much for your attention, keep up the good work! >
