Hello, I recently upgraded my Tomcat to 8.5.11 and certain JSPs have stopped working since the maximum method/file size error 65535. The stack trace is below: An error occurred at line: [362] in the generated java file: [C:\Fieldglass\InSite-2017.10\work\Catalina\localhost\ROOT\org\apache\jsp\WEB_002dINF\pages\buyer\job_005fposting_005fform_002d3_jsp.java] The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit Stacktrace: at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:212) at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:457) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:377) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:349) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:333) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:600) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:368) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:726) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:592) The project I have doesn't contain any error/bug that might cause this. Rather than reformatting/refactoring >200 files, I was wondering if you guys would take a look at this and provide some comments on why this is happening. I have already tried adding the following attributes to %CATALINA_HOME%\conf\web.xml suppressSmap=true mappedFile=False
Additional code was added for error handling, which undoubtedly increases the method sizes. It is thus possible that some JSP which was too close to the limit not has an issue.
I can confirm that the issue is prevalent when you have a multipart form built using 2-3 JSP forwards. And my java version is JDK 8 Update 121. Have you guys had the issue with this JDK?
Also found the same problem when downgraded to 8.0.39. Hence, downgrading to 8.0.29. I am not facing the issue anymore with 8.0.29. Could someone please let me know if a bugfix will be done on 8.5.11?
There is no bug here. The code generated for JSPs got longer as additional error handling had to be added to tags. JSps that use a lot of tags and/or were close to the limit are likely to need to be refactored to bring them under the limit.
Thanks - But isn't this going to cause quite a lot of Legacy systems to be broken? Or do you expect developers to use the older versions of Tomcat?
The users list is the best place to discuss ways to handle problems with overly large methods. I've taken a quick look at the generated source and I don;t see any obvious ways to reduce the size of the generated method.
While the long term advice is still try to restructure the JSP, I've spent time looking more closely at the generated code. I found several potential changes that might reduce the overall size of the _jspService() method but because of compiler optimisations, changes that look like they should reduce the method size, don't always have the expected effect. I've now implemented the changes that appear to have a positive effect in trunk (9.0.x). With the tag I was testing with (the foo tag from the JSP examples) the number of instances of the tag I could use on a single page were: - before the try/finally clean-up fixes - 301 - after the try/finally clean-up fixes - 221 - after clean-up but with optimisations - 292 The figures will vary from tag to tag. The more attributes a tag has, the greater the effect of the optimisations (the foo tag has three). I'd like to get some feedback on these changes from end-users (to the dev@ list please) before back-porting them so any feedback you can provide based on testing of the current trunk (9.0.x) would be appreciated.
*** Bug 60653 has been marked as a duplicate of this bug. ***
One of the optimisations was buggy. Removing it gives: - after clean-up but with optimisations - 258 Setting mappedFile to false permits another 10 tags to used.