commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rhino" <rhi...@sympatico.ca>
Subject Re: [FileUpload] Typo in error message
Date Mon, 20 Dec 2004 19:26:27 GMT

----- Original Message ----- 
From: "Martin Cooper" <mfncooper@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Sent: Monday, December 20, 2004 11:21 AM
Subject: Re: [FileUpload] Typo in error message


> On Mon, 20 Dec 2004 09:37:10 -0500, Rhino <rhino1@sympatico.ca> wrote:
> > I was just testing a servlet that uses Commons FileUpload and
deliberately
> > chose a file that was above the threshold size. I got the expected
> > FileUploadException and this message:
> >
> > org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException:
the
> > request was rejected because it's size exceeds allowed range
> >
> > The word "it's" in this message should actually be "its". "It's" is
always
> > short for "it is" while "its" denotes the possessive case, which is the
> > appropriate choice for this sentence. Sorry, I don't mean to be a
grammar
> > cop but two years of having this drummed into my head when I was a kid
makes
> > these little errors jump out at me ;-) Normally, I wouldn't say anything
but
> > since the developers probably want FileUpload to look as professional as
> > possible, I thought I should mention it.
>
> Fixed in CVS. Not sure how I missed that - I'm just as picky as you
> are about grammar. ;-)
>
Hey, nobody's perfect; I make spelling and grammar errors myself sometimes
;-)

> > It would be excessive to issue a new version of FileUpload just to fix a
> > simple typo so maybe this change can be fixed in the next version of
> > FileUpload, assuming there is ever a need for another version of
FileUpload
> > ;-)
>
> There will be a new release sometime soon-ish, with a bunch of new
> features, including a servlet filter, portal support, XML
> configuration, and some refactoring. Much of this is in CVS already,
> and the rest is mostly done on my disk but needs some finishing up and
> more unit tests.
>
Great! I'm not sure I need any of that stuff yet but I'm sure I'll be glad
it's there when I do need it. ;-)

> > By the way, it would be neat if the message actually *stated* the
maximum
> > size that had been exceeded and maybe the size of the file that the user
had
> > attempted to upload. Although the developer that uses FileUpload in his
> > servlet could do this in their own error message, the FileUpload code
surely
> > knows both values too so it would be useful to see this in the message
and
> > save the user the trouble....
>
> Good idea. If you wouldn't mind submitting an enhancement request for
> this in the bug tracking system, that will make sure I don't forget
> about it.
>
> http://issues.apache.org/bugzilla/
>
Done!

> Thanks!
>
You're very welcome!

By the way, before I forget, I am just finishing up a prototype of a servlet
that utilizes FileUpload. I'm doing this to learn the key features of
FileUpload without getting bogged down in a lot of application logic. It
struck me that you might have some use for this in the documentation of
FileUpload: it could be a full, working example of the main things you do
with FileUpload, including validity checking and error handling for problems
that occur.

My premise is a simple form with two plain text fields (first name and last
name), plus three file upload fields. The servlet that handles the form
ensures that the text fields are valid (i.e. non-blank), then stores the
files on the user's file system. (The location at which the files will be
stored depends on whether the servlet is running on Unix or Windows; the
init() of the servlet determines which OS is running and gets the
appropriate storage path from an init parameter in web.xml). The file proper
is stored in the appropriate directory; the two text fields are stored in
one database table and the names of the uploaded files (and a key to relate
them back to the form) are stored in a second database table. The servlet
will work with either DB2 or MySQL. (The multiple database aspect of this
prototype may unduly complicate it for the purposes of an example so I could
strip that out if you like and simply write a few lines to the Tomcat log or
a text file to simulate the database work.)

My prototype will handle each of the following in a user-friendly manner and
log the problem appropriately:
a) One of the text files is invalid.
b) The aggregate size of all files to be uploaded exceeds the limit for that
servlet.
c) The size of *individual* files that the user wants to upload are larger
than a separate maximum.
d) The JDBC driver can't be found.
e) A database connection can't be obtained.
f) Autocommit can't be set.
g) A duplicate row is being inserted into either table.
h) The write of the uploaded file to the server's file system throws an
exception.

I used to teach DB2 at IBM and I've always really learned a lot from good
clear examples. Perhaps the users of FileUpload might benefit from this
prototype (with or without the database logic.) If you're not interested,
that's fine; the existing documentation is already a good start on using
FileUpload.

Rhino
> --
> Martin Cooper
>
>
> >
> > Rhino
> > ---
> > rhino1 AT sympatico DOT ca
> > "There are two ways of constructing a software design. One way is to
make it
> > so simple that there are obviously no deficiencies. And the other way is
to
> > make it so complicated that there are no obvious deficiencies." - C.A.R.
> > Hoare
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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


Mime
View raw message