[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: Recent change to FileUpload's DefaultFileItem
From:       Martin Cooper <martinc () apache ! org>
Date:       2003-04-30 17:38:20
[Download RAW message or body]



On Wed, 30 Apr 2003, Martin Cooper wrote:

>
>
> On Wed, 30 Apr 2003, Robert Leland wrote:
>
> > Martin Cooper wrote:
> > >
> > > On Wed, 30 Apr 2003, Howard M. Lewis Ship wrote:
> > >
> > >
> > >>http://cvs.apache.org/viewcvs/jakarta-commons/fileupload/src/java/org/apache
> > >>/commons/fileupload/DefaultFileItem.java.diff?r1=1.16&r2=1.17&diff_format=h
> > >>
> > >>Tapestry uses the DefaultFileItem.getStoreLocation() method, which has been
> > >>removed.
> > >
> > >
> > > That method was not removed - it is still there, with the same signature -
> > > so there must be something else that's causing a breakage.
> >
> > It was removed from the FileItem. We normally transfer 100MB to 500 MB
> > files. Making copies of files that already exist on a disk is slow and
> > can add more than a minute to the transfer time which was only 4 minutes
> > to start with. The getStoreLocation() allowed a fast rename() to take place.

By the way, if the data is on disk, write() will attempt to rename the
file, and will only copy the data if the rename fails. So you should be
able to do what you need without getStoreLocation().

--
Martin Cooper


>
> It was removed from FileItem because it is tied to Files. FileItem needs
> to be generic enough that you could use it for storage elsewhere, such as
> in a database, without any lingering remnants of file system specific
> storage left in the interface.
>
> This is why there is now a DiskFileUpload class, as well as FileUpload
> which is now much more generic.
>
> How about if I create a DiskFileItem interface that extends FileItem and
> is implemented by DefaultFileItem and exposed by DiskFileUpload? WOuld
> that do the trick?
>
> > Previously we depended on if getStoreLocation() returned a null then we
> > had to do stream copy for the smaller files.
>
> The determination of whether the item is in memory or on disk can be made
> using FileItem.isInMemory().
>
> > We were also running with a
> > modified version of Struts to expose the getStoreLocation() to the
> > application. I had planned to make this small change in Struts 1.2 but
> > now this won't work. From a standard Struts distribution, there needs to
> > be a way to access the File or path to a file, from the Struts upload
> > wrappers.
>
> I also have some changes in mind for the Struts multipart handling, post
> 1.1 Final. We should talk about this on the Struts list. ;-)
>
> --
> Martin Cooper
>
>
> >
> >
> >
> > -Rob
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

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

[prev in list] [next in list] [prev in thread] [next in thread]