Java小程序似乎使用旧的响应对象给出jsession ID时 [英] Java Applet seems to use old response object when given jsession id
问题描述
我在我的JSF页面文件上传小程序。此applet期待一个ADRESS它可以把它的POST请求。 （我不能编辑这个职位要求添加更多的字段或东西）。我的servlet的POST方法，然后存储文件。这项工作不能由托管bean来完成，因为servlet有与@MultiPartConfig被注解，我不能这个注释添加到JSF托管bean。为了强制上传小程序来使用我按照这个添加了一个名为JSESSIONID的URL属性POST请求同一会话<一个href=\"http://stackoverflow.com/questions/13194034/accessing-jsf-session-scoped-bean-from-servlet-which-is-called-by-applet-embedde\">topic.现在每当我试图在会议期间上传多个文件的小程序的正则表达式的字符串^ SUCCESS $，在响应主体没有被发现的错误信息会停止，这是因为小程序预计这个字符串在servlet的响应为了知道上传的内容是全成。
I have a file upload applet in my jsf page. This applet expects an adress where it can send it's POST request. (I can't edit this post request to add more fields or something). The post method of my servlet then stores the file. This job can't be done by a managed bean because the servlet has to be annotated with @MultiPartConfig and I can't add this annotation to the jsf managed bean. In order to force the upload applet to use the same session I added an URL attribute named jsessionId to the post request according to this topic. Now whenever I try to upload more than one file during a session the applet stops with the error message "The regexp string "^SUCCESS$" was not found in the response body" this is because the applet expects this string in the servlets response in order to know that the upload was successfull.
当我查看小程序的调试code响应包含了很多的html code，但不是这种成功串altough我加在我的Servlet code。这里是我的servlet的code：
When I view the debug code of the applet the response contains a lot of html code but not this success string altough I add it in my Servlet code. Here's the code of my servlet :
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.reset();
if (!userBean.getUploadedDatasets().isEmpty()) {
String datasetID = userBean.getUploadedDatasets().getLast().replaceAll("/", "%2F");
response.sendRedirect(response.encodeRedirectURL("http://____________/faces/details.xhtml?id="+datasetID));
}
}
/**
* Handles the HTTP
* <code>POST</code> method.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response){
PrintWriter out = null;
try {
Part filePart = request.getPart("item");
InputStream filecontent = filePart.getInputStream();
String datasetID = repBean.persistDataset(filecontent, uploadBean.getFolder());
userBean.getUploadedDatasets().add(datasetID);
out = response.getWriter();
out.println("SUCCESS");
} catch (ServletException ex) {
Logger.getLogger(RequestHandler.class.getName()).log(Level.SEVERE, null, ex);
} catch (IOException ex) {
Logger.getLogger(RequestHandler.class.getName()).log(Level.SEVERE, null, ex);
}finally{
out.close();
}
}
doGet方法是由小程序用作afterUploadURL（所以这是给它一个文件上传后跳下URL）
the doGet method is used as afterUploadURL by the applet (so that's the url to which is jumped after a file is uploaded)
该applet code是：
the applet code is :
<APPLET
CODE="wjhk.jupload2.JUploadApplet"
NAME="JUpload"
ARCHIVE="wjhk.jupload.jar"
WIDTH="640"
HEIGHT="300"
MAYSCRIPT="true"
ALT="The java pugin must be installed.">
<param name="postURL" value="http://________________/request;jsessionid=#{session.id}" />
<!-- Optionnal, see code comments -->
<param name="showLogWindow" value="false" />
<param name="debugLevel" value="99" />
<param name="httpUploadParameterName" value="item" />
<param name="nbFilesPerRequest" value="1" />
<param name="httpUploadParameterType" value="oneFile" />
<param name="afterUploadURL" value="http://________________/request" />
</APPLET>
和尝试上载第二个文件，旧（这是我的看法，但我不知道有足够的了解servlet的）响应看起来像这样经过：的 http://pastebin.ca/2300999
（字符太多，所以我不得不把它上传有）
and after trying to upload a second file, the "old" (that's what I think but I don't know enough about servlets) response looks like this : http://pastebin.ca/2300999 (too many characters so I had to upload it there)
推荐答案
您的问题是因为servlet发送GET上（和含蓄也HEAD）的请求重定向造成的。日志的以下部分包含相关信息：
Your problem is caused because the servlet is sending a redirect on GET (and implicitly also HEAD) request. The following part of the log contains relevant information:
00064 13:44:42.482 HttpProtocolFinderThread [DEBUG] Getting serverProtocol from HEAD request
00065 13:44:42.485 HttpProtocolFinderThread [DEBUG] Checking protocol with URL: http://___________________:8080/application1/request;jsessionid=47440f88e532021656b3724eea33
00066 13:44:42.501 HttpProtocolFinderThread [DEBUG] [initByteArrayEncoder] proxy=DIRECT, proxy.type=DIRECT, useProxy=false, url.host=___________________, url.port=8080
00067 13:44:42.501 HttpProtocolFinderThread [DEBUG] [onAppendHeader] Start
00068 13:44:42.502 HttpProtocolFinderThread [DEBUG] [onAppendHeader] Header appended; Cookie: __utma=132868616.170774110.1354796930.1356109339.1356547898.3; __utmz=132868616.1356547898.3.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
00069 13:44:42.509 HttpProtocolFinderThread [DEBUG] [onAppendHeader] Header appended; User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
00070 13:44:42.510 HttpProtocolFinderThread [DEBUG] [onAppendHeader] End
00071 13:44:42.510 HttpProtocolFinderThread [DEBUG] [HTTPConnectionHelper append]
00072 13:44:42.511 HttpProtocolFinderThread [DEBUG] Before sendRequest()
00073 13:44:42.511 HttpProtocolFinderThread [DEBUG] Using non SSL socket, direct connection
00074 13:44:42.538 HttpProtocolFinderThread [DEBUG] After sendRequest()
00075 13:44:42.538 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00076 13:44:42.538 HttpProtocolFinderThread [DEBUG] ----------------- HEAD message sent (start) --------------------------
00077 13:44:42.539 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] HEAD /application1/request;jsessionid=47440f88e532021656b3724eea33 HTTP/1.1
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Host: ___________________:8080
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Accept: */*
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Accept-Encoding: identity
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Connection: close
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Cookie: __utma=132868616.170774110.1354796930.1356109339.1356547898.3; __utmz=132868616.1356547898.3.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG]
00079 13:44:42.539 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00080 13:44:42.540 HttpProtocolFinderThread [DEBUG] ----------------- HEAD message sent (end) -----------------------------
00081 13:44:42.540 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00082 13:44:42.548 HttpProtocolFinderThread [DEBUG] -------- Response Headers Start --------
00083 13:44:42.556 HttpProtocolFinderThread [DEBUG] HTTP/1.1 302 Moved Temporarily
00084 13:44:42.558 HttpProtocolFinderThread [DEBUG] Location: http://___________________:8080/application1/faces/details.xhtml;jsessionid=47440f88e532021656b3724eea33?id=%2F37ded64f-f2c9-4b90-99ea-79c34eb140e5
00085 13:44:42.559 HttpProtocolFinderThread [DEBUG] Content-Type: text/html;charset=ISO-8859-1
00086 13:44:42.566 HttpProtocolFinderThread [DEBUG] Content-Language: de-DE
00087 13:44:42.578 HttpProtocolFinderThread [DEBUG] Content-Length: 306
00088 13:44:42.578 HttpProtocolFinderThread [DEBUG] Date: Thu, 10 Jan 2013 12:44:42 GMT
00089 13:44:42.579 HttpProtocolFinderThread [DEBUG] Connection: close
00090 13:44:42.579 HttpProtocolFinderThread [DEBUG]
00091 13:44:42.580 HttpProtocolFinderThread [DEBUG] --------- Response Headers End ---------
00092 13:44:42.580 HttpProtocolFinderThread [DEBUG] This is a HEAD request: we don't care about the bytearrayResponseBody
00093 13:44:42.584 HttpProtocolFinderThread [DEBUG] HEAD status: 302
00094 13:44:42.585 HttpProtocolFinderThread [DEBUG] HEAD protocol: HTTP/1.1
00095 13:44:42.586 HttpProtocolFinderThread [DEBUG] Location read: http://___________________:8080/application1/faces/details.xhtml;jsessionid=47440f88e532021656b3724eea33?id=%2F37ded64f-f2c9-4b90-99ea-79c34eb140e5
00096 13:44:42.594 HttpProtocolFinderThread [INFO] postURL switched from http://___________________:8080/application1/request;jsessionid=47440f88e532021656b3724eea33 to http://___________________:8080/application1/faces/details.xhtml;jsessionid=47440f88e532021656b3724eea33?id=%2F37ded64f-f2c9-4b90-99ea-79c34eb140e5
该小程序基本上是由HEAD请求测试 postURL 的可用性，一旦确定，它被重定向，它使用重定向的URL作为新的 postURL （按照copypasted日志的最后一行）。但是，重定向的URL指向返回一大堆HTML的JSF页面。
The applet is basically testing the availability of postURL by a HEAD request and once determined that it's been redirected, it's using the redirected URL as new postURL (as per the last line of the copypasted log). However, the redirected URL is pointing to a JSF page which returns a whole bunch of HTML.
您需要修改你的的doGet（），它不执行重定向，或者添加 doHead（）返回有效一无所获。作为一个HEAD是每个基本HTTP规范的GET没有响应主体，默认 doHead（）实施委托给的doGet（）并丢弃响应主体。重写 doHead（）应委托给的doGet prevent它（）。
You need to fix your doGet() that it doesn't perform a redirect, or to add a doHead() which returns effectively nothing. As a HEAD is per the HTTP specification basically a GET without a response body, the default doHead() implementation delegates to the doGet() and discards the response body. Overriding the doHead() should prevent it from delegating to doGet().
这篇关于Java小程序似乎使用旧的响应对象给出jsession ID时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
