Re: Problem with cookie values in 8.5.14
On 4/26/2017 12:48 PM, Mark Thomas wrote: I suggest you read the changelog for 8.5.x. Hint. Start with the entries for 8.5.0. Got it. I thought that this was a minor update. I've been running Tomcat 8.5.x for a while now so I guess I was not affected by that change. Thanks, Igal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with cookie values in 8.5.14
On 26/04/17 20:35, Igal @ Lucee.org wrote: > On 4/26/2017 11:55 AM, Mark Thomas wrote: >> >> >> In short, yes there is a conflict. >> >> RFC 6265 does not permit ',' (and a bunch of other characters) to be >> used in the value and provides no escape or encoding syntax for >> including these characters. >> >> RFC 2109 allows quoted string to be used. In this Tomcat can (and will) >> do what needs to be done to make the cookie value 'just work'. > > Seems like a BIG change for a minor update (8.5.13 --> 8.5.14), no? I suggest you read the changelog for 8.5.x. Hint. Start with the entries for 8.5.0. >> You could switch to the LegacyCookieProcessor. Other than that, you'd >> need to find a different delimited for the values in you Cookie. > > Where would I go about setting the Cookie Processor? http://tomcat.apache.org/tomcat-8.5-doc/config/index.html Look in the index on the left hand side. Hint: You want "CookieProcessor" Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with cookie values in 8.5.14
On 4/26/2017 11:55 AM, Mark Thomas wrote: In short, yes there is a conflict. RFC 6265 does not permit ',' (and a bunch of other characters) to be used in the value and provides no escape or encoding syntax for including these characters. RFC 2109 allows quoted string to be used. In this Tomcat can (and will) do what needs to be done to make the cookie value 'just work'. Seems like a BIG change for a minor update (8.5.13 --> 8.5.14), no? You could switch to the LegacyCookieProcessor. Other than that, you'd need to find a different delimited for the values in you Cookie. Where would I go about setting the Cookie Processor? Thanks, Igal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with cookie values in 8.5.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 4/26/17 3:18 PM, Mark Thomas wrote: > On 26/04/17 20:13, Christopher Schultz wrote: >> On 4/26/17 2:55 PM, Mark Thomas wrote: > > > >>> RFC 2109 allows quoted string to be used. In this Tomcat can >>> (and will) do what needs to be done to make the cookie value >>> 'just work'. >> So does 6265 just basically do-away with all attempts to quote >> things and say "if you want weird stuff in there, use base64"? > > Exactly. > > To maximize compatibility with user agents, servers that > wish to store arbitrary data in a cookie-value SHOULD encode that > data, for example, using Base64 [RFC4648]. Done. With backward-compatibility. ;) Since everything I have is name=value[,name=value] I just decided to look for anything that includes an equals sign anywhere other at the end(s) of the input and consider that a non-base64-encoded cookie value. Fortunately, I've got the cookie-value-generation in one single place in the code and, similarly, the cookie-value-reading code is in another one single place, it was easy to add this symmetrically. I'll keep this in mind for future Cookie exploits... er, adventures. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZAPTjAAoJEBzwKT+lPKRYR8YQAIP2VZvX/cvDHGu+34Hvrqdo MiNReQwd4EZos+vecH2X3rpy+4nFWach3HTqFJyatDzHRuEiw4DnYiQfakPErBW7 x9gy1PErkGbpm6B0Z2WgaqXcQy9ChUTzIrzRyqkhAeDA0ZAA+6N2GHexsFFWkhVS 2UPXQfQt71Bs3+cZDQzCiMzWFSuob4P4cqWV6rpXiZIu19gu5ibkRfs5jR/vQEpn 5nttICtSuNJQMVAXkI9uPzsXOgOq1Q9/WiWc39Dp2tTasCj0xBlVfd29HgRraNbv YHREO0aVFocFfZRofQSTbr9xFzhnJ9u6oN5eIpQNXYIFw7arKqKujYak7hWj53Jr 3iybfRLeVY/uo8vHgAyOmtvBQxLeagTgtmgYIQyVF2l+vsmJl7C4y+j1BHuP5h81 jPf9rpj4JwXQVBxu6W6Bs4Xn++jZ+vA3eDFqUyz4E+FBxIwYDjd5tvX9/2+Z3QNn QMYQZRNH3iV50+YJdhQUxjWJvrnowmn/zMylDJWWBxuh6ih2Dw89F1y1Uyqj8Uc4 unVaYsN8ttkKLh25+OpTg3JNiBDixL1xJVCkvIdV/xvuy5AGQxLk+esDS5kAZKg0 tdTsLonq0VLhrMZQTXsHC8wXKHMSlhg3DQQl/a8vCWLC8NTMOyHseZut3vJfehi0 j7XSmYIgqsUooSPIeebR =mhKU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with cookie values in 8.5.14
On 26/04/17 20:13, Christopher Schultz wrote: > On 4/26/17 2:55 PM, Mark Thomas wrote: >> RFC 2109 allows quoted string to be used. In this Tomcat can (and >> will) do what needs to be done to make the cookie value 'just >> work'. > So does 6265 just basically do-away with all attempts to quote things > and say "if you want weird stuff in there, use base64"? Exactly. To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 [RFC4648]. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with cookie values in 8.5.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 4/26/17 2:55 PM, Mark Thomas wrote: > On 26/04/17 19:07, Christopher Schultz wrote: > > > >> The log message says that the value of the cookie is >> "mqpp=1,kiosk=true" (without the quotes). >> >> The offending character (decimal 44... I was surprised it wasn't >> a hex value) is a comma. I think either the Cookie class or >> Tomcat is mis-managing my cookie value. I was expecting >> Cookie/Tomcat to just "make it work" regardless of the value I >> tried to put into the cookie. >> >> This has worked without any problems prior to Tomcat 8.5.x. >> >> The javadoc for Cookie.setVersion says that when version=1, >> cookie values should confirm to 2109, but since Tomcat is now >> using RFC 6265 perhaps there is conflict between the two? > > In short, yes there is a conflict. :( That's what I feared. > RFC 6265 does not permit ',' (and a bunch of other characters) to > be used in the value and provides no escape or encoding syntax for > including these characters. Fabulous. > RFC 2109 allows quoted string to be used. In this Tomcat can (and > will) do what needs to be done to make the cookie value 'just > work'. So does 6265 just basically do-away with all attempts to quote things and say "if you want weird stuff in there, use base64"? >> Is there a way I can make both javax.servlet.http.Cookie and >> Tomcat 8.5.x+ happy? I can easily manually-quote this cookie >> value in whatever way is required. > > You could switch to the LegacyCookieProcessor. Other than that, > you'd need to find a different delimited for the values in you > Cookie. I'd prefer not to fall-back to the LegacyCookieProcessor because default s. I'll probably use base64, then none of this will ever be a problem again. Unless "=" isn't allowed in there. But my cookie has two of those, and Tomcat didn't complain, so it's probably okay. >> Or is this a bug in either j.s.h.Cookie or Tomcat's RFC 6265 >> validator (or a combination of the two)?> > The RFC 6265 spec (and hence CookieProcessor) is (arguably) not > fully compliant with the Servlet spec. Okay, good to know that this is at least an *expected* incompatibility and not that I'm specifically doing anything wrong. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZAPFbAAoJEBzwKT+lPKRY458P/j/yUdgwK6H/N8Nwi73uHeyS k+ydc8O85Og60tdqsAtAiSq1lM/r2mK4cV/4LCh+8AmKmci1pCqX67728QkpNoFv kmejpjJZd10NZ4oEm60lrhhtgpUlPUwKXso5cxZb/15ngyOhk4LH15S6tEnFSxg5 nPpWS4/LJYs4GC/4Q+2T65y7EbaaMQQhZ5Vt3YbdIOi9aW2Ov+IJPOzHey3Yc0fo U5tIEQgKI4Zo3uXyq45ahpfA5cITp502mx0pLNw+SqWJpzR5WJE4GeXoSIPRk8Q0 HAYulpRJvoPA1tKOfpFdrTN5cjLqfXn4/HUQDUzArYu+f0mgonm8iZnjvastH5aW y4C7SR6134l8YvwGk2DqP+XBa+raR0FSKjBC8YBZAqTci+iquLgPKtyP1Dc1rXPs SxP3VkZudmLtSzC+JA7JJ/ZjL9HUKuv3oBXHs7IulhefGC4mKsaRa3vWUu4Iwh5o O4enbXWcmz/gakqUUljIRIhlk2osi/iy25rIfKtP/GpFI1YZQOsStPwZCVlV78Cn tCg47lUFik5rUTWYEgN/EiUq/N+WeE3z7IBx0H7tLYZt202iRmCiMc4GA3e3bbuO qdsvlxaiJl5GutgKeb81CGUbfDsyXp1Pc/+5uAjbd49eg10TzTKgq+t0iHUakdpJ TVXPvargml2J1g3Kj0oW =0dW8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with cookie values in 8.5.14
On 26/04/17 19:07, Christopher Schultz wrote: > The log message says that the value of the cookie is > "mqpp=1,kiosk=true" (without the quotes). > > The offending character (decimal 44... I was surprised it wasn't a hex > value) is a comma. I think either the Cookie class or Tomcat is > mis-managing my cookie value. I was expecting Cookie/Tomcat to just > "make it work" regardless of the value I tried to put into the cookie. > > This has worked without any problems prior to Tomcat 8.5.x. > > The javadoc for Cookie.setVersion says that when version=1, cookie > values should confirm to 2109, but since Tomcat is now using RFC 6265 > perhaps there is conflict between the two? In short, yes there is a conflict. RFC 6265 does not permit ',' (and a bunch of other characters) to be used in the value and provides no escape or encoding syntax for including these characters. RFC 2109 allows quoted string to be used. In this Tomcat can (and will) do what needs to be done to make the cookie value 'just work'. > Is there a way I can make both javax.servlet.http.Cookie and Tomcat > 8.5.x+ happy? I can easily manually-quote this cookie value in > whatever way is required. You could switch to the LegacyCookieProcessor. Other than that, you'd need to find a different delimited for the values in you Cookie. > Or is this a bug in either j.s.h.Cookie or Tomcat's RFC 6265 validator > (or a combination of the two)? The RFC 6265 spec (and hence CookieProcessor) is (arguably) not fully compliant with the Servlet spec. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: InvocationTargetException on startup after upgrade to 8.5.13
On 26/04/17 16:34, Frank Taffelt wrote: >> I can't reproduce this. It may be configuration related. Please provide the >> steps minimal to reproduce this from a clean 8.5.14 install. > > http://www.glesir.de/~frank/tomcat-startup.zip > > Sample CATALINA_BASE structure with a prebuilt webapp. To run it you have to > adjust the contained runcatalina.bat to point CATALINA_HOME to a clean > 8.5.14. On startup you should see the errors mentioned. > > nevertheless you can invoke > https://localhost/test/metrics > > inside is mvn-tomcat-test.zip that contains the webapp as an mvn project. > > hope this helps to dig further into it, It does. Thanks. The previous fix addressed an issue with non-TLS connectors. There was still an issue with TLS connectors during initialisation. This is now fixed in 8.5.x for 8.5.15 onwards and 9.0.x for 9.0.0.M21 onwards. Kind regards, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problem with cookie values in 8.5.14
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
I have this code in a servlet and it's throwing an exception (below):
StringBuilder sb = ...;
logger.trace("cookie value: " + sb.toString());
Cookie cookie = new Cookie(cookieName, sb.toString());
cookie.setVersion(1);
cookie.setPath(cookiePath);
response.addCookie(cookie); // exception thrown here
Tomcat is throwing this exception:
Exception: java.lang.IllegalArgumentException: An invalid character
[44] was present in the Cookie value
Stack Trace:
java.lang.IllegalArgumentException: An invalid character [44] was
present in the Cookie value
org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateCookieValue(R
fc6265CookieProcessor.java:182)
at
org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc626
5CookieProcessor.java:115)
at
org.apache.catalina.connector.Response.generateCookieString(Response.jav
a:999)
at org.apache.catalina.connector.Response.addCookie(Response.java:947
)
at
org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.ja
va:386)
at
javax.servlet.http.HttpServletResponseWrapper.addCookie(HttpServletRespo
nseWrapper.java:58)
at [my code]
The log message says that the value of the cookie is
"mqpp=1,kiosk=true" (without the quotes).
The offending character (decimal 44... I was surprised it wasn't a hex
value) is a comma. I think either the Cookie class or Tomcat is
mis-managing my cookie value. I was expecting Cookie/Tomcat to just
"make it work" regardless of the value I tried to put into the cookie.
This has worked without any problems prior to Tomcat 8.5.x.
The javadoc for Cookie.setVersion says that when version=1, cookie
values should confirm to 2109, but since Tomcat is now using RFC 6265
perhaps there is conflict between the two?
Is there a way I can make both javax.servlet.http.Cookie and Tomcat
8.5.x+ happy? I can easily manually-quote this cookie value in
whatever way is required.
Or is this a bug in either j.s.h.Cookie or Tomcat's RFC 6265 validator
(or a combination of the two)?
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZAOHeAAoJEBzwKT+lPKRY9FAP/1YRlatkbLKIYhKlsWgAi3Ze
WlW25qjBW6uLkdE+7J1/3HvEtk80ZdQ6wDE187IIiMHF2CEbPfqjaculhVrsjSPE
VBdQXfDR3jt3QIEs/iKAor6shhGri4PEEPxUgYhe8QMHjwGRmQ2uP6pwzX8dyOyq
/WGlZgp3rsrlrShRoI2nVZO9DgMISjAwytLdJdeTRdXQ6UsKXBC48YEaUJOuxUbf
fBUV7TvB3UEbxSEsLKDx88JANujTYbQJpVEE8IhyDJ5Wji4X0LN3ylDahgNIKwwK
Zz6fY3I9bOVZwMAr1f0bbm9AnvL3zsu5bgp4YH3oyJAg7iW81sYMNe5ubsU9xifQ
KwpovSlObkj6Y5B7BqLO8eb2TOh+a4qIE0RnMCfV+5neAWnPD3uL2pyFGYtHWNwh
DgQskKxuFuId0onaR8COtD3qiAwpuzA+96c15EXZPGZW122vODOlIdel26Uv5ZXH
tZrPus24tNXkgaLMBYjHq53uWyXxNmdN27nK//L83cgPHCx4wMRCUN3hjkE2WUYf
SuVXZcZidFcu67Dk3iwYCz0TxFvMVtw9cyl98F1zAZzOV1GW347aDlQga1psV9Nf
BgIibfASeoIumNIzzBgHyeVi5WP3jeIP/29GQiGr0IEIhXMa72ot6+6OFadRGKGM
L+Wc8c2+9LajaiSUi3Uy
=5bWu
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Last chance: ApacheCon is just three weeks away
ApacheCon is just three weeks away, in Miami, Florida, May 15th - 18th. http://apachecon.com/ There's still time to register and attend. ApacheCon is the best place to find out about tomorrow's software, today. ApacheCon is the official convention of The Apache Software Foundation, and includes the co-located events: * Apache: Big Data * Apache: IoT * TomcatCon * FlexJS Summit * Cloudstack Collaboration Conference * BarCampApache * ApacheCon Lightning Talks And there's dozens of opportunities to meet your fellow Apache enthusiasts, both from your project, and from the other 200+ projects at the Apache Software Foundation. Register here: http://events.linuxfoundation.org/events/apachecon-north-america/attend/register- More information here: http://apachecon.com/ Follow us and learn more about ApacheCon: * Twitter: @ApacheCon * Discussion mailing list: https://lists.apache.org/list.html?apachecon-disc...@apache.org * Podcasts and speaker interviews: http://feathercast.apache.org/ * IRC: #apachecon on the https://freenode.net/ We look forward to seeing you in Miami! -- Rich Bowen - VP Conferences, The Apache Software Foundation http://apachecon.com/ @apachecon signature.asc Description: OpenPGP digital signature
RE: InvocationTargetException on startup after upgrade to 8.5.13
>I can't reproduce this. It may be configuration related. Please provide the >steps minimal to reproduce this from a clean 8.5.14 install. http://www.glesir.de/~frank/tomcat-startup.zip Sample CATALINA_BASE structure with a prebuilt webapp. To run it you have to adjust the contained runcatalina.bat to point CATALINA_HOME to a clean 8.5.14. On startup you should see the errors mentioned. nevertheless you can invoke https://localhost/test/metrics inside is mvn-tomcat-test.zip that contains the webapp as an mvn project. hope this helps to dig further into it, Frank - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
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 >> >> 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
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 > >
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
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
Re: Identifying 64k size violation for __jspService methods loaded by Tomcat
Hi, 2017-04-26 11:06 GMT+03:00 Mohammed Manna : > > -- 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: We have changes related to that issue.[1] So update your Tomcat instance to the latest Tomcat 8.0 (8.0.43) Regards, Violeta [1] http://tomcat.apache.org/tomcat-8.0-doc/changelog.html > > 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,
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,
