Upgrade to APR 1.5 with Tomcat 8.0.39 distro
Hi, I understand that there were some notable security upgrades made for 1.5 APR. For tomcat 8.0.39 i belive the distro is still using 1.2.12. Does anyone know if upgrading to 1.5.2 will cause any complications? KR,
Re: JSP compilation 65535 bytes limit
You cannot blindly execute the snippet by copying it from Tomcat website.
You have to adapt it to your project first. Try and remove the line and try to build it. You probably need to set up your project
for Ant build first if not done already.
On 17 May 2017 at 15:03, Vidyadhar wrote:
> On Wed, May 17, 2017 at 7:30 PM, Mohammed Manna
> wrote:
>
> > Your ant Build File seems to be incorrect. Could you provide the snippet
> of
> > the Jspc Task and Javac task for this?
> >
> Following is the tomcat.xml which I am using for precompilation:
>
>
>
>
>
>
> validateXml="false"
> uriroot="${webapp.path}"
> webXmlFragment="${webapp.path}/WEB-INF/generated_web.xml"
> outputDir="${webapp.path}/WEB-INF/src" />
>
>
>
>
>
>
>
>
> optimize="off"
>debug="on" failonerror="false"
>srcdir="${webapp.path}/WEB-INF/src"
>excludes="**/*.smap">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> > On 17 May 2017 at 14:58, Vidyadhar wrote:
> >
> > > Hello KR,
> > >
> > > On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna
> > > wrote:
> > >
> > > > Hi Vidyadhar,
> > > >
> > > > Some points to note here:
> > > >
> > > > 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf)
> > doesn't
> > > > guarantee that it won't happen. Tomcat 8.0.43 onwards have got this
> > > relaxed
> > > > out by using a more efficient error handling code. But you will have
> > this
> > > > error if the code is truly hitting near the limit.
> > > > 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the
> issue
> > > > happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't
> > happen.
> > > > 3) Did you try and follow my suggestion on point 3 (last email) about
> > > > checking the method sizes of the precompiled JSPs using apache
> commons
> > > BCEL
> > > > (bcel-5.4.1.jar) library? If yes, what did you find?
> > > >
> > >
> > > I already tried to precompile the JSPs using ANT but it is giving
> > following
> > > error:
> > > C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.JasperException:
> > > java.lang.IllegalArgumentException: Page directive: invalid value for
> > > import
> > > at org.apache.jasper.JspC.processFile(JspC.java:1296)
> > > at org.apache.jasper.JspC.execute(JspC.java:1415)
> > > at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > I guess I am hitting the bug # 57099 and there are multiple JSPs
> wherein
> > we
> > > need to do these changes.
> > >
> > > >
> > > >
> > > > You also haven't mentioned what sort of JSPs you have that yields
> into
> > > such
> > > > error. Are you having legacy scriptlets which are quite heavy and
> uses
> > > lots
> > > > of custom tags? Try to use the following too:
> > > >
> > > >
> > > > trimSpaces
> > > > true
> > > >
> > > >
> > > > The above is having some inconsistency reported in a different email
> > > > thread, but I assume it should be fine in most of the cases. Try to
> see
> > > if
> > > > you can provide some results on the above points.
> > > >
> > > >
> > > > KR,
> > > >
> > > > On 16 May 2017 at 15:29, Vidyadhar wrote:
> > > >
> > > > > Hello KR,
> > > > >
> > > > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna <
> manme...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > I have two things which you might want to try out:
> > > > > >
> > > > > > 1) You will lose your JSP debugging capability - but if that's
> not
> > > your
> > > >
Re: JSP compilation 65535 bytes limit
Your ant Build File seems to be incorrect. Could you provide the snippet of the Jspc Task and Javac task for this? On 17 May 2017 at 14:58, Vidyadhar wrote: > Hello KR, > > On Tue, May 16, 2017 at 8:43 PM, Mohammed Manna > wrote: > > > Hi Vidyadhar, > > > > Some points to note here: > > > > 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf) doesn't > > guarantee that it won't happen. Tomcat 8.0.43 onwards have got this > relaxed > > out by using a more efficient error handling code. But you will have this > > error if the code is truly hitting near the limit. > > 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the issue > > happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't happen. > > 3) Did you try and follow my suggestion on point 3 (last email) about > > checking the method sizes of the precompiled JSPs using apache commons > BCEL > > (bcel-5.4.1.jar) library? If yes, what did you find? > > > > I already tried to precompile the JSPs using ANT but it is giving following > error: > C:\apache-ant-1.9.4\tomcat.xml:11: org.apache.jasper.JasperException: > java.lang.IllegalArgumentException: Page directive: invalid value for > import > at org.apache.jasper.JspC.processFile(JspC.java:1296) > at org.apache.jasper.JspC.execute(JspC.java:1415) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > I guess I am hitting the bug # 57099 and there are multiple JSPs wherein we > need to do these changes. > > > > > > > You also haven't mentioned what sort of JSPs you have that yields into > such > > error. Are you having legacy scriptlets which are quite heavy and uses > lots > > of custom tags? Try to use the following too: > > > > > > trimSpaces > > true > > > > > > The above is having some inconsistency reported in a different email > > thread, but I assume it should be fine in most of the cases. Try to see > if > > you can provide some results on the above points. > > > > > > KR, > > > > On 16 May 2017 at 15:29, Vidyadhar wrote: > > > > > Hello KR, > > > > > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna > > > wrote: > > > > > > > I have two things which you might want to try out: > > > > > > > > 1) You will lose your JSP debugging capability - but if that's not > your > > > > concern, then in your CATALINA_HOME\conf folder append this for > > > > "JspServlet" > > > > > > > > > > > > mappedfile > > > > false > > > > > > > > > > > > suppressSmap > > > > true > > > > > > > > > > > We already tried this option. We included these lines in tomcat's > web.xml > > > file and restarted the services, but still it is giving the same error. > > > > > > > > > > > This will stop generating JSR45 debug info and Symbol Maps for > JSP > > > > pages ( I think I have said technical things right here, otherwise > > please > > > > correct me!). > > > > > > > > 2) I sincerely recommend moving scriptlet code out of your JSP and > > remove > > > > all unwanted/commented code, newline/carriages from your JSP. Even > with > > > the > > > > config above, this might fail since the code is genuinely too large > for > > > > __jspService(). > > > > > > > > 3) If possible, try to use Ant and precompile your JSP and iterate > > > through > > > > the .class files to check which method size is larger or close to 90% > > or > > > > the 64k footprint. You can write a short program by leveraging > java.io > > > and > > > > Apache commons BCEL library. Ant has a strange behaviour which > doesn't > > > > throw any exceptions if the Jsp method size exceeds the limit. But > the > > > > compilation occurs anyway. So you can go through those compiled files > > > using > > > > your custom tool and print the size of the methods. > > > > > > > > > > > > I hope this helps you. > > > > > > > > Further to above we tried various tomcat version and as per our > > > observation we are not seeing th
Re: JSP compilation 65535 bytes limit
Hi Vidyadhar, Some points to note here: 1) Setting those parameters in Web.xml file (CATALINA_HOME/conf) doesn't guarantee that it won't happen. Tomcat 8.0.43 onwards have got this relaxed out by using a more efficient error handling code. But you will have this error if the code is truly hitting near the limit. 2) The issue occurs with Tomcat 8.0.39 onwards. Try to see if the issue happens for tomcat 8.0.29. I can vouch for 8.0.29 where it didn't happen. 3) Did you try and follow my suggestion on point 3 (last email) about checking the method sizes of the precompiled JSPs using apache commons BCEL (bcel-5.4.1.jar) library? If yes, what did you find? You also haven't mentioned what sort of JSPs you have that yields into such error. Are you having legacy scriptlets which are quite heavy and uses lots of custom tags? Try to use the following too: trimSpaces true The above is having some inconsistency reported in a different email thread, but I assume it should be fine in most of the cases. Try to see if you can provide some results on the above points. KR, On 16 May 2017 at 15:29, Vidyadhar wrote: > Hello KR, > > On Fri, May 12, 2017 at 12:37 PM, Mohammed Manna > wrote: > > > I have two things which you might want to try out: > > > > 1) You will lose your JSP debugging capability - but if that's not your > > concern, then in your CATALINA_HOME\conf folder append this for > > "JspServlet" > > > > > > mappedfile > > false > > > > > > suppressSmap > > true > > > > > We already tried this option. We included these lines in tomcat's web.xml > file and restarted the services, but still it is giving the same error. > > > > > This will stop generating JSR45 debug info and Symbol Maps for JSP > > pages ( I think I have said technical things right here, otherwise please > > correct me!). > > > > 2) I sincerely recommend moving scriptlet code out of your JSP and remove > > all unwanted/commented code, newline/carriages from your JSP. Even with > the > > config above, this might fail since the code is genuinely too large for > > __jspService(). > > > > 3) If possible, try to use Ant and precompile your JSP and iterate > through > > the .class files to check which method size is larger or close to 90% or > > the 64k footprint. You can write a short program by leveraging java.io > and > > Apache commons BCEL library. Ant has a strange behaviour which doesn't > > throw any exceptions if the Jsp method size exceeds the limit. But the > > compilation occurs anyway. So you can go through those compiled files > using > > your custom tool and print the size of the methods. > > > > > > I hope this helps you. > > > > Further to above we tried various tomcat version and as per our > observation we are not seeing this error on 8.0.29 version. Note that the > same error is still there in latest version i.e. 8.5.15. > > > KR, > > > > On 12 May 2017 at 07:58, Vidyadhar wrote: > > > > > Hello Sagar, > > > > > > On Fri, 12 May 2017 at 12:26 PM, sagar kohli > > > wrote: > > > > > > > Try adding following init parameter in /conf/web.xml > > > > > > > > > > > > mappedfile > > > > false > > > > > > > > > > > > > We already tried it but no success. > > > > > > > > > > > > > > > On Fri, May 12, 2017 at 10:28 AM, Vidyadhar < > techienote@gmail.com> > > > > wrote: > > > > > > > > > Hello Team, > > > > > > > > > > Recently we did a upgrade existing tomcat from 7.0.42 to 7.0.76 on > > > > windows > > > > > box. Post the up gradation we are seeing following error in couple > of > > > > JSPs > > > > > > > > > > org.apache.jasper.JasperException: Unable to compile class for > JSP: > > > > > > > > > > An error occurred at line: [231] in the generated java file: > > > [C:\Program > > > > > Files\Apache\Tomcat\work\Catalina\localhost\app\org\ > apache\jsp\jsp\ > > > > > applicationChange\applicationChangeMain_jsp.java] > > > > > The code of method _jspService(HttpServletRequest, > > > HttpServletResponse) > > > > is > > > > > exceeding the 65535 bytes limit > > > > > > > > > > Stacktrace: > > > > > org
Re: JSP compilation 65535 bytes limit
I have two things which you might want to try out: 1) You will lose your JSP debugging capability - but if that's not your concern, then in your CATALINA_HOME\conf folder append this for "JspServlet" mappedfile false suppressSmap true This will stop generating JSR45 debug info and Symbol Maps for JSP pages ( I think I have said technical things right here, otherwise please correct me!). 2) I sincerely recommend moving scriptlet code out of your JSP and remove all unwanted/commented code, newline/carriages from your JSP. Even with the config above, this might fail since the code is genuinely too large for __jspService(). 3) If possible, try to use Ant and precompile your JSP and iterate through the .class files to check which method size is larger or close to 90% or the 64k footprint. You can write a short program by leveraging java.io and Apache commons BCEL library. Ant has a strange behaviour which doesn't throw any exceptions if the Jsp method size exceeds the limit. But the compilation occurs anyway. So you can go through those compiled files using your custom tool and print the size of the methods. I hope this helps you. KR, On 12 May 2017 at 07:58, Vidyadhar wrote: > Hello Sagar, > > On Fri, 12 May 2017 at 12:26 PM, sagar kohli > wrote: > > > Try adding following init parameter in /conf/web.xml > > > > > > mappedfile > > false > > > > > We already tried it but no success. > > > > > > > On Fri, May 12, 2017 at 10:28 AM, Vidyadhar > > wrote: > > > > > Hello Team, > > > > > > Recently we did a upgrade existing tomcat from 7.0.42 to 7.0.76 on > > windows > > > box. Post the up gradation we are seeing following error in couple of > > JSPs > > > > > > org.apache.jasper.JasperException: Unable to compile class for JSP: > > > > > > An error occurred at line: [231] in the generated java file: > [C:\Program > > > Files\Apache\Tomcat\work\Catalina\localhost\app\org\apache\jsp\jsp\ > > > applicationChange\applicationChangeMain_jsp.java] > > > The code of method _jspService(HttpServletRequest, > HttpServletResponse) > > is > > > exceeding the 65535 bytes limit > > > > > > Stacktrace: > > > org.apache.jasper.compiler.DefaultErrorHandler.javacError( > > > DefaultErrorHandler.java:103) > > > org.apache.jasper.compiler.ErrorDispatcher.javacError( > > > ErrorDispatcher.java:366) > > > > > org.apache.jasper.compiler.JDTCompiler.generateClass( > JDTCompiler.java:490) > > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:379) > > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) > > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:341) > > > I have checked the various threads on tomcat support archive and did > try > > > following solution which did not work on 7.0.76 as well as on 7.0.77. > > > > > > 1. Following changes in conf/web.xml > > > > > > mappedfile > > > false > > > > > > > > > compiler > > > modern > > > > > > 2. Increased the buffer size. > > > > > > Can some one suggest some ways to resolve this error, without > downgrading > > > to 7.0.42 > > > > > > > > > > > > > > > -- > > > Regards, > > > Vidyadhar > > > > > > > > > > > -- > > Regards, > > sagar kohli > > > -- > Regards, > Vidyadhar >
Re: [ANN] New committer: Michael Osipov
Good to hear this! We look forward to your excellent work here On 8 May 2017 at 11:58, Martin Grigorov wrote: > Welcome, Michael! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, May 8, 2017 at 10:08 AM, Mark Thomas wrote: > > > On behalf of the Tomcat committers I am pleased to announce that > > Michael Osipov (michaelo) has been voted in as a new Tomcat committer. > > > > Please join me in welcoming him. > > > > Regards, > > > > Mark > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
Hi,
May be i didn't explain the issue clearly. I am using the same compiler as
Tomcat (JDT compiler, not ANT). When doing a standalone *ant build*, my
pre-compilation doesn't show any 64k size error for __jspService(). But
when I launch the application, it *does* throws error on 64k size on
various pages.
Just for the sake of comparison, I did the following:
1) Threw a purposefully generated error on ant build - captured to stack to
see which compiler implementation it followings - JDT compiler
2) Corrected the error above and passed the build
3) Deployed and launched the application.
4) Went to the problem page - generated the 64k error to capture the stack
information.
5) The compiler implementation is the same as reported on Ant Build error
(JDTCompiler).
This is why I have been struggling to understand why the behaviour is so
different when the compiler isn't ?
Is there any tuning of <*javac> *task definition in ant build I can use?
What do you recommend?
KR,
from the JspCompilationContext, what I can see is that it will use JDT
compiler when nothing is specified and the compilation will be based on 1.7
standard. Which means my *ant build* will also use JDT compiler
(org.apache.jasper.compiler.JDTCompiler). This is why I have been
struggling to understand why this is so different if
On 30 Apr 2017 12:05, "Mark Thomas" wrote:
On 29/04/17 11:10, Mohammed Manna wrote:
> 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.
Isn't that good? Doesn't that mean you've found a solution to the
problem? Compile with Ant and javac rather than JDT.
Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> validateXml="false"
> uriroot="webapps/${webdir}"
> webXmlFragment="work/generated_web.xml"
> outputDir="work/jsp"
> smapsuppressed="0"
> compilersourcevm="1.8"
> compilertargetvm="1.8"
> mappedfile="1"/>
>
>
>
>
> destdir="work/jsp"
> optimize="off"
> debug="on"
> failOnError="false"
> srcdir="work/jsp">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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 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 cod
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
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. 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 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 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 > >>
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
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? Additionally, thanks to you for putting a lot more attention to it. KR, On 26 April 2017 at 09:58, Mark Thomas 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 > >
Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
-- Forwarded message -- From: Mohammed Manna Date: 25 April 2017 at 21:50 Subject: Identifying 64k size violation for __jspService methods loaded by Tomcat To: users@tomcat.apache.org 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). 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: 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. 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. KR,
