InputStream无限循环

问题描述 投票:0回答:2

我正在尝试将文件从Android上传到运行Jersey的Tomcat服务器。我将它打包在一个Post Request中。

这就是我在Android中所做的:

protected String doInBackground(String... params) {
    String url = params[0];
    String pathToFile = params[1];
    HttpClient httpClient = new DefaultHttpClient();
    HttpContext localContext = new BasicHttpContext();
    HttpPost httpPost = new HttpPost();
    HttpResponse response = null;
    httpPost.addHeader("Cookie", "sessionToken=~session");
    try {
        httpPost.setURI(new URI(url));
        httpPost.setHeader("Accept", "application/json");
        MultipartEntity entity = new MultipartEntity(
                HttpMultipartMode.BROWSER_COMPATIBLE);
        File file = new File(pathToFile);
        if(!file.exists())
            return null;
        FileBody fileBody = new FileBody(file);
        entity.addPart("file", fileBody);
        httpPost.setEntity(entity);

        response = httpClient.execute(httpPost);
        HttpEntity result = response.getEntity();
    } catch (ClientProtocolException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    } catch (URISyntaxException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    } catch(Exception e){
        e.printStackTrace();
    }
    return response.getStatusLine().toString();

在服务器中我有以下内容:

我收到一个类型为“org.jvnet.mimepull.DataHead $ ReadMultiStream”的InputStream,在读取它时,读取到达文件末尾后的1024。

@POST
@Consumes({ MediaType.MULTIPART_FORM_DATA })
@Produces({ MediaType.APPLICATION_JSON })
public Response uploadStorageFile(@Context UriInfo ui, @Context HttpHeaders hh, @FormDataParam("file") 
InputStream uploadedInputStream, @FormDataParam("file") FormDataContentDisposition fileDetail){
    System.out.println(uploadedInputStream.getClass().getName());
    String uploadedFileLocation = fileDetail.getFileName();
    long size = fileDetail.getSize();
    // save it
    writeToFile(uploadedInputStream);

    String output = "File uploaded to : ";

    return Response.status(200).entity(output).build();

}
private void writeToFile(InputStream uploadedInputStream) {

        try {
            OutputStream out = new FileOutputStream(new File("test.jpg"));
            int read = 0;
            byte[] bytes = new byte[1024];
            while ((read = uploadedInputStream.read(bytes)) > 0) {
                out.write(bytes, 0, read);
            }
            out.flush();
            out.close();
        } catch (IOException e) {

            e.printStackTrace();
        }

    }

如果文件的长度是8192,那么循环如下:1024,2048,3072,4096,5120,6144,7168,8192,1024 - >为什么?

注意:我已尝试将条件设置为-1。

任何人都能弄明白发生了什么事吗?

java tomcat file-upload jersey
2个回答
2
投票

由于这有助于您解决问题,您的最新评论表明this bug was responsible.

ReadMultiStream类上的两个方法“read”都违反了已实现的接口java.io.InputStream的契约。 Javadoc声明,-1应该在流的末尾返回,但是ReadMultiStream类仅在第一次调用时返回-1(在流的末尾),所有后续调用都会抛出异常。可以通过在Web服务上发送字符流并将其包装到客户端的java.io.BufferedReader来模拟此问题。当流不以新行字符结束时,方法readLine的常规用法将失败。

修复版本:2.2.6


1
投票

感谢@Jonathan Drapeau,@ boxed |问题被确定了。 ReadMultiStream违反了java.io.InputStream接口。

解决方案相当简单,服务器端:

@POST
@Consumes({ MediaType.MULTIPART_FORM_DATA })
@Produces({ MediaType.APPLICATION_JSON })
public Response uploadStorageFile(@Context UriInfo ui, @Context HttpHeaders hh,     @FormDataParam("file") 
InputStream uploadedInputStream, @FormDataParam("file") FormDataContentDisposition fileDetail){
System.out.println(uploadedInputStream.getClass().getName());
String uploadedFileLocation = fileDetail.getFileName();
long size = fileDetail.getSize();
// save it
try {
            //test.jpg for test purposes
    OutputStream out = new FileOutputStream(new File("test.jpg")); 
    IOUtils.copy(uploadedInputStream, out);
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }

String output = "File uploaded to : ";

return Response.status(200).entity(output).build();

}

正如我在问题中提供的那样,多个教程正在教导输入流(服务器端),因此我不知道它是否是最近的错误。

© www.soinside.com 2019 - 2024. All rights reserved.