Re: DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory

[Forrest Girouard]

Martin:

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

Cheers,
        Forrest
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]