Ken,
On 4/19/2010 12:06 PM, Ken Bowen wrote:
<form name="csvUploadForm" action="csvfileupload" method="post"
enctype="multipart/form-data"> File:<input type="file"
name="csvfile2upload"><br></br> <input type="submit" name="Submit"
value="Upload CSV File" onclick="uploadCSVFile();return false;">
</form>
Looks good, except for that "uploadCSVFile" javascript trigger. Why
not
just do a regular file upload? Is this some kinda AJAX thing?
The CSVFileUpload servlet doPost method uses
org.apache.commons.fileupload.servlet.ServletFileUpload; to accept
and process the upload, and puts the resulting data into the db. If
I don't care about duplicates or partial matches, this works fine;
at
the end of the servlet processing, I execute
response.sendRedirect("/myStartPage.jsp"); -- where response is the
doPost's HttpServletResponse.
That seems fine (ignoring the mismatch between myStartPage.jsp and
nextPage.jsp).
String nextJSP = "/nextPage.jsp"; RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(nextJSP);
dispatcher.forward(request, response);
That's the correct way to do a forward.
Unfortunately, I'm running into the following errors showing in the
log:
WARNING: Nested in javax.servlet.ServletException:
org.apache.commons.fileupload.FileUploadBase
$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null:
org.apache.commons.fileupload.FileUploadBase
$InvalidContentTypeException:
the request doesn't contain a multipart/form-data or multipart/mixed
stream, content type header is null at
org.apache.commons.fileupload.FileUploadBase
$FileItemIteratorImpl.<init>(FileUploadBase.java:885)
at
org
.apache
.commons
.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at
org
.apache
.commons
.fileupload
.servlet.ServletFileUpload.getItemIterator(ServletFileUpload.java:
148)
at
com
.formrunner
.servlets.CSVFileUploadServlet.doPost(CSVFileUploadServlet.java:53)
at
com
.formrunner
.servlets.CSVFileUploadServlet.doGet(CSVFileUploadServlet.java:29)
From
the information you've given, it looks like the
CSVFileUploadServlet is being invoked on a request that doesn't
have the
proper formatting. You might want to change your
CSVFileUploadServlet to
check the Content-Type of the request before invoking the
commons-file-upload stuff so you can give a better error message to
your
users.
This could be happening due to a couple of reasons:
1. Your URL mapping is too wide-reaching and the CVS upload servlet
is
handling the request to /nextPage.jsp, which would be weird.
2. Your are seeing an error for a request other than the one you
think
you are.
I recommend checking for the Content-Type and then dumping a bunch of
information about the request if it's not multipart/form-data: things
like the URL, method and maybe the parameters, too.
The browser actually displays the nextPage.jsp page. However, if
one then clicks any navigation button, you get a version of the
warning above showing in the browser.
Do you have a link like <a href=""> that could be going to the wrong
place? Presumably, navigation links shouldn't take you to the
CSVFileUploadServlet... only form POSTs.
My goal is to get from the CSVFileUpload servlet to the nextPage.jsp
with the "partialMatch" data in hand.
...whatever that is.
In the normal use case, this will only be a couple of text lines.
However, at the extreme it could be hundreds of lines of mismatches.
I really don't care how I accomplish the transition to nextPage.jsp,
so if there's a better way than what I'm attempting here, please let
me know. {Anything written on the web would be great.} [I assume
that I could store the "partialMatch" data in the db under some
appropriate key, get to nextPage using response.sendRedirect, and
then retrieve the info, but that seems like more of a hack than
ought
to be necessary here.]
Keeping state in the request is always risky, because after it's
over,
the user has to re-submit everything in order to basically see the
same
result. It's idempotent, but not particularly elegant.
Keeping state in the session is always risky because the session can
expire /and/ you can also bust your heap if it's a lot of data. If
session timeouts are a concern, you have to encode a bunch of
information in the request to recover the session in those cases.
Putting the data into the database is not particularly convenient,
but
it will save you from worries about memory exhaustion as well as
having
to repeatedly shuttle lots of data from the client to the server and
back. Think: do you want your users to have to re-upload files
after the
"mismatches" have been identified and resolved? Or, do you just
want to
apply whatever mitigation steps have been chosen by the user on the
data
already on the server?
-chris
