Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 15:31, Christopher Schultz wrote: My question would be "why do so many have AJP connectors where no 'address' attribute was specifically configured?" The answer to the question "why change the default?" is: "because the default was essentially insecure, in a way that wasn't obvious to someone who wasn't paying close attention." So we are forcing users to pay closer attention. If you want to open your AJP instance to the "whole world", then you can explicitly bind to 0.0.0.0/:: just as the previous default. Similarly, if you don't want to use the "secret" setting, then you can explicitly disable it. But the defaults will no longer let you be "insecure" without knowing it . Obviously, there are ways to have a "secure" installation while using 0.0.0.0/:: and/or secretRequired="false". But having those things in the configuration right in front of you make it clear that some decision has been made, rather than hiding (potential) danger behind insecure defaults. Why make this change in a point-release and not a major one? Because we felt it was important enough to do so. Will this disrupt some environments? Yes, it will. But the path to fixing it is to make one (or two) small edits to your configuration files which are surely under revision-control and automatically pushed-out to these hundreds-of-nodes clusters everyone is worried about, right? Well, then, change your configs and push them out there along with your upgrade of Tomcat and all will be well. - -chris Thank you Christopher for those complements. And thank you all for your disponibility. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 12:41, Mark Thomas wrote: On 13/02/2020 09:57, Olivier Jaquemet wrote: I understand the need to introduce a "secured by default" AJP configuration. However, I question one choice that was made for this change : the default behavior of the AJP connector to listen only on the loopback address. [...] You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour of listening on any address. Mark Thank you Mark. This should address this use case. Would you consider adding this binding information to the documentation (in the documentation of the address attribute) ? To sum up : When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as I saw you had also backported this change to the 7.0.x branch), if your server architecture is to expose tomcat with an AJP connector, to a remote distant front server, you can : either, *secure your installation* (obviously the recommended way on untrusted network) : - by specifying the valid IP address on which the connector must bind; This is done with address attribute of the AJP connector. - by specifying a shared secret between the front server and the connector ; This is done with the secret attribute of the AJP connector or else, if you want your server.xml to be agnostic to the running host and remote front server, change your configuration back to the previous behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* : - by removing explicit bind of AJP connector, by specifying "0.0.0.0" (IPv4) or "::" (IPv6) in the address attribute of the AJP connector - by removing need for shared secret between front and tomcat ; This is done with the secretRequired="false" attribute of the AJP connector. Olivier - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 10:32, Rémy Maucherat wrote: On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet wrote: On 13/02/2020 01:02, Stefan Mayr wrote: - AJP defaults changed to listen the loopback address, require a secret and to be disabled in the sample server.xml [snip] Am I correct ? Why such a change ? Why no bugzilla issue for proper tracking and context ? What are your recommendations regarding AJP connector configuration ? It is obviously best to keep default configurations as stable as possible. But sometimes things have to change ... As a result, you'll indeed need to adjust your server.xml according to your deployment and AJP usage. Thank you Rémy for taking the time to answer. I understand the need to introduce a "secured by default" AJP configuration. However, I question one choice that was made for this change : the default behavior of the AJP connector to listen only on the loopback address. This is the change which is, to me, the most questionable one. Because to my understanding, any architecture in which a remote Apache HTTPD is being used will require a *specific IP address of the current host* to be specified in the address attribute of the AJP connector. A specific IP address means that the server.xml is no longer agnostic to the platfom it is being hosted on. Prior to this, a server.xml file could be configured in such way that it would never contain any hard coded value related to the current host. With this change it is no longer possible. (unless I'm missing something). For large deployment configuration, this does seems a bit problematic. Do you understand my concern ? Is there any way to address this ? (The secret attribute is less of a problem, because as stated in the documentation there is an alternative : secretRequired can be set fo false "when the Connector is used on a trusted network".) Make that such a breaking change in a minor maintenance update is quite touchy. I have never seen such drastic change in my usage history of Tomcat. Olivier - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 01:02, Stefan Mayr wrote: Hi, - AJP defaults changed to listen the loopback address, require a secret and to be disabled in the sample server.xml What was the motivation behind this breaking change to require a secret or to explitly disable it? What makes an open AJP connector more unsafe than an open HTTP connector? We have hundreds of Tomcats behind Apache httpd with mod_jk. My interpretation is that upgrading Tomcat 8.5 or 9.0 will break that setup until we disable the secret in all of them (or add a secret in mod_jk and Tomcat). I would understand that for a new major version 10.x but not in the lifecycle of an existing major version. Hi, I second those questions. We also have many tomcat instances behind Apache HTTPD, most of them are not the same server. It is my understanding that the new default listening behavior on the loopback address would break our installation, as the AJP connector would no longer be reachable to our remote Apache HTTP server. It would requires that we update all our tomcat's server.xml configuration to explicitely listen to an additional address by specifying the "address" attribute of the AJP connector. Am I correct ? Why such a change ? Why no bugzilla issue for proper tracking and context ? What are your recommendations regarding AJP connector configuration ? Olivier - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hide a request header to application
On 16/12/2019 16:06, Christopher Schultz wrote: Hello all, I would like to systematically hide a request header to web applications hosted by Tomcat. [...] I took a look at Tomcat's rewrite valve[1] and also at the venerable url-rewrite[2] and I didn't see any options for munging headers. I could have sworn someone wrote a mod_headers port for Tomcat and/or any container, but I guess not. I think this one would indeed require some (light) development work to make it work in the container and not in, say, a proxy. - -chris [1] https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html [2] https://tuckey.org/urlrewrite/ Thank you Christopher for your researchs and pointers. I also thought there would have been some port :/ Anyway I appreciate the time you took to look into this, thanks again. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hide a request header to application
On 16/12/2019 12:25, M. Manna wrote: I would like to systematically hide a request header to web applications hosted by Tomcat. "Blanking" or "Unsetting" a header is not the same as "Hiding". By hiding, you are essentially asking for the Header to be available under certain elevated privilege or conditions. Unless, you meant Unsetting the value or removing the header (not "Hiding")? Hello M. Manna. I meant Unsetting. [... snip] - Is there any way to apply a similar configuration (no development [2]) to Apache Tomcat when there is no front server ? I could not find any built-in valve/filter that would allow such filtering. I don't think there is any, but I wanted to make sure I had not missed something. Not to my knowledge. But I don't see why you cannot implement your own Valve. Of course, any suggestion is welcome unless someone else has any other suggestions? "I don't see why you cannot implement you own" : Because as stated in my original post, I am explicitely looking for a solution which does not requires any developpement. Thank you for your answer though. [...] [2] I know it is possible to develop a quite simple custom ServletFilter to wrap the request with a custom HttpServletRequest wrapper, but I'm looking for a zero development possibility. For those of your reading this discussion later and looking for a development solution, you can find inspiration in the following github repo that you can adapt to handle removal https://github.com/lonelyplanet/tomcat-request-header-filter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Hide a request header to application
Hello all, I would like to systematically hide a request header to web applications hosted by Tomcat. - If Apache HTTPD is used in front of Tomcat, you can use the RequestHeader directive [0]: RequestHeader unset Some-Header-Name - If NGINX is used in front of Tomcat, you can use the proxy_set_header directive [1]: proxy_set_header Some-Header-Name ""; - Is there any way to apply a similar configuration (no development [2]) to Apache Tomcat when there is no front server ? I could not find any built-in valve/filter that would allow such filtering. I don't think there is any, but I wanted to make sure I had not missed something. Olivier [0] https://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader [1] http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header [2] I know it is possible to develop a quite simple custom ServletFilter to wrap the request with a custom HttpServletRequest wrapper, but I'm looking for a zero development possibility. For those of your reading this discussion later and looking for a development solution, you can find inspiration in the following github repo that you can adapt to handle removal https://github.com/lonelyplanet/tomcat-request-header-filter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OutOfMemory on large file download with AJP and cachingAllowed=false
On 26/04/2019 09:56, Mark Thomas wrote: There was an extra copy but Chris's suggestion got me thinking and I found a much better solution. The patch has been applied to 9.0.x and 8.5.x and will be in the next release of both. 7.0.x is not affected. The patch fixes the OutOfMemoryError and the ArrayIndexOutOfBoundsException. Mark Thank you Mark and Christopher for your work on this. As always you rocks. For the record, if anyone is looking for the corresponding issue/bug, none was entered (quite unfortunate from my point of view regarding defect tracking), but the corresponding commit is there : * master (9.x) https://github.com/apache/tomcat/commit/a8f1e96a456d8493a8e64dfe743a8ae663b28ce * 8.5 : https://github.com/apache/tomcat/commit/4ab58e9881ebdc039a657f5f77caf66b673f934b (and also two some commits added for improved getContent javadoc) Thanks again. Olivier PS : completely unrelated to this matter, I just find out that the page https://tomcat.apache.org/svn.html contains outdated information and should probably removed as it as been replaced with https://tomcat.apache.org/source.html
Re: OutOfMemory on large file download with AJP and cachingAllowed=false
On 23/04/2019 16:12, Christopher Schultz wrote: Olivier, Hi Christopher, Thanks for you answer. On 4/23/19 05:58, Olivier Jaquemet wrote: Hi all, We were able to reproduce a OutOfMemory error when using AJP and the Resources cachingAllowed=false directive. It looks like a bug of AJP connector(s), as it does not occurs with other HTTP connectors. Could you confirm the behavior described below is indeed bug ? (if you do, I'll create the issue on bugzilla) To reproduce : * Use latest tomcat 8.5 version (tested with Tomcat 8.5.40) * Add an AJP connector to server.xml nb: no compression nb: NIO connector is in use ; no APR (see stack trace for thread name) * Add the following directive to context.xml : Okay. Why context.xml, by the way? I don't even know (yet...) why this setting was added in the first place in the environment where it was present... ! so why this file... I don't know either :) * Create a large file in the samples webapp, for example : cd webapps/examples dd if=/dev/zero of=large.txt bs=1k count=200 ~2GiB static file * Start Tomcat with a 1024 mb heap size (JAVA_OPTS="-Xms1024m -Xmx1024m" * Configure Apache HTTPD to use mod_proxy_ajp, or mod_jk (both will have the same issue) [1] * Start Apache HTTPD * Download file through default HTTP connector http://localhost:8080/examples/large.txt --> OK * Download file through Apache/AJP http://localhost/examples/large.txt --> BUG : OutOfMemory error occurs Exception in thread "ajp-nio-8009-exec-10" java.lang.OutOfMemoryError: Java heap space at org.apache.catalina.webresources.FileResource.getContent(FileResource. java:207) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServl et.java:992) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java: 438) at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) ... That's ... interesting. What if you request the file more than once via the default connector? I would have expected these code paths to be relatively the same. There are no problems at all if I request the file many times in // using the default HTTP connector. Can you generate a heap dump when the OOME occurs? Use the following JVM startup options: - -XX:+HeapDumpOnOutOfMemoryError - -XX:HeapDumpPath=/path/to/heap-dump-file Sure. Here are heap dumps and log file from two different run : https://www.dropbox.com/sh/q6iqpe42fxvsvin/AAARR4uOnn-qJ4PCg8e_Ll8La?dl=0 If you generate a heap dump, are you able to navigate it? I've heard that Eclipse MAT is good. I've mostly used YourKit and it's quite good, able to pick-out the "big things" and help locate what kind of object(s) is/are taking up all the space. I've used MAT some times before, and indeed it's a really nice tool ! However, if you are familiar with YourKit, you might find the culprit faster than me... Can you have a look a the heap dump I shared above ? I did have a look at it with MAT... however I could not find any definitive conclusion ... There is a BufferedWriter of an AccessLogValve which reference a large char array with \0 (like the content of the large generated file...). There are many (leaking?) java.util.zip.ZipFile$ZipFileInflaterInputStream (however you said there were no compression, though here they are) ... Reading the code for FileResource.getContent, it's clear that the entire file is being loaded into memory, which obviously isn't going to work, here. I'm wondering why that's happening since streaming is the correct behavior when caching=false. Also strange is that DefaultServlet will attempt to call FileResource.getContent() -- which returns a byte[] -- and, if that returns null, it will call FileResource.getInputStream which ... calls this.getContent. So this looks like a special-case for FileResource just trying to implement that interface in the simplest way possible. FileResource seems to implement in-memory caching whether it's enabled or not. I can't understand why this doesn't fail for the other kind of connector. Everything else is the same? You have two separate connectors in one instance, or are you changing the connector between tests? Everything is exactly the same as I have only one instance with two separate connectors (AJP+HTTP). One last (confusing) information in form of an exception, that I could *not* reproduce our test environments, but that I saw on the server where the symptom first occurred. I don't think this is related to the OOM, but it might be another symptom of the same resource configuration. java.lang.ArrayIndexOutOfBoundsException: Unable to return [/path/to/file/being/downloaded.ext] as a byte array since the resource is [2,637,615,704] bytes in size which is larger than the maximum size of a byte array at org.apache.catalina.webresources.FileResource.getContent(
OutOfMemory on large file download with AJP and cachingAllowed=false
Hi all, We were able to reproduce a OutOfMemory error when using AJP and the Resources cachingAllowed=false directive. It looks like a bug of AJP connector(s), as it does not occurs with other HTTP connectors. Could you confirm the behavior described below is indeed bug ? (if you do, I'll create the issue on bugzilla) To reproduce : * Use latest tomcat 8.5 version (tested with Tomcat 8.5.40) * Add an AJP connector to server.xml * Add the following directive to context.xml : * Create a large file in the samples webapp, for example : cd webapps/examples dd if=/dev/zero of=large.txt bs=1k count=200 * Start Tomcat with a 1024 mb heap size (JAVA_OPTS="-Xms1024m -Xmx1024m" * Configure Apache HTTPD to use mod_proxy_ajp, or mod_jk (both will have the same issue) [1] * Start Apache HTTPD * Download file through default HTTP connector http://localhost:8080/examples/large.txt --> OK * Download file through Apache/AJP http://localhost/examples/large.txt --> BUG : OutOfMemory error occurs Exception in thread "ajp-nio-8009-exec-10" java.lang.OutOfMemoryError: Java heap space at org.apache.catalina.webresources.FileResource.getContent(FileResource.java:207) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:992) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:438) at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) ... Additionnal informations : * The bug could be reproduced on both Linux/Windows * Tested with latest OpenJDK 8. Regards, Olivier [1] the HTTPD configuration : * if using mod_proxy_ajp (sudo a2enmod proxy proxy_ajp) ProxyPass / ajp://127.0.0.1:8009/ * if using mod_jk : (sudo a2enmod jk) JkWorkerProperty worker.list=tomcat JkWorkerProperty worker.tomcat.type=ajp13 JkWorkerProperty worker.tomcat.host=localhost JkWorkerProperty worker.tomcat.port=8009 JkMount / tomcat JkMount /* tomcat
Re: ClientAbortException / IOException occurs only when using HttpServletResponseWrapper
On 01/09/2016 08:09, Mark Thomas wrote: On 31 August 2016 13:22:34 BST, Olivier Jaquemet wrote: Hi all, We are encountering a weird but frequent exception when users try to access AVI video playback on IE11. My analysis is that it's a bad behavior of Tomcat when using HttpServletResponseWrapper. I did not want to immediately create a bug report, first because you might have other insight on the subject, and also because the bug affects all tomcat version, thus I wanted to be sure on the appropriate way to report. Indeed the bug report page (https://tomcat.apache.org/bugreport.html) does not explain what to do if bugs affect several version of Tomcat. Only enter bug for the latest version ? Enter bug serval time ? Or maybe there is a way to select multiple product at once ? Open one bug against the earliest affected version. Patches, if any, are most useful if against trunk. I have setup a very simple reproduction webapp (2 nearly empty class, one html, one video) that can be downloaded here : https://www.dropbox.com/s/q61obn8381hugug/test.war?dl=0 (204.72 KB) This webapp is configured with a simple servlet filter, doing nothing special but wrapping the response using a simple HttpServletResponseWrapper (not doing anything at all) and logging request information on exception. To help demonstrate the cause of the problem, the filter expose an init parameter "wrap-response" in web.xml which quickly allows the webapp to be tested with 2 behavior : response wrapped (to exhibit the bug) or not (to behave properly). The home page contains a video player with a very small AVI file. The reproduction steps : * Start Tomcat (any version) with the webapp above * Access the index page using IE 11 on Windows 7 (very important : clear browser cache between each test) --> The exception at the end of this message occurs. * Edit web.xml, set "wrap-response" init parameter to false * Repeat the test with IE (don't forget to clear cache!) --> No exception. The problem may be workaround by modifying Tomcat's web.xml by disabling Accept-Ranges support. useAcceptRanges false Because the ClientAbortException/IOException does not occurs if the response is not wrapped, and does not occurs either if acceptRange is disabled, it really make me think that is a bug in Tomcat (and not a behavior of the client contrary to what ClientAbortException implies). Hmm. The dependence on range support makes me want to double check what the filter is doing. There was an issue with filters, range support and the default servlet several years back. I need to remind myself of the details. Bug verified to exist in all following version (with a default install) (using JDK 1.8.0_102-b14 on Win7 SP1): Apache Tomcat/7.0.70 Apache Tomcat/8.0.36 Apache Tomcat/8.5.4 Apache Tomcat/9.0.0.M9 ** Should I fill the bug report? and if so, on which product should I report the bug ? ** Yes. Against 7.0.x unless 6.0.x is affected as well. I plan to look at this once the current set of releases is complete unless someone else beats me to it. Mark I could verify that the bug also exists in 6.0.45, thus I have entered the following bug report : https://bz.apache.org/bugzilla/show_bug.cgi?id=60076 Thank you Mark. Thanks for your help, Olivier The exception : org.apache.catalina.connector.ClientAbortException: java.io.IOException: Une connexion établie a été abandonnée par un logiciel de votre ordinateur hôte at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:396) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:344) at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:421) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:409) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:97) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:90) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:961) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:398) at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at com.example.BasicFilter.doFilter(BasicFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
ClientAbortException / IOException occurs only when using HttpServletResponseWrapper
Hi all, We are encountering a weird but frequent exception when users try to access AVI video playback on IE11. My analysis is that it's a bad behavior of Tomcat when using HttpServletResponseWrapper. I did not want to immediately create a bug report, first because you might have other insight on the subject, and also because the bug affects all tomcat version, thus I wanted to be sure on the appropriate way to report. Indeed the bug report page (https://tomcat.apache.org/bugreport.html) does not explain what to do if bugs affect several version of Tomcat. Only enter bug for the latest version ? Enter bug serval time ? Or maybe there is a way to select multiple product at once ? I have setup a very simple reproduction webapp (2 nearly empty class, one html, one video) that can be downloaded here : https://www.dropbox.com/s/q61obn8381hugug/test.war?dl=0 (204.72 KB) This webapp is configured with a simple servlet filter, doing nothing special but wrapping the response using a simple HttpServletResponseWrapper (not doing anything at all) and logging request information on exception. To help demonstrate the cause of the problem, the filter expose an init parameter "wrap-response" in web.xml which quickly allows the webapp to be tested with 2 behavior : response wrapped (to exhibit the bug) or not (to behave properly). The home page contains a video player with a very small AVI file. The reproduction steps : * Start Tomcat (any version) with the webapp above * Access the index page using IE 11 on Windows 7 (very important : clear browser cache between each test) --> The exception at the end of this message occurs. * Edit web.xml, set "wrap-response" init parameter to false * Repeat the test with IE (don't forget to clear cache!) --> No exception. The problem may be workaround by modifying Tomcat's web.xml by disabling Accept-Ranges support. useAcceptRanges false Because the ClientAbortException/IOException does not occurs if the response is not wrapped, and does not occurs either if acceptRange is disabled, it really make me think that is a bug in Tomcat (and not a behavior of the client contrary to what ClientAbortException implies). Bug verified to exist in all following version (with a default install) (using JDK 1.8.0_102-b14 on Win7 SP1): Apache Tomcat/7.0.70 Apache Tomcat/8.0.36 Apache Tomcat/8.5.4 Apache Tomcat/9.0.0.M9 ** Should I fill the bug report? and if so, on which product should I report the bug ? ** Thanks for your help, Olivier The exception : org.apache.catalina.connector.ClientAbortException: java.io.IOException: Une connexion établie a été abandonnée par un logiciel de votre ordinateur hôte at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:396) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:344) at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:421) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:409) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:97) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:90) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:961) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:398) at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at com.example.BasicFilter.doFilter(BasicFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteA
Tomcat 8.5 : Java SE 7, README.html mistake ?
Tomcat 8.5 : Java SE 7, README.html mistake ? Hello all, As far as I know, Tomcat 8.5 requires Java SE 7, as indicated in many official sources (see below). However, one quite visible source is stating otherwise and may requires an update to prevent confusion, the README.html displayed on all mirrors "Tomcat 8.5 requires Java SE 8 or later. Read the RELEASE-NOTES and the RUNNING.txt file in the distribution for more details." http://archive.apache.org/dist/tomcat/tomcat-8/v8.5.3/README.html http://mirrors.ircam.fr/pub/apache/tomcat/tomcat-8/v8.5.3/README.html http://apache.mindstudios.com/tomcat/tomcat-8/v8.5.3/README.html Sources which are hopefully correct :) - Mark Thomas in "Introducing Apache Tomcat 8.5" Webinar "8.5 has to run on Java 7" https://www.youtube.com/watch?v=kBJCIpPLWm0&feature=youtu.be&t=300 - Tomcat SVN : "Apache Tomcat @VERSION_MAJOR_MINOR@ requires a Java Standard Edition Runtime Environment (JRE) version 7 or later." http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/RUNNING.txt - 8.5.3 Release notes : "Tomcat 8.5 is designed to run on Java SE 7 and later." http://mirrors.ircam.fr/pub/apache/tomcat/tomcat-8/v8.5.3/RELEASE-NOTES - Apache Tomcat "Which version" page : 8.5.3 : 7 and later http://tomcat.apache.org/whichversion.html - RUNNING.txt in 8.5.3 distribution archive "Apache Tomcat 8.5 requires a Java Standard Edition Runtime Environment (JRE) version 7 or later." http://mirrors.ircam.fr/pub/apache/tomcat/tomcat-8/v8.5.3/ Thanks Olivier Olivier - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
