On 19/04/2010 22:21, Christopher Schultz wrote:
> 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).
... and that one is a redirect & one is a forward?
p (confused)
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
signature.asc
Description: OpenPGP digital signature
