Jetty 8.1 is Servlet 3.0, not Servlet 2.5. If you used a spring boot that was for Servlet 2.5 on Jetty 8.1 then you'd have Servlet 2.5 support and expectations (eg: it wouldn't know about Part.write(String))
The Jetty 8.1 / Servlet 3.0 behavior of Part.write(String) is the same as it is in Jetty 9.x and Servlet 3.1 Joakim Erdfelt / [email protected] On Tue, Feb 27, 2018 at 12:08 PM, Robert Stroud <[email protected]> wrote: > Hello Joakim, > > One further question about the file upload issue - we previously used > Jetty Runner version 8.x to launch our application and the file upload > feature worked correctly. > > Can you clarify whether the earlier version of Jetty Runner behaved > differently with respect to file uploads - for example, it presumably > implemented the Servlet 2.5 specification rather than than Servlet 3.0 > specification, but I don’t know if this would make any difference? > > Also, to clarify something in my earlier email, I said that the problem > had been fixed in Spring 5.0 but not back ported to Spring 4.3.9. In fact, > the patch was applied to Spring 4.3.8, but I believe it doesn’t fix the > problem. > > Thanks again for your help with this issue. > > Best wishes, > > Robert > > On 27 Feb 2018, at 10:39, Robert Stroud <[email protected]> wrote: > > Hello Joakim, > > Thank you for the additional explanation - the difference between the > Tomcat behaviour and the official behaviour is the underlying cause of our > problem. > > Apparently, the Spring MultipartFile abstraction has always allowed files > to be uploaded to an absolute path location, but assumed that the > underlying Servlet Container behaved like Tomcat: > > https://jira.spring.io/browse/SPR-15257#comment-135998 > > This has apparently been fixed in Spring 5.0 but doesn’t seem to have been > back ported to Spring 4.3.9, which is the version we are using. > > Best wishes, > > Robert > > > > > > [email protected]> wrote: > > 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- >>> >>> >>> 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 > > > > > _______________________________________________ > 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
