Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
JSP not rendered on Jetty #113
I'm contributing to the Spring Petclinic sample: https://github.com/spring-projects/spring-petclinic
This problem appears to be similar to issue #55.
Hi, just a note to say that the Jetty team are also looking a dandelion and are happy to help resolve these issues, either by updating jetty and/or improving the Dandelion Filter.
Our inspection of the Dandelion filter indicate that it is wrapping the response and overriding the
I think the wrapper needs to be extended to override more methods that can cause a commit. You could look at implementations of GzipFilters that are available, as these have dealt with similar problems. At the very least you should probably override:
Also note that in general, such response wrappers are getting harder and harder to implement correctly - specially with asynchronous IO. IT may be better to modularize the output transformations that you want to do and them provide that in various adaptors:
I think @janbartel and I have worked out a bit more of this issue.
The wrapper only wraps getWriter, and the request is forwarded by spring to the JSP which calls it and fills up the ByteArrayOutputStream with content. But importantly neither getOutputStream nor getWriter have been called on the jetty response.
The dispatch forward to the JSP returns and Jetty has to commit the response (by the servlet spec), but it has seen neither a getWriter nor a getOutputStream, so it just picks one (in this case the getOutputStream) and closes it. So the close flushes the response and all the content that was written to the writer is lost.
We have a fix for jetty that helps it make a better choice of what to close and that will be in a release soon (just missed 9.3.11). But I can also see a way for you to improve your filter so that it does not suffer this problem.
You need to override getOutputStream so that when it is called it get's the jetty outputstream and first writes all the buffered content to it before return the stream. This should then work with the current jetty releases. Do you want us to make a pull request?
referenced this issue
Jul 22, 2016
An alternate solution, that is probably more in line with the contract of Response, is that the wrapped getOutputStream should throw an ISE if getWriter has been called. Jetty already has code to try one and then the other if ISE is correctly thrown. The problem is that Jetty is trying to close the OutputStream first and this succeeds even though it should not, so we don't then close the writer.
We have looked again at the "fix" in jetty code and also looked at tomcat. It was just that tomcat tries to close the writer first and if the ISE, they close the output stream. Jetty does it the otherway around. So our fix is not really a fix it is just an arbitrary change to make up for a problem in your filter.
You need to override both getOutputStream and getWriter and correctly throw an ISE. See our PR #116 for a proposed implementation of this, which also respects any character encoding set.
If this looks OK, and ETA of when it could make it into a release would be good.