commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Forrest Girouard <>
Subject Re: DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory
Date Fri, 05 Mar 2004 16:07:29 GMT

I've submitted an enhancement request (27477) per your request.


On Mar 4, 2004, at 11:16 PM, Martin Cooper wrote:

> On Thu, 4 Mar 2004, Forrest Girouard wrote:
>> I just attempted to extend CommonsMultipartRequestHandler so that I 
>> can
>> override handleRequest(HttpServletRequest) but unfortunately the
>> Hashtables of elements (elementsText, elementsFile, and elementsAll)
>> must be initialized by the overriding implementation of that method
>> which is not possible given that they are private.  Shouldn't they be
>> protected?
> Yup, that's a bug. To be honest, when I wrote that class, I was really
> focussed on getting something in place that was more reliable than the
> original Struts multipart handler, so I wasn't thinking so much about
> reuse (although it bugged me that the interface uses Hashtables rather
> than HashMaps).
> Please file an enhancement request against the Struts FileUpload
> component, so that I can track this.
>> In the bigger picture, are you aware that
>> CommonsMultipartRequestHandler's use of the no-arg constructor of
>> DiskFileUpload exposes the container to crashes due to the use of
>> File.deleteOnExit() in DefaultFileItem.getTempFile()?
> I was not aware of that until the thread on that topic started up
> yesterday. ;-) I guess I'll need to look at that sometime soon. Any
> ideas much appreciated...
>> Interestingly enough I can readily reproduce the crashes using the AIX
>> JRE but not the Sun JRE even though in theory they share the same
>> flawed native code associated with File.deleteOnExit().  Any ideas on
>> why that might be?
> None at all, I'm afraid.
> --
> Martin Cooper

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message