Hello, I have retried using the following javac and jasper settings for my project (using ANT build) - and it still doesn't reveal those 64K errors even when the compilers are the same.
<!-- Configure Jasper --> <target name="jspc" depends="build.web"> <taskdef classname="org.apache.jasper.JspC" name="jasper2"> <classpath id="jspc.classpath"> <pathelement location="${java.home}/../lib/tools.jar"/> <fileset dir="bin"> <include name="*.jar"/> </fileset> <fileset dir="lib"> <include name="*.jar"/> </fileset> </classpath> </taskdef> <jasper2 validateXml="false" uriroot="webapps/${webdir}" webXmlFragment="work/generated_web.xml" outputDir="work/jsp" smapsuppressed="0" compilersourcevm="1.8" compilertargetvm="1.8" mappedfile="1"/> </target> <!-- Compile JSP --> <target name="compile.jsp" depends="jspc" > <javac compiler="javac1.8" destdir="work/jsp" optimize="off" debug="on" failOnError="false" srcdir="work/jsp"> <classpath> <pathelement location="webapps/${webdir}/WEB-INF/classes"/> <fileset dir="webapps/${webdir}/WEB-INF/lib"> <include name="*.jar"/> </fileset> <fileset dir="lib"> <include name="*.jar"/> </fileset> <fileset dir="bin"> <include name="*.jar"/> </fileset> </classpath> <include name="**"/> <exclude name="tags/**"/> </javac> </target> I set my environment variables for catalina and java as part of my tomcat start script. And both ANT and Tomcat are using the same compiler as i understand from ant task documentation. Is there anything else I can do to reveal the 64k size errors on the method? KR, On 26 April 2017 at 11:24, Mark Thomas <ma...@apache.org> wrote: > 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 > >