Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 351B6200D52 for ; Fri, 17 Nov 2017 11:19:05 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 3359A160BFB; Fri, 17 Nov 2017 10:19:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5A0A0160BF8 for ; Fri, 17 Nov 2017 11:19:04 +0100 (CET) Received: (qmail 39414 invoked by uid 500); 17 Nov 2017 10:19:03 -0000 Mailing-List: contact issues-help@struts.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@struts.apache.org Delivered-To: mailing list issues@struts.apache.org Received: (qmail 39387 invoked by uid 99); 17 Nov 2017 10:19:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Nov 2017 10:19:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A54E418088F for ; Fri, 17 Nov 2017 10:19:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id T2sIk4BAcIa6 for ; Fri, 17 Nov 2017 10:19:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id DC58D5F299 for ; Fri, 17 Nov 2017 10:19:00 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 6933EE0C18 for ; Fri, 17 Nov 2017 10:19:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3014B240D6 for ; Fri, 17 Nov 2017 10:19:00 +0000 (UTC) Date: Fri, 17 Nov 2017 10:19:00 +0000 (UTC) From: "M. Manna (JIRA)" To: issues@struts.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (STR-3224) DiskFile getInputStream() implementation returns ByteInputStream or FileInputStream MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 17 Nov 2017 10:19:05 -0000 [ https://issues.apache.org/jira/browse/STR-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] M. Manna updated STR-3224: -------------------------- Description: i have posted the question original on SO. Here is the link: [https://stackoverflow.com/questions/47347194/struts-diskfile-getinputstream-returns-bytearrayinputstream-and-filearrayinput?noredirect=1#comment81646937_47347194] The summary is that this "Switchover" behaviour should be documented somewhere if it returns ByteArrayInputStream or FileInputStream based on file size. The files for my case was class files (byte code files). and my code is given below {code:java} /** ** Get Uploaded file from Struts Multipart form upload ** org.apache.struts.upload.FormFile **/ FormFile file = form.getTheFile(); /** ** Since we never had any issue, we didn't explicitly check using ** instanceof, but even then it's confusing. We do know that ** ByteArrayInputStream has mark supported. And it works upto ** 256KB file size on Windows OS. **/ InputStream markStream = file.getInputStream(); // Doc says it sends "FileInputStream" try { // Do something with the markStream object markStream.reset(); // for ByteArrayInputStream mark is supported // Do something else with markStream } Catch (IOException ioe) { ioe.printStackTrace(); } finally { markStream.close(); // no effect for certain types } {code} Our issue is that this behaviour, even if expected, should be well documented. If we have missed this somewhere in Oracle JDK docs or in ASF docs, please could you point us there? was: i have posted the question original on SO. Here is the link: [https://stackoverflow.com/questions/47347194/struts-diskfile-getinputstream-returns-bytearrayinputstream-and-filearrayinput?noredirect=1#comment81646937_47347194] The summary is that this "Switchover" behaviour should be documented somewhere if it returns ByteArrayInputStream or FileInputStream based on file size. The files for my case was class files (byte code files). and my code is given below /** ** Get Uploaded file from Struts Multipart form upload ** org.apache.struts.upload.FormFile **/ FormFile file = form.getTheFile(); /** ** Since we never had any issue, we didn't explicitly check using ** instanceof, but even then it's confusing. We do know that ** ByteArrayInputStream has mark supported. And it works upto ** 256KB file size on Windows OS. **/ InputStream markStream = file.getInputStream(); // Doc says it sends "FileInputStream" try { // Do something with the markStream object markStream.reset(); // for ByteArrayInputStream mark is supported // Do something else with markStream } Catch (IOException ioe) { ioe.printStackTrace(); } finally { markStream.close(); // no effect for certain types } Our issue is that this behaviour, even if expected, should be well documented. If we have missed this somewhere in Oracle JDK docs or in ASF docs, please could you point us there? > DiskFile getInputStream() implementation returns ByteInputStream or FileInputStream > ----------------------------------------------------------------------------------- > > Key: STR-3224 > URL: https://issues.apache.org/jira/browse/STR-3224 > Project: Struts 1 > Issue Type: Bug > Affects Versions: 1.2.9 > Environment: Windows OS > Reporter: M. Manna > Priority: Critical > > i have posted the question original on SO. Here is the link: > [https://stackoverflow.com/questions/47347194/struts-diskfile-getinputstream-returns-bytearrayinputstream-and-filearrayinput?noredirect=1#comment81646937_47347194] > The summary is that this "Switchover" behaviour should be documented somewhere if it returns ByteArrayInputStream or FileInputStream based on file size. > The files for my case was class files (byte code files). and my code is given below > {code:java} > /** > ** Get Uploaded file from Struts Multipart form upload > ** org.apache.struts.upload.FormFile > **/ > FormFile file = form.getTheFile(); > /** > ** Since we never had any issue, we didn't explicitly check using > ** instanceof, but even then it's confusing. We do know that > ** ByteArrayInputStream has mark supported. And it works upto > ** 256KB file size on Windows OS. > **/ > InputStream markStream = file.getInputStream(); // Doc says it sends "FileInputStream" > try { > > // Do something with the markStream object > markStream.reset(); // for ByteArrayInputStream mark is supported > > // Do something else with markStream > } Catch (IOException ioe) { > > ioe.printStackTrace(); > > } finally { > > markStream.close(); // no effect for certain types > > } > {code} > Our issue is that this behaviour, even if expected, should be well documented. If we have missed this somewhere in Oracle JDK docs or in ASF docs, please could you point us there? > -- This message was sent by Atlassian JIRA (v6.4.14#64029)