-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvMyWgACgkQ9CaO5/Lv0PBh8ACghZQnjby2vv3hjRKCV/pbcrei
38YAn1IO2Y+tLL8xbgsoTuDpr+DA0YJo
=CHhi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
