Re: Using log4j for logging
On 29/06/2021 17:53, Niranjan Rao wrote: We are actually using log4j2, I should have been more clearer. Ack. Does this mean we don't have to use specialized juli jar and adapters and many of the stackoverflow answers are out of date? Yes. I have seen answers saying download juli adapter version from tomcat version 7 and use it for 9 or similar. I guess that might work but I'd be surprised. Mark Regards, Niranjan On 6/29/21 12:24 AM, Mark Thomas wrote: On 29/06/2021 01:11, Niranjan Rao wrote: Greetings, I wanted to setup log4j for tomcat logs and google searches seems to indicate that this is possible. Many articles speak about downloading tomcat-juli-adapters.jar from bin/extras directory. I found out that for tomcat version 9, extras directory is last present on version 9.0.14 (https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). Latter versions do not have extras directory. Is tomcat-juli-adapters file no longer required? What will be the best way to configure tomcat logs using log4j. log4j was declared end of life in 2015. If you really need to use log4j then there are some pointers here: https://stackoverflow.com/questions/869945/how-to-send-java-util-logging-to-log4j I'd recommend the answer from Emmanuel Bourg. If you are using log4j2 then you can use: https://logging.apache.org/log4j/2.x/log4j-jpl/index.html Mark - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using log4j for logging
We are actually using log4j2, I should have been more clearer. Does this mean we don't have to use specialized juli jar and adapters and many of the stackoverflow answers are out of date? I have seen answers saying download juli adapter version from tomcat version 7 and use it for 9 or similar. Regards, Niranjan On 6/29/21 12:24 AM, Mark Thomas wrote: On 29/06/2021 01:11, Niranjan Rao wrote: Greetings, I wanted to setup log4j for tomcat logs and google searches seems to indicate that this is possible. Many articles speak about downloading tomcat-juli-adapters.jar from bin/extras directory. I found out that for tomcat version 9, extras directory is last present on version 9.0.14 (https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). Latter versions do not have extras directory. Is tomcat-juli-adapters file no longer required? What will be the best way to configure tomcat logs using log4j. log4j was declared end of life in 2015. If you really need to use log4j then there are some pointers here: https://stackoverflow.com/questions/869945/how-to-send-java-util-logging-to-log4j I'd recommend the answer from Emmanuel Bourg. If you are using log4j2 then you can use: https://logging.apache.org/log4j/2.x/log4j-jpl/index.html Mark - 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: 500 instances of tomcat on the same server
Eric, On 6/28/21 13:08, Eric Robinson wrote: -Original Message- From: Christopher Schultz Sent: Monday, June 28, 2021 8:54 AM To: users@tomcat.apache.org Subject: Re: 500 instances of tomcat on the same server Eric, On 6/25/21 22:58, Eric Robinson wrote: We can run 75 to 125 instances of tomcat on a single Linux server with 12 cores and 128GB RAM. It works great. CPU is around 25%, our JVMs are not throwing OOMEs, iowait is minimal, and network traffic is about 30Mbps. We're happy with the results. Now we're upping the ante. We have a 48-core server with 1TB RAM, and we're planning to run 600+ tomcat instances on it simultaneously. What caveats or pitfalls should we watch out for? Are there any hard limits that would prevent this from working as expected? If you have the resources, I see no reason why this would present any problems. On the other hand, what happens when you need to upgrade the OS on this beast? You are now talking about disturbing not 72-125 clients, but 600 of them. There are two load-balanced servers, each with adequate power to support the whole load. When we want to maintain Server A, we drain it at the load balancer and wait for the last active connection to complete. Then we reboot/maintain the server and add it back into the rotation gracefully. Sounds good. I'm curious, are you using the LoadBalancerDrainingValve for that purpose? What are you using for your load-balancer and/or reverse-proxy? If I had a beast like this, I'd run VMWare (or similar) on it, carve it up into virtual machines, and run fewer clients on each just for the sheer flexibility of it. We considered doing it that way. Performance is top priority, so we ultimately decided to run the instances on metal rather than introducing a few trillion lines of OS code into the mix. We might consider containerizing. If this is already a virtualized/cloud environment, then I think you're doing it wrong: don't provision one huge instance and use it for multiple clients. Instead, provision lots of small instances and use them for fewer (or even 1) at a time. That makes sense until you know the environment better. It's a canned application and we're not the publisher. Breaking it out this way gives us the ability to present each customer and a unique entity to the publisher for support purposes. When their techs connect, the sandbox allows them to troubleshoot and support our mutual customer independently, which puts them in an environment their techs are comfortable with, and removed the risk of them doing something that impacts everybody on the server (or in the VM, if we used those). Okay. I'm sure I don't understand, but if you have heterogeneous support getting involved, to me it would be even more important to isolate all those applications from each other. Maybe you mean in-application support for mutual customers and not in-OS, etc. support. All I can tell you is we've been running it this way for 15 years and we've never looked back and wished we were doing it differently. That's a good position to be in. :) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 500 instances of tomcat on the same server
All, On 6/29/21 11:33, Eric Robinson wrote: -Original Message- From: Berneburg, Cris J. - US Sent: Tuesday, June 29, 2021 7:16 AM To: users@tomcat.apache.org Subject: RE: 500 instances of tomcat on the same server Eric and Mark Just curious... Eric> We can run 75 to 125 instances of tomcat on a single Linux server Eric, Do you have or need a centralized way of managing all those instances? Hi Cris and Mark, We have about 1500 instances of tomcat (750 load-balanced virtual services across 20 physical servers). We currently manage the environment with scripts. Due to the simplicity and consistency of our internal deployment standards, it works well and is pretty easy to manage on an instance-by-instance basis, but a web console where we can see the environment as a whole, or filter on portions of it, would be amazing! A few years ago, a team from Cerner health came to ApacheCon and introduced their product called Jwala that was intended to do this kind of thing. You can find their presentation slides and video linked from the Tomcat presentations page: http://tomcat.apache.org/presentations.html The product appears to have undergone very little development in the past 4 years: it looks like they dropped it on GitHub and mostly forgot about it. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange error with JSP
Konstantin,
On 6/29/21 10:21, Konstantin Kolinko wrote:
ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :
All,
On 6/2/21 13:52, Christopher Schultz wrote:
All,
I don't do too much work with JSPs, but I do have a few quick-and-dirty
administrative things including one called the "session snooper" which
just dumps out loads of information about the current user's session
object.
I'm getting this error in production, and I can reproduce it every time
I access the page. Here's the exception stack trace:
java.lang.ClassNotFoundException: org.apache.jsp.admin.SessionSnooper_jsp
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:128)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:59)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:159)
at
org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:192)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:413)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
[...filters, etc...]
This is a relatively simple JSP. There are no tag libraries in use and
there are 3 imports of JSPs which contain some static utility functions.
Both files
app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
and
app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
exist and have file-dates from way back in 2016. (No recent changes)
The context has been restarted/reloaded (not redeployed) recently using
JMX a few times, but nothing else relevant comes to mind.
This is Tomcat 8.5.65 from a stock ASF-distrubuted tarball, launched
using "catalina.sh start". Nothing fancy.
What other information can I collect to help debug this? My expectation
would be that the class should be findable and runnable. Tomcat should
not be tripping over its own feet on this one IMO.
There is more in my catalina.out file:
Jun 02, 2021 4:12:27 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path
[/[$context]] threw exception [java.lang.NullPointerException] with root
cause
java.lang.NullPointerException
at
org.apache.jasper.JspCompilationContext.createOutputDir(JspCompilationContext.java:685)
at
org.apache.jasper.JspCompilationContext.getOutputDir(JspCompilationContext.java:204)
at
org.apache.jasper.JspCompilationContext.getClassFileName(JspCompilationContext.java:537)
at
org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:464)
at
org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:430)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:590)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
Here's the code from createOutputDir:
l684File base = options.getScratchDir();
l685baseUrl = base.toURI().toURL();
l686outputDir = base.getAbsolutePath() + File.separator + path +
l687File.separator;
l688if (!makeOutputDir()) {
l689throw new
IllegalStateException(Localizer.getMessage("jsp.error.outputfolder"));
l690}
I'm not playing any games with JSP configuration or scratch/work
directory locations, etc.
Looking at line 685,
It is odd:
If options.getScratchDir() were returning null, you would see fatal
errors in your log earlier: The "options" variable should be an
instance of o.a.j.EmbeddedServletOptions. Its constructor initializes
the scratchDir field, does some checks and logs with log.fatal() when
the dir is null or not readable and writable.
A java.io.File.toURI() call cannot return null: the only possible
returned value is a new object, "new URI(...)" (looking into the
sources from Java 8u292).
BTW, I wonder whether your JspServlet is configured "for production",
http://tomcat.apache.org/tomcat-8.5-doc/jasper-howto.html#Production_Configuration
Unfortunately, I have restarted (or possibly reloaded) the server since
then and can no longer replicate the error. But I'm happy to answer
questions if it helps zero-in on a bug in Tomcat. I think there's
definitely someting that CAN go wrong but shouldn't. So I think there is
a bug hidden, here, somewhere.
I have no special configuration for JSP in my application: it's whatever
the defaults are that ship with a stock Tomcat. We don't use JSPs
heavily, and those JSPs we do use
Re: TLSv1.3 Support in Tomcat
Daniel, On 6/29/21 02:03, Daniel Savard wrote: https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites TLSv1.3 supports 5 cipher suites and none is in your list. +1 Abirami, Also, you aren't providing any or other elements, so we can't tell what type of ey/cert you are using: RSA or EC? Try adding: TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ... to your list. Note that you have both RSA and EC-based cipher suites in your cipher suites string, and with only a single certificate, you cannot possibly actually support both. -chris Le mar. 29 juin 2021 à 01:44, S Abirami a écrit : Hi Christopher, Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 it is working fine with TLSv1.2. When sslEnabledProtocols=TLSv1.3, Tomcat is started but, the browser unable to perform handshake with webapp. Is there any dependency with Cipher suites? Regards, Abirami.S -Original Message- From: Christopher Schultz Sent: Monday, June 28, 2021 7:27 PM To: users@tomcat.apache.org Subject: Re: TLSv1.3 Support in Tomcat Abirami, On 6/28/21 07:16, S Abirami wrote: TLSv1.3 support is available in Tomcat. I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and restarted tomcat. It doesn't work. [We are using Tomcat 9.0.46 and JDK 8u291] Please let me know any other configuration also needs to be changed. Can you please post your configuration (minus any secrets)? When you say "it doesn't work", what exactly do you mean? -chris - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: 500 instances of tomcat on the same server
> -Original Message- > From: Berneburg, Cris J. - US > Sent: Tuesday, June 29, 2021 7:16 AM > To: users@tomcat.apache.org > Subject: RE: 500 instances of tomcat on the same server > > Eric and Mark > > Just curious... > > Eric> We can run 75 to 125 instances of tomcat on a single Linux server > > Eric, Do you have or need a centralized way of managing all those instances? Hi Cris and Mark, We have about 1500 instances of tomcat (750 load-balanced virtual services across 20 physical servers). We currently manage the environment with scripts. Due to the simplicity and consistency of our internal deployment standards, it works well and is pretty easy to manage on an instance-by-instance basis, but a web console where we can see the environment as a whole, or filter on portions of it, would be amazing! > It sounds like different support groups connect to their own instances, if I > understand correctly. > Same software vendor, different technicians. When they call, they are seeking to support an individual customer. We give them an interface through which they see a sandboxed representation of that customer's deployment. The servers themselves are multi-tenanted, but when the support techs connect, it looks to them like a single instance. Each customer is running the same canned webapp, but possibly different versions of it, with different memory configurations, and requiring different versions of tomcat and the JVM. > Mark> if there are changes we could make to Tomcat that would it easier > Mark> to run and manage that many instances do let us know. > Mark> We'd be happy to consider them. > > Mark, did you already have something in mind? Like a TC Manager-manager? > Some sort of dashboard that is able to perform TC Manager ops against all > the instances? > > -- > Cris Berneburg > CACI Senior Software Engineer > > > > > This electronic message contains information from CACI International Inc or > subsidiary companies, which may be company sensitive, proprietary, > privileged or otherwise protected from disclosure. The information is > intended to be used solely by the recipient(s) named above. If you are not > an intended recipient, be aware that any review, disclosure, copying, > distribution or use of this transmission or its contents is prohibited. If you > have received this transmission in error, please notify the sender > immediately. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange error with JSP
ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :
>
> All,
>
> On 6/2/21 13:52, Christopher Schultz wrote:
> > All,
> >
> > I don't do too much work with JSPs, but I do have a few quick-and-dirty
> > administrative things including one called the "session snooper" which
> > just dumps out loads of information about the current user's session
> > object.
> >
> > I'm getting this error in production, and I can reproduce it every time
> > I access the page. Here's the exception stack trace:
> >
> > java.lang.ClassNotFoundException: org.apache.jsp.admin.SessionSnooper_jsp
> > java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > at
> > org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:128)
> > at
> > org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:59)
> > at
> > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:159)
> >
> > at
> > org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:192)
> >
> > at
> > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:413)
> >
> > at
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
> > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
> > [...filters, etc...]
> >
> > This is a relatively simple JSP. There are no tag libraries in use and
> > there are 3 imports of JSPs which contain some static utility functions.
> >
> > Both files
> > app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
> > and
> > app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
> > exist and have file-dates from way back in 2016. (No recent changes)
> >
> > The context has been restarted/reloaded (not redeployed) recently using
> > JMX a few times, but nothing else relevant comes to mind.
> >
> > This is Tomcat 8.5.65 from a stock ASF-distrubuted tarball, launched
> > using "catalina.sh start". Nothing fancy.
> >
> > What other information can I collect to help debug this? My expectation
> > would be that the class should be findable and runnable. Tomcat should
> > not be tripping over its own feet on this one IMO.
>
> There is more in my catalina.out file:
>
> Jun 02, 2021 4:12:27 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [jsp] in context with path
> [/[$context]] threw exception [java.lang.NullPointerException] with root
> cause
> java.lang.NullPointerException
> at
> org.apache.jasper.JspCompilationContext.createOutputDir(JspCompilationContext.java:685)
> at
> org.apache.jasper.JspCompilationContext.getOutputDir(JspCompilationContext.java:204)
> at
> org.apache.jasper.JspCompilationContext.getClassFileName(JspCompilationContext.java:537)
> at
> org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:464)
> at
> org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:430)
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:590)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
>
> Here's the code from createOutputDir:
>
>
> l684File base = options.getScratchDir();
> l685baseUrl = base.toURI().toURL();
> l686outputDir = base.getAbsolutePath() + File.separator + path +
> l687File.separator;
> l688if (!makeOutputDir()) {
> l689throw new
> IllegalStateException(Localizer.getMessage("jsp.error.outputfolder"));
> l690}
>
> I'm not playing any games with JSP configuration or scratch/work
> directory locations, etc.
Looking at line 685,
It is odd:
If options.getScratchDir() were returning null, you would see fatal
errors in your log earlier: The "options" variable should be an
instance of o.a.j.EmbeddedServletOptions. Its constructor initializes
the scratchDir field, does some checks and logs with log.fatal() when
the dir is null or not readable and writable.
A java.io.File.toURI() call cannot return null: the only possible
returned value is a new object, "new URI(...)" (looking into the
sources from Java 8u292).
BTW, I wonder whether your JspServlet is configured "for production",
http://tomcat.apache.org/tomcat-8.5-doc/jasper-howto.html#Production_Configuration
Has the page been compiled once, or its modification time is being
checked over and over, or even worse: being recompiled?
Are "webapps" and "work" directories on the same kind of file system
(with the same supported precision for file modification times)?
BTW,
A java.lang.ClassNotFoundException with
RE: TLSv1.3 Support in Tomcat
My guess would be that whatever JRE webstart is using to launch does not support TLS 1.3. We used webstart for a long time, and this type of error looks pretty familiar. As I am sure you have experienced, just because the browser can connect (with its certifications, proxies, protocols, ...) does not mean that the VM can connect. I think support for TLS 1.3 in JDK 8 started in 261 There is this bug too, but I don't think this manifests itself with a nice error (like "protocol_version"): https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-sockets-fail-on-a-handshake-failure-error-with-tlsv1-3-enable Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -Original Message- From: S Abirami Sent: Tuesday, June 29, 2021 6:01 AM To: Tomcat Users List Subject: [Possible Spam] RE: TLSv1.3 Support in Tomcat Importance: Low Hi ALL, Web UI launched successfully. Using a link in the web UI, we will download and launch a Java Web start Launcher (JNLP). JNLP is not opening, it is due to the problem in Tomcat or it is problem in the JDK. Following exception thrown javax.net.ssl.SSLException: Received fatal alert: protocol_version at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivilegedWithCombiner(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source) at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source) at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source) at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unkn -Original Message- From: Daniel Savard Sent: Tuesday, June 29, 2021 11:33 AM To: Tomcat Users List Subject: Re: TLSv1.3 Support in Tomcat https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites TLSv1.3 supports 5 cipher suites and none is in your list. - Daniel Savard Le mar. 29 juin 2021 à 01:44, S Abirami a écrit : > Hi Christopher, > > Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 > it is working fine with TLSv1.2. When sslEnabledProtocols=TLSv1.3, > Tomcat is started but, the browser unable to perform handshake with webapp. > > Is there any dependency with Cipher suites? > > protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp" > port="" maxThreads="200" scheme="https" secure="true" > SSLEnabled="true" keystoreFile="/opt/cert/keystore" > keystorePass="" clientAuth="false" > maxHttpHeaderSize="8192" server="" xpoweredBy="false" > ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_S > HA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, >
RE: Strange error with JSP
Hi Chris Was there a final resolution to this? -- Cris Berneburg CACI Senior Software Engineer -Original Message- From: Christopher Schultz Sent: Wednesday, June 2, 2021 1:52 PM To: Tomcat Users List Subject: Strange error with JSP All, I don't do too much work with JSPs, but I do have a few quick-and-dirty administrative things including one called the "session snooper" which just dumps out loads of information about the current user's session object. I'm getting this error in production, and I can reproduce it every time I access the page. Here's the exception stack trace: java.lang.ClassNotFoundException: org.apache.jsp.admin.SessionSnooper_jsp java.net.URLClassLoader.findClass(URLClassLoader.java:382) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:128) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:59) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:159) at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:192) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:413) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330) at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) [...filters, etc...] This is a relatively simple JSP. There are no tag libraries in use and there are 3 imports of JSPs which contain some static utility functions. Both files app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java and app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java exist and have file-dates from way back in 2016. (No recent changes) The context has been restarted/reloaded (not redeployed) recently using JMX a few times, but nothing else relevant comes to mind. This is Tomcat 8.5.65 from a stock ASF-distrubuted tarball, launched using "catalina.sh start". Nothing fancy. What other information can I collect to help debug this? My expectation would be that the class should be findable and runnable. Tomcat should not be tripping over its own feet on this one IMO. Thanks, -chris This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: 500 instances of tomcat on the same server
Eric and Mark Just curious... Eric> We can run 75 to 125 instances of tomcat on a single Linux server Eric, Do you have or need a centralized way of managing all those instances? It sounds like different support groups connect to their own instances, if I understand correctly. Mark> if there are changes we could make to Tomcat that would it Mark> easier to run and manage that many instances do let us know. Mark> We'd be happy to consider them. Mark, did you already have something in mind? Like a TC Manager-manager? Some sort of dashboard that is able to perform TC Manager ops against all the instances? -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TLSv1.3 Support in Tomcat
Hi ALL, Web UI launched successfully. Using a link in the web UI, we will download and launch a Java Web start Launcher (JNLP). JNLP is not opening, it is due to the problem in Tomcat or it is problem in the JDK. Following exception thrown javax.net.ssl.SSLException: Received fatal alert: protocol_version at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivilegedWithCombiner(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source) at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source) at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source) at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unkn -Original Message- From: Daniel Savard Sent: Tuesday, June 29, 2021 11:33 AM To: Tomcat Users List Subject: Re: TLSv1.3 Support in Tomcat https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites TLSv1.3 supports 5 cipher suites and none is in your list. - Daniel Savard Le mar. 29 juin 2021 à 01:44, S Abirami a écrit : > Hi Christopher, > > Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 > it is working fine with TLSv1.2. When sslEnabledProtocols=TLSv1.3, > Tomcat is started but, the browser unable to perform handshake with webapp. > > Is there any dependency with Cipher suites? > > protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp" > port="" maxThreads="200" scheme="https" secure="true" > SSLEnabled="true" keystoreFile="/opt/cert/keystore" > keystorePass="" clientAuth="false" > maxHttpHeaderSize="8192" server="" xpoweredBy="false" > ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_S > HA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, > TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_RSA_WITH_AES_128_GCM_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA" > sslEnabledProtocols=" TLSv1.3"/> > > > > Regards, > Abirami.S > > -Original Message- > From: Christopher Schultz > Sent: Monday, June 28, 2021 7:27 PM > To: users@tomcat.apache.org > Subject: Re: TLSv1.3 Support in Tomcat > > Abirami, > > On 6/28/21 07:16, S Abirami wrote:
RE: TLSv1.3 Support in Tomcat
Hi Daniel, Thanks for the response. It's working after adding the cipher suites. I have one more question. In JDK 1.8, TLSv1.3 communication mentioned as half duplex policy communication and how about tomcat 9.0.46 whether it is half duplex and full duplex? Regards, Abirami.S -Original Message- From: Daniel Savard Sent: Tuesday, June 29, 2021 11:33 AM To: Tomcat Users List Subject: Re: TLSv1.3 Support in Tomcat https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites TLSv1.3 supports 5 cipher suites and none is in your list. - Daniel Savard Le mar. 29 juin 2021 à 01:44, S Abirami a écrit : > Hi Christopher, > > Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 > it is working fine with TLSv1.2. When sslEnabledProtocols=TLSv1.3, > Tomcat is started but, the browser unable to perform handshake with webapp. > > Is there any dependency with Cipher suites? > > protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp" > port="" maxThreads="200" scheme="https" secure="true" > SSLEnabled="true" keystoreFile="/opt/cert/keystore" > keystorePass="" clientAuth="false" > maxHttpHeaderSize="8192" server="" xpoweredBy="false" > ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_S > HA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, > TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_RSA_WITH_AES_128_GCM_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA" > sslEnabledProtocols=" TLSv1.3"/> > > > > Regards, > Abirami.S > > -Original Message- > From: Christopher Schultz > Sent: Monday, June 28, 2021 7:27 PM > To: users@tomcat.apache.org > Subject: Re: TLSv1.3 Support in Tomcat > > Abirami, > > On 6/28/21 07:16, S Abirami wrote: > > TLSv1.3 support is available in Tomcat. > > > > I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and > > restarted tomcat. It doesn't work. > > > > [We are using Tomcat 9.0.46 and JDK 8u291] > > > > Please let me know any other configuration also needs to be changed. > > Can you please post your configuration (minus any secrets)? > > When you say "it doesn't work", what exactly do you mean? > > -chris > > - > 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 > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Possible bug in http2 window size handling in tomcat 9.0.45
On 29/06/2021 09:26, Erik Nilsson wrote: Sorry but there seems to be no difference in the behaviour.. /Erik OK. Thanks for testing. I'm going to need those debug logs then to figure out what is going on. Mark Den mån 28 juni 2021 kl 20:44 skrev Mark Thomas : On 28/06/2021 15:11, Mark Thomas wrote: On 28/06/2021 10:53, Erik Nilsson wrote: Yep, something seems to go wrong with the waitingFor field in WindowAllocationManager. We are developing a quite complex embedded cms application, don't know if I will be able to share this application. Hopefully you can reproduce this anyway by using the nghttp client and another large webapp? One thing to notice is that we can't reproduce this by accessing the webapplication directly with any browser, but with a f5-proxy in production and nghttp it occurs almost every time. I'll see what I can do to reproduce this. Any chance you could run Tomcat with http2 debug logging enabled, trigger the issue and then post the debug logs (or send them to me privately if you prefer?). I've found a bug in the sendfile handling. Can you add useSendfile="false" to the associated element and see if that works around the issue. Thanks, Mark - 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: Possible bug in http2 window size handling in tomcat 9.0.45
Sorry but there seems to be no difference in the behaviour.. /Erik Den mån 28 juni 2021 kl 20:44 skrev Mark Thomas : > On 28/06/2021 15:11, Mark Thomas wrote: > > On 28/06/2021 10:53, Erik Nilsson wrote: > >> Yep, something seems to go wrong with the waitingFor field in > >> WindowAllocationManager. > >> > >> We are developing a quite complex embedded cms application, don't know > >> if I > >> will be able to share this application. Hopefully you can reproduce this > >> anyway by using the nghttp client and another large webapp? One thing to > >> notice is that we can't reproduce this by accessing the > >> webapplication directly with any browser, but with a f5-proxy in > >> production > >> and nghttp it occurs almost every time. > > > > I'll see what I can do to reproduce this. > > > > Any chance you could run Tomcat with http2 debug logging enabled, > > trigger the issue and then post the debug logs (or send them to me > > privately if you prefer?). > > I've found a bug in the sendfile handling. Can you add > useSendfile="false" to the associated element and see > if that works around the issue. > > Thanks, > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --
Re: Using log4j for logging
On 29/06/2021 01:11, Niranjan Rao wrote: Greetings, I wanted to setup log4j for tomcat logs and google searches seems to indicate that this is possible. Many articles speak about downloading tomcat-juli-adapters.jar from bin/extras directory. I found out that for tomcat version 9, extras directory is last present on version 9.0.14 (https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). Latter versions do not have extras directory. Is tomcat-juli-adapters file no longer required? What will be the best way to configure tomcat logs using log4j. log4j was declared end of life in 2015. If you really need to use log4j then there are some pointers here: https://stackoverflow.com/questions/869945/how-to-send-java-util-logging-to-log4j I'd recommend the answer from Emmanuel Bourg. If you are using log4j2 then you can use: https://logging.apache.org/log4j/2.x/log4j-jpl/index.html Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TLSv1.3 Support in Tomcat
https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites TLSv1.3 supports 5 cipher suites and none is in your list. - Daniel Savard Le mar. 29 juin 2021 à 01:44, S Abirami a écrit : > Hi Christopher, > > Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 it is > working fine with TLSv1.2. When sslEnabledProtocols=TLSv1.3, Tomcat is > started but, the browser unable to perform handshake with webapp. > > Is there any dependency with Cipher suites? > > protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp" > port="" maxThreads="200" scheme="https" secure="true" > SSLEnabled="true" keystoreFile="/opt/cert/keystore" > keystorePass="" clientAuth="false" > maxHttpHeaderSize="8192" server="" xpoweredBy="false" > ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, > TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA" > sslEnabledProtocols=" TLSv1.3"/> > > > > Regards, > Abirami.S > > -Original Message- > From: Christopher Schultz > Sent: Monday, June 28, 2021 7:27 PM > To: users@tomcat.apache.org > Subject: Re: TLSv1.3 Support in Tomcat > > Abirami, > > On 6/28/21 07:16, S Abirami wrote: > > TLSv1.3 support is available in Tomcat. > > > > I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and > > restarted tomcat. It doesn't work. > > > > [We are using Tomcat 9.0.46 and JDK 8u291] > > > > Please let me know any other configuration also needs to be changed. > > Can you please post your configuration (minus any secrets)? > > When you say "it doesn't work", what exactly do you mean? > > -chris > > - > 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 > >
