Tomcat implemented their version based on commons-fileupload, and an early version of *their own* javadoc for the servlet spec.
See: https://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/Part.html#write(java.lang.String) > fileName - The location into which the uploaded part should be stored. Relative locations are relative to MultipartConfigElement.getLocation() vs https://docs.oracle.com/javaee/7/api/javax/servlet/http/Part.html#write-java.lang.String- > fileName - the name of the file to which the stream will be written. The file is created relative to the location as specified in the MultipartConfig Notice the difference in documentation? The Tomcat implementation isn't based on the actual final Servlet 3.0 spec. Joakim Erdfelt / [email protected] On Mon, Feb 26, 2018 at 12:23 PM, Robert Stroud <[email protected]> wrote: > Hello Joakim, > > Thank you for your quick response to my question - it sounds as though the > root of our problem is an ambiguity or difference in interpretation of the > servlet specification. > > I bet your configuration has MultipartConfig.location set to >> java.io.tmpdir (the default value), hence why your transferTo() is prefixed >> with "/tmp" >> > > That sounds like a good bet to me… :-) > > Best wishes, > > Robert > > > On 26 Feb 2018, at 17:49, Joakim Erdfelt <[email protected]> wrote: > > Some more background/detail on this ... > > Interestingly page 224 of the Servlet 4.0 metions this .. > > https://javaee.github.io/servlet-spec/downloads/ > servlet-4.0/servlet-4_0_FINAL.pdf > > 21. Clarify interpretation of fileName parameter for method Part.write(). >> See the javadoc for details. > > > Found the issue for Part.write at ... > > https://github.com/javaee/servlet-spec/issues/172 > > Finally a link to Part.write in the Servlet 4.0 Part.write update ... > > https://github.com/javaee/servlet-spec/blob/4.0.0/src/ > main/java/javax/servlet/http/Part.java#L93-L113 > > > > > > Joakim Erdfelt / [email protected] > > On Mon, Feb 26, 2018 at 11:31 AM, Joakim Erdfelt <[email protected]> > wrote: > >> You should never assume that Part.write() or .transferTo() accepts fully >> qualified locations on disk, its always relative to the >> MultipartConfig.location. >> >> See: >> >> - https://github.com/eclipse/jetty.project/issues/1337 >> - https://docs.oracle.com/javaee/7/api/javax/servlet/http/Part.html >> - https://docs.oracle.com/javaee/7/api/javax/servlet/http/ >> Part.html#write-java.lang.String- >> >> <https://docs.oracle.com/javaee/7/api/javax/servlet/http/Part.html#write-java.lang.String-> >> >> >> >> The Apache Commons File Upload package (last time I looked) will delegate >> to the servlet spec HttpServletRequest.getPart() behavior. >> Since Tomcat's Part.write(String) allows you to write to any arbitrary >> location on disk that's how Apache Commons File Upload expects it. >> >> The javadoc for Part.write() says it will write relative to the >> MultipartConfig.location. >> >> I bet your configuration has MultipartConfig.location set to >> java.io.tmpdir (the default value), hence why your transferTo() is prefixed >> with "/tmp" >> >> This was brought up in the Servlet spec 4.0 discussions (not sure how it >> was resolved) >> >> >> Joakim Erdfelt / [email protected] >> >> On Mon, Feb 26, 2018 at 11:17 AM, Robert Stroud <[email protected]> wrote: >> >>> Hello, >>> >>> We are using Jetty Runner 9.4.8 to launch a Java web application from a >>> WAR file and have encountered a problem with file uploads. The code in >>> question works fine if the WAR file is launched by Tomcat, but fails if the >>> WAR file is launched by Jetty Runner, which suggests that there may be a >>> problem with the way in which we have configured Jetty Runner. >>> >>> The application is written in Grails, which runs on Spring Boot, so we >>> are using the Spring MultipartFile interface to upload the file. At the >>> point at which the web application attempts to store a copy of the uploaded >>> file in a local folder on the web server, we get a “File not found >>> exception”. This appears to be caused by the value of “java.io.tmpdir” >>> being prepended to the target filename, which means that the path is >>> invalid. Can anyone suggest why this might be happening? >>> >>> In more detail, the relevant line of code is >>> >>> uploader.transferTo(“/some/destination”) // make a local >>> copy of the file upload >>> >>> and the exception is >>> >>> java.io.FileNotFoundException: /tmp/some/destination/file (No >>> such file of directory) >>> >>> Note that “/tmp” (or more precisely, the value of System.getProperty(“ >>> java.io.tmpdir”)) has been prepended to the destination pathname, which >>> makes it invalid. >>> >>> The problem seems to be with the implementation of the Spring >>> MultipartFile interface on Jetty Launcher - I believe Spring Boot is using >>> an implementation based on the Apache Commons File Upload package. Does >>> anyone know of a reason why this might not work on Jetty? >>> >>> Thanks for any help or suggestions. >>> >>> Best wishes, >>> >>> Robert >>> >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
