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
