DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory

[Forrest Girouard <Fo...@openwave.com>]

Folks:

Why does the DiskFileUpload require that the factory be of type 
DefaultFileItemFactory instead of FileItemFactory?  This seems 
needlessly restrictive.

Cheers,
	Forrest


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory

[Martin Cooper <ma...@apache.org>]

On Fri, 5 Mar 2004, Noel J. Bergman wrote:

> > > Please file an enhancement request against the Struts FileUpload
> > > component, so that I can track this.
>
> Martin, I have a small utility class that tracks a filename and associated
> marker object.  You can't use just a File, of course, since File instances
> are often far more transient than the objects used to perform I/O.  But you
> could do FileCleaner.track(myFile, myIOObject), and when myIOObject goes
> away, the file referenced by myFile will be removed.
>
> Helpful to your situation?

Possibly, yes. The myIOObject could be a FileItem, for example?

Is this something that would make sense as part of Commons IO?

--
Martin Cooper


>
> 	--- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory

["Noel J. Bergman" <no...@devtech.com>]

> > Please file an enhancement request against the Struts FileUpload
> > component, so that I can track this.

Martin, I have a small utility class that tracks a filename and associated
marker object.  You can't use just a File, of course, since File instances
are often far more transient than the objects used to perform I/O.  But you
could do FileCleaner.track(myFile, myIOObject), and when myIOObject goes
away, the file referenced by myFile will be removed.

Helpful to your situation?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory

[Forrest Girouard <Fo...@openwave.com>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: DiskFileUpload requires a DefaultFileItemFactory instead of just a FileItemFactory

[Martin Cooper <ma...@apache.org>]

On Wed, 3 Mar 2004, Forrest Girouard wrote:

> Folks:
>
> Why does the DiskFileUpload require that the factory be of type
> DefaultFileItemFactory instead of FileItemFactory?  This seems
> needlessly restrictive.

It's required because the DiskFileUpload class includes methods that turn
around and invoke the equivalent methods on the DefaultFileItemFactory
class. Those methods are specific to disk-based uploads, and not present
in the generic classes and interfaces.

If you don't want the restrictions of the disk-based implementation, then
you can use FileUpload instead of DiskFileUpload.

--
Martin Cooper

PS - Please don't cross-post to both commons-dev and commons-user.


>
> Cheers,
> 	Forrest
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org