On 26/04/17 10:33, Mohammed Manna wrote: > Hello, > > Thanks for suggesting the solutions. This is closer to what I was expecting > in the original message which I sent in the past. Once again, I apologise > if I have made any Negative/Reactive comments about Apache no being > supportive enough. I have been using various Apache libraries over the past > 7 years without any issues. But this particular Tomcat upgrade has caused > me significant grief in managing large projects where 9/10 systems are > legacy code base. I do agree that the JSPs need to be refactored to remove > any obsolescence. But until your response, I have only received responses > where I was asked to upgrade to a different version, but I am more curious > to find out the root cause for this. > > Unfortunately, I have to leave with *enablePooling=TRUE, *since it might > affect things. I will however try to reconfigure Jasper and use my native > Java 1.8.121 to do all the compilation and see how things go. > > Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but > minimise the occurrences of it. Is this correct?
Correct. The error handling code was refactored for 8.0.42 onwards to be a little more efficient. It isn't much but if your code is on the border line it might be enough to bring it back under the 64k. Mark > > > Additionally, thanks to you for putting a lot more attention to it. > > KR, > > > > > On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote: > >> On 26/04/17 09:06, Mohammed Manna wrote: >>> Hello, >>> >>> I have emailed and posted a few questions over the web about this, but >>> haven't received any helpful response. Since the upgrade to 8.0.39, my >> web >>> application is failing in various places since the Jasper compiler has >> now >>> got more debug information (and inturn __jspService method is now bigger >>> than 64k). >> >> First a correction. The changes were not made to introduce additional >> debug information. The changes introduced additional - specification >> required - error handling for tags. The changes were the result of >> investigating a reported memory leak [1]. >> >>> I have done the following so far: >>> >>> 1) Kept mappedFile = TRUE >>> 2) Kept suppressSMAP = FALSE >>> >>> This removes the failure, but now I have lost the JSP debugging >> capability. >>> Since Apache is not going to provide any support for this, could you >> kindly >>> assist me with the following: >> >> First you say Apache isn't going to provide you with any support >> (despite this being your first post on this topic) then you ask this >> Apache community for that same support. That isn't the best way to >> motivate a group of volunteers to help you. >> >> The initial fix was in 8.0.37. >> A regression was fixed in 8.0.40. >> A more efficient solution was provided in 8.0.42. >> An improved solution for simple tags was in 8.0.43 >> >> The first recommendation is to upgrade to 8.0.43. The more efficient >> code introduced in 8.0.42 may help. >> >> Other configuration settings that can help reduce the size of your JSP >> methods include: >> >> trimSpaces - true >> enablePooling - false >> >> Note the disabling pooling may impact performance. It depends on lot on >> the complexity of the tags. >> >>> 1) How can I identify my JSP pages which are going to have this issue? >>> 2) I have tried using ANT build and compiled my JSPs. It simply passes >> the >>> build, but doesn't report any method size violation. Do you have any >>> development mode support that can expose these affected methods. >> >> Do those pre-compiled JSPs then execute without error? >> >> Pre-compilation typically uses javac whereas on the fly compilation >> typically uses JDT (the Eclipse Compiler). It is possible that >> differences in the compilers means that a class compiles with one but >> fails with the other - particularly if your code is close to the boundary. >> >> It is possible to configure Jasper to compile JSPs with Ant and javac >> (see the compiler init parameter). >> >> I suggest you try the recommendations above and see how you get on. >> >>> I appreciate that these are too specific questions, but Tomcat 8.0.39 >>> upgrade clearly didn't consider legacy systems and has left a massive >>> refactoring job to the developers. So, it would be great if you could >>> proactively extend "Known Issues" section with these. >> >> Patches welcome. >> >> Mark >> >> >> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
