Re: Tomcat closes connections on unexpected status codes

[Rémy Maucherat]

On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:
>
> On 18/04/2024 09:07, Stefan Ansing wrote:
> > Hi,
> >
> > We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
> > where we see that HTTP/1.1 connections are closed whenever a servlet
> > application returns the following status codes: 400, 408, 411, 414, 500,
> > 503, 501. This causes client applications to rapidly reconnect and induce
> > high server-side CPU load due to doing TLS handshakes.
> >
> > The 400 and 500 status codes are commonly used in RESTful microservices to
> > communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
> > closing connections on these status codes.
> >
> > After testing with Undertow (version 2.3.12), where we didn't see the same
> > behaviour, we believe that these status codes do not necessitate a new
> > connection.
>
> The Tomcat developers disagree. Connections are closed after these
> status codes to avoid various forms of request smuggling attacks.
>
> > Checking the Tomcat sources makes me believe that the behaviour is
> > hard-coded[1]. I'm reaching out here to re-evaluate the list of status
> > codes and to discuss the possibilities of making the behaviour configurable.
>
> Making this list of status codes configurable seems reasonable. The
> default can stay as current and if users want to change it then they
> have to accept the associated security risks.

If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...

Rémy

> Mark
>
>
> >
> > A colleague of mine reported a bug for this issue:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=68901
> >
> > Kind regards,
> > Stefan Ansing
> >
> > [1]:
> > https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617
> >
>
> -
> 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

[ANN] Apache Tomcat 9.0.88 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.88.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.88 is a bugfix and feature release. The notable
changes compared to 9.0.87 include:

- Cookies header generation enhancements.

- Fix regression when reloading TLS configuration and files.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 11.0.0-M19 (alpha) available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M19 (alpha).

Apache Tomcat 11 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M19 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M18 include:

- Finalize update to the Jakarta EE 11 specifications.

- Cookies header generation enhancements.

- Fix regression when reloading TLS configuration and files.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-11.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-11.cgi

Migration guides from Apache Tomcat 8.5.x, 9.0.x and 10.1.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.87 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.87.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.87 is a bugfix and feature release. The notable
changes compared to 9.0.86 include:

- When restoring a saved POST request after a successful FORM
   authentication, ensure that neither the URI, the query string nor
   the protocol are corrupted when restoring the request body.

- Align error handling for Writer and OutputStream. Ensure use of either
   once the response has been recycled triggers a NullPointerException
   provided that discardFacades is configured with the default value of
   true.

- The standard thread pool implementations that are
   configured using the Executor element now implement
   ExecutorService for better support of NIO2 or others.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: When does Tomcat add and remove threads?

[Rémy Maucherat]

On Tue, Mar 12, 2024 at 5:55 PM  wrote:
>
> All,
>
>
> > -Original Message-
> > From: Christopher Schultz 
> > Sent: Tuesday, March 12, 2024 8:31 AM
> > To: users@tomcat.apache.org
> > Subject: Re: When does Tomcat add and remove threads?
> >
> > John,
> >
> > On 3/11/24 18:14, john.e.gr...@wellsfargo.com.INVALID wrote:
> > > From: Christopher Schultz 
> > > Sent: Monday, March 11, 2024 5:09 PM
> >  >
> > >> On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:
> > >>> I am using Tomcat 9.x.
> > >>>
> > >>> When does Tomcat add and remove threads from its internal thread
> > >>> pool?  I'm talking about the threads with names like
> > >>> http-nio-8080-exec-1.  It appears the thread pool is Tomcat's own
> > >>> ThreadPoolExecutor but I don't see the exact behavior documented.
> > >>> I'm familiar with how java.util.concurrent does it, but it looks
> > >>> like Tomcat's version is a little different.
> >  >>
> > >> Are you looking for a technical explanation with code references, or
> > >> a plain-English description of when threads are created and added? >
> > > Mostly plain English like the j.u.c. ThreadPoolExecutor Java doc has.
> > > What happens when all core threads are in use?  When do tasks go on
> > > the queue?  When does core thread + 1 get added?  When do threads get
> > > removed?
> > Tomcat will create thread pools under two separate circumstances. They are
> > related, but behave somewhat differently.
> >
> > First, if you declare an  in your server.xml, then a thread pool 
> > will be
> > created. You can control the number of threads and their retention policy 
> > such
> > as "keep X spare threads around" and "retire threads after N seconds without
> > being used."
> >
> > Second, if you declare a  without specifying an "executor", a
> > thread pool will be configured for you but you don't really have control 
> > over it
> > because all those nice configuration options for an  are not 
> > available
> > on the . If you want to control those settings, use a 
> > linked with an . To be clear, if you declare a  
> > without an
> > "executor" attribute, your thread pool will be of a fixed size and threads 
> > will
> > never be released. (I think the thread pool starts small and grows but will
> > never shrink.)
> >
> > An  is implemented in the StandardThreadExecutor and
> > ThreadPoolExecutor classes, which I believe were adaptations of classes from
> > java.util.concurrent introduced into Tomcat before java.util.concurrent was
> > actually available -- which is why it wasn't used directly in Tomcat. (NB: 
> > The
> > ThreadPoolExecutor class in Tomcat contains an "@author Doug Lea" tag. The
> > Tomcat source is licensed under AL2, the JDK source is licensed under GPL2,
> > but the original was released by Doug Lea into the public domain under a CC0
> > 1.0 Deed license.)
> >
> > The re-sizing occurs in the ThreadPoolExecutor class if you'd like to read 
> > it. It is
> > not entirely straightforward. You could start by reading the code for the
> > runWorker(Worker w) method where, at the end, processWorkerExit is called.
> >
> > But since Tomcat's ThreadPoolExecutor is basically Java's 
> > ThreadPoolExecutor,
> > they work the same.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
>
> I took matters in to my own hands and wrote a test to see what was happening.
>
> Unlike java.util.concurrent.ThreadPoolExecutor, Tomcat's TPE adds threads 
> when all core threads are busy.  It only adds tasks to the queue when max 
> threads are busy.  I prefer this behavior to the JDK behavior.
>
> Threads are removed when idle for 60 seconds.  This appears to be hard-coded 
> in AbstreactEndpoint.createExecutor().

I have added configuration for that, since this was not right.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.86 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.86.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.86 is a bugfix and feature release. The notable
changes compared to 9.0.85 include:

- Add improvements to the CSRF prevention filter including the ability
   to skip adding nonces for resource name and subtree URL patterns.

- Add support for user provided SSLContext instances configured on
   SSLHostConfigCertificate instances. Based on pull request #673
   provided by Hakan Altındağ.

- Review usage of debug logging and downgrade trace or data dumping
   operations from debug level to trace.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.85 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.85.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.85 is a bugfix and feature release. The notable
changes compared to 9.0.84 include:

- Fix virtual thread support for the NIO2 connector

- Correct a regression in the fix for 67675 that broke TLS key file
   parsing for PKCS#8 format keys that do not specify an explicit
   pseudo-random function and rely on the default. This typically affects
   keys generated by OpenSSL 1.0.2.

- Allow multiple operations with the same name on introspected mbeans,
   fixing a regression caused by the introduction of a second
   addSslHostConfig() method.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Run Tomcat as native image

[Rémy Maucherat]

On Wed, Dec 20, 2023 at 5:33 AM Jun Suzuki  wrote:
>
> 2023年12月19日(火) 16:11 Jun Suzuki :
> >
> > 2023年12月19日(火) 1:18 Rémy Maucherat :
> > >
> > > On Mon, Dec 18, 2023 at 1:28 PM Jun Suzuki  
> > > wrote:
> > > >
> > > > Hello all,
> > > >
> > > > I'm now following the guide of
> > > > https://tomcat.apache.org/tomcat-11.0-doc/graal.html to build Tomcat
> > > > into native image.
> > > > The original thread I posted before has become too long to be easily
> > > > understood, so please let me raise a new thread to clarify.
> > > > I break down the contents from the guide into a step-by-step
> > > > procedure, and I would appreciate it if you can verify the steps and
> > > > check for the issues.
> > > >
> > > > [Environment]: Tomcat 10.0.27, Ant 1.10.14, Maven 3.6.3, GraalVM EE 
> > > > 21.x+Java17
> > > > [Steps]:
> > > > 1. Download the stuffed folder according to the guide.
> > > > 2. Edit the original pom to align with the Tomcat and JDK version:
> > > > 
> > > > 
> > > > UTF-8
> > > > org.apache.catalina.startup.Tomcat
> > > > 10.0.27
> > > > 
> > > > ..
> > > > 
> > > > org.apache.maven.plugins
> > > > maven-compiler-plugin
> > > > 3.11.0
> > > > 
> > > > 11
> > > > 
> > > >   
> > > > 3.  Copy conf and webapps folders from Tomcat to the stuffed folder.
> > > > 4.  Edit the logging properties(Deleted all Juli-related statements to
> > > > avoid runtime error)
> > > >  handlers = java.util.logging.ConsoleHandler
> > > >  .handlers = java.util.logging.ConsoleHandler
> > > >  .
> > > >  java.util.logging.ConsoleHandler.level = FINE
> > > >  # java.util.logging.ConsoleHandler.formatter =
> > > > org.apache.juli.OneLineFormatter
> > > >  java.util.logging.ConsoleHandler.encoding = UTF-8
> > > > 5.  Build and packaging.
> > > >  mvn package
> > > >  ant -Dwebapp.name=ROOT -f webapp-jspc.ant.xml
> > > >  ant -Dwebapp.name=manager -f webapp-jspc.ant.xml
> > > >  ant -Dwebapp.name=examples -f webapp-jspc.ant.xml
> > > >
> > > > Until here everything was running fine without error. And when I
> > > > executed the next command, error message displayed as below:
> > > > mvn package
> > > > ..
> > > > [INFO] --- maven-compiler-plugin:3.11.0:compile (default-compile) @
> > > > tomcat-stuffed ---
> > > > [INFO] Changes detected - recompiling the module! :source
> > > > [INFO] Compiling 130 source files with javac [debug release 17] to
> > > > target/classes
> > > > [INFO] 
> > > > /home/opc/project/tomcat-native/stuffed/src/main/java/manager/org/apache/jsp/WEB_002dINF/jsp/sessionsList_jsp.java:
> > > > Some input files use unchecked or unsafe operations.
> > > > [INFO] 
> > > > /home/opc/project/tomcat-native/stuffed/src/main/java/manager/org/apache/jsp/WEB_002dINF/jsp/sessionsList_jsp.java:
> > > > Recompile with -Xlint:unchecked for details.
> > > > [INFO] Some messages have been simplified; recompile with
> > > > -Xdiags:verbose to get full output
> > > > [INFO] -
> > > > [ERROR] COMPILATION ERROR :
> > > > [INFO] -
> > > > [ERROR] 
> > > > /home/opc/project/tomcat-native/stuffed/src/main/java/examples/org/apache/jsp/jsp/tagplugin/choose_jsp.java:[162,210]
> > > > cannot access javax.servlet.jsp.tagext.TagSupport
> > > >   class file for javax.servlet.jsp.tagext.TagSupport not found
> > > > [ERROR] 
> > > > /home/opc/project/tomcat-native/stuffed/src/main/java/examples/org/apache/jsp/jsp/tagplugin/choose_jsp.java:[165,35]
> > > > cannot access javax.servlet.jsp.tagext.Tag
> > > >   class file for javax.servlet.jsp.tagext.Tag not found
> > > > ..

Re: Run Tomcat as native image

[Rémy Maucherat]

On Mon, Dec 18, 2023 at 1:28 PM Jun Suzuki  wrote:
>
> Hello all,
>
> I'm now following the guide of
> https://tomcat.apache.org/tomcat-11.0-doc/graal.html to build Tomcat
> into native image.
> The original thread I posted before has become too long to be easily
> understood, so please let me raise a new thread to clarify.
> I break down the contents from the guide into a step-by-step
> procedure, and I would appreciate it if you can verify the steps and
> check for the issues.
>
> [Environment]: Tomcat 10.0.27, Ant 1.10.14, Maven 3.6.3, GraalVM EE 
> 21.x+Java17
> [Steps]:
> 1. Download the stuffed folder according to the guide.
> 2. Edit the original pom to align with the Tomcat and JDK version:
> 
> UTF-8
> org.apache.catalina.startup.Tomcat
> 10.0.27
> 
> ..
> 
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.11.0
> 
> 11
> 
>   
> 3.  Copy conf and webapps folders from Tomcat to the stuffed folder.
> 4.  Edit the logging properties(Deleted all Juli-related statements to
> avoid runtime error)
>  handlers = java.util.logging.ConsoleHandler
>  .handlers = java.util.logging.ConsoleHandler
>  .
>  java.util.logging.ConsoleHandler.level = FINE
>  # java.util.logging.ConsoleHandler.formatter =
> org.apache.juli.OneLineFormatter
>  java.util.logging.ConsoleHandler.encoding = UTF-8
> 5.  Build and packaging.
>  mvn package
>  ant -Dwebapp.name=ROOT -f webapp-jspc.ant.xml
>  ant -Dwebapp.name=manager -f webapp-jspc.ant.xml
>  ant -Dwebapp.name=examples -f webapp-jspc.ant.xml
>
> Until here everything was running fine without error. And when I
> executed the next command, error message displayed as below:
> mvn package
> ..
> [INFO] --- maven-compiler-plugin:3.11.0:compile (default-compile) @
> tomcat-stuffed ---
> [INFO] Changes detected - recompiling the module! :source
> [INFO] Compiling 130 source files with javac [debug release 17] to
> target/classes
> [INFO] 
> /home/opc/project/tomcat-native/stuffed/src/main/java/manager/org/apache/jsp/WEB_002dINF/jsp/sessionsList_jsp.java:
> Some input files use unchecked or unsafe operations.
> [INFO] 
> /home/opc/project/tomcat-native/stuffed/src/main/java/manager/org/apache/jsp/WEB_002dINF/jsp/sessionsList_jsp.java:
> Recompile with -Xlint:unchecked for details.
> [INFO] Some messages have been simplified; recompile with
> -Xdiags:verbose to get full output
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] 
> /home/opc/project/tomcat-native/stuffed/src/main/java/examples/org/apache/jsp/jsp/tagplugin/choose_jsp.java:[162,210]
> cannot access javax.servlet.jsp.tagext.TagSupport
>   class file for javax.servlet.jsp.tagext.TagSupport not found
> [ERROR] 
> /home/opc/project/tomcat-native/stuffed/src/main/java/examples/org/apache/jsp/jsp/tagplugin/choose_jsp.java:[165,35]
> cannot access javax.servlet.jsp.tagext.Tag
>   class file for javax.servlet.jsp.tagext.Tag not found
> ..
>
> Could you please help to indicate what I have missed from the above steps?
> And I would really appreciate it if you could offer some kind of
> step-by-step hands-on examples about how to practice to run Tomcat as
> native image.

This seems unrelated, you are apparently trying to run an EE8 webapp
(the examples from Tomcat 9) on a EE10 container. The package names
for the APIs changed to jakarta.*.

Rémy

>
> Thank you
> Jun
>
> -
> 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: Issues of Ahead of Time compilation support

[Rémy Maucherat]

On Fri, Dec 15, 2023 at 11:54 AM Jun Suzuki  wrote:
>
> Rémy
> Thank you so much for your support.
> May I confirm a little bit further regarding your reply.
>
> 2023年12月15日(金) 17:08 Rémy Maucherat :
> >
> > On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  wrote:
>
> > > (1) Guidance is not so clear about following points:
> > > Should I copy the deployed application(with or without war file?) from
> > > existing Tomcat server webapps directory, to webapps directory of
> > > $TOMCAT_STUFFED?
> > > Should I copy all the files from conf directory of existing Tomcat
> > > server, to conf directory of $TOMCAT_STUFFED?
> >
> > Yes.
> > When building your image, you have to compile all the classes into it.
> > So that means all the classes of the webapp as well. So if you don't
> > copy your webapp for the script to compile, no webapp classes ... Also
> > all the webapp Java classes and JARs will have to be included in the
> > image as well for annotation scanning.
>
> Is it correct that following source from existing Tomcat Server needed
> to be copied into $TOMCAT_STUFFED?
> A.  All files under conf folder (including war file)
> B.  All files under webapps folder
> C.  How about lib folder? Should it also be copied?
> D.  How about java source code(which are not deployed on Tomcat)

The doc is correct, so just use that:
- Copy config files from conf (obvious)
- Webapps go in webapps (unless the host appBase is something else)
And that's it.

> >
> > > (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> > > -Djava.util.logging.config.file=conf/logging.properties -jar
> > > target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> > > errors messages show as below:
> > > ...
> > > Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> > > java.lang.ClassNotFoundException: 
> > > 1catalina.org.apache.juli.AsyncFileHandler
> > > java.lang.ClassNotFoundException: 
> > > 1catalina.org.apache.juli.AsyncFileHandler
> > > at 
> > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> > > at 
> > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> > > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> > > ...
> >
> > Yes, avoid the juli file handlers. There's a jul file handler I think:
> > java.util.logging.FileHandler
>
> I revised the source code by deleting "import java.util.*", and I
> recompiled the java source and copied the war file into
> $TOMCAT_STUFFED.
> However, the error message remains:
> Can't load log handler "1localhost.org.apache.juli.AsyncFileHandler"
> java.lang.ClassNotFoundException: 1localhost.org.apache.juli.AsyncFileHandler
> ...
> Can't load log handler "2localhost.org.apache.juli.AsyncFileHandler"
> java.lang.ClassNotFoundException: 2localhost.org.apache.juli.AsyncFileHandler

Use stuff from java.util.logging instead if juli doesn't work for you.
Or change the pom to add it. Juli makes things more complex with
Graal, so the pom doesn't have it.
As explained in the doc, the pom needs to be edited for needed dependencies.

> ...
> 15-Dec-2023 10:35:47.580 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> web application directory
> [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> [215] ms
> 15-Dec-2023 10:35:47.580 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> web application directory
> [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> [215] ms
> 15-Dec-2023 10:35:47.583 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
> 15-Dec-2023 10:35:47.583 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
>
> Since the error messages are showing as above and the process is
> hanging on there, I could not proceed with the step of the next "maven
> package" unless I open another terminal to run maven command.
> Do you have any idea about how to fix this error?

Well, there's no error there, so it's fine. The process is to generate
reflection metadata for your webapp depending on what it needs, so you
need to write a script that exercises all your paths in your webapp
[that would

Re: 9.0.83 addSslHostConfig JMX Operation Regression (Sample Code Attached)

[Rémy Maucherat]

On Thu, Dec 14, 2023 at 7:54 PM Daniel Skiles
 wrote:
>
> Christ,
> Thanks for the explanation.
>
> The XML-based registration - is that something I would do as a user, or
> something that would be changed on the Tomcat side as part of its release
> bundle?

I fixed MbeansDescriptorsIntrospectionSource to allow multiple
operations with the same name. The fix will be in 9.0.85.

Rémy


> On Thu, Dec 14, 2023 at 10:17 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Daniel,
> >
> > On 12/14/23 09:43, Daniel Skiles wrote:
> > > Do you have any pointers on how to do that using JMX?  So far as I can
> > tell
> > > from what little documentation I can find on the tomcat site, this is how
> > > it's done.
> > >
> > > I'm suspicious that there might be an issue in
> > > Tomcat's MbeansDescriptorsIntrospectionSource.createManagedBean(...)
> > > method.  I'm not familiar with the code, but it appears that there might
> > be
> > > an issue with how that map is constructed.
> >
> > +1
> >
> > The operations map is keyed on method-name which means that overloads
> > are not supported.
> >
> > I suppose it's possible that the introspecter doesn't always get the
> > methods back from the reflection process in exactly the same order, and
> > the last one always wins. This would explain why it sometimes works and
> > sometimes does not work.
> >
> > The best solution would be to explicitly-define this operation in the
> > MBeans XML-based registration. Then no introspection is necessary and we
> > always get the right method.
> >
> > -chris
> >
> > > On Thu, Dec 14, 2023 at 4:25 AM Rémy Maucherat  wrote:
> > >
> > >> On Wed, Dec 13, 2023 at 9:43 PM Daniel Skiles
> > >>  wrote:
> > >>>
> > >>> The object and operation I'm trying to address is Catalina -->
> > >>> ProtocolHandler -->  -->  --> operations -->
> > >> addSslHostConfig.
> > >>>
> > >>> The parameters are an SslHostConfig object and the boolean value
> > "true".
> > >>>
> > >>> The operation is "addSslHostConfig".
> > >>>
> > >>> The code I sent in the previous message works 100% of the time in
> > 9.0.82.
> > >>> In 9.0.83, it works about 50% of the time.  I can always query that the
> > >>> operation exists, but roughly half the time it will fail with a JMX
> > >>> exception saying that the operation does not exist.
> > >>>
> > >>> I am not positive, but I believe the behavior in 9.0.83 might have to
> > do
> > >>> with the fact that the catalina java code now has a one argument and
> > two
> > >>> argument variant of the same method.
> > >>
> > >> I'm pretty sure you got the explanation right. It is very similar to
> > >> using reflection here. You're doing the lookup based on the method
> > >> name, which matches something. However, if you want to avoid an error,
> > >> you also have to check that the arguments match, otherwise you're
> > >> going to randomly pick one of the two methods and fail half the time.
> > >>
> > >> Rémy
> > >>
> > >>> On Wed, Dec 13, 2023 at 10:27 AM Christopher Schultz <
> > >>> ch...@christopherschultz.net> wrote:
> > >>>
> > >>>> Daniel,
> > >>>>
> > >>>> On 12/12/23 19:45, Daniel Skiles wrote:
> > >>>>> I apologize for it being a bit rough - it's what I was using to
> > >>>>> troubleshoot locally.
> > >>>>>
> > >>>>> import static java.util.Objects.nonNull;
> > >>>>>
> > >>>>> import java.lang.management.ManagementFactory;
> > >>>>> import java.util.Arrays;
> > >>>>> import java.util.HashMap;
> > >>>>> import java.util.Map;
> > >>>>> import java.util.Optional;
> > >>>>> import java.util.function.Predicate;
> > >>>>>
> > >>>>> import javax.management.MBeanInfo;
> > >>>>> import javax.management.MBeanOperationInfo;
> > >>>>> import javax.management.MBeanServer;
> > >>>>> import javax.management.ObjectName;
> > >>>>>
> > >>>>> import org.apache.logg

Re: Issues of Ahead of Time compilation support

[Rémy Maucherat]

On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  wrote:
>
> Hello all,
>
> Does anyone have experience of implementation of AOT/GraalVM by
> following official documentation as below?
> https://tomcat.apache.org/tomcat-9.0-doc/graal.html
>
> I created a simple spring framework application(deployed as a war
> file) which is working well under Tomcat10.x, GraalVM21 with JDK21.
> Then I'm trying to transform the application into native image based
> on the documentation.
> I download the Tomcat Stuffed module and started to do packaging and building.
> However, I encountered some issues by following the steps from the
> documentation.
>
> (1) Guidance is not so clear about following points:
> Should I copy the deployed application(with or without war file?) from
> existing Tomcat server webapps directory, to webapps directory of
> $TOMCAT_STUFFED?
> Should I copy all the files from conf directory of existing Tomcat
> server, to conf directory of $TOMCAT_STUFFED?

Yes.
When building your image, you have to compile all the classes into it.
So that means all the classes of the webapp as well. So if you don't
copy your webapp for the script to compile, no webapp classes ... Also
all the webapp Java classes and JARs will have to be included in the
image as well for annotation scanning.

> (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> -Djava.util.logging.config.file=conf/logging.properties -jar
> target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> errors messages show as below:
> ...
> Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
> java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> ...

Yes, avoid the juli file handlers. There's a jul file handler I think:
java.util.logging.FileHandler

> (3) When using JDK17, the first step of maven build failed with following 
> error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile
> (default-compile) on project tomcat-stuffed: Fatal error compiling:
> error: release version 21 not supported.
> After I switched to JDK21, build completed successfully. Is the
> approach only support JDK21?

Yes, if you take the path to stuffed that is mentioned in the docs, it
will be from the "main" Tomcat branch, which means Java 21 (it got
updated since). The module exists on the "10.1.x" branch as well,
where it is Java 11 instead, matching Tomcat 10.1. Don't be afraid to
change the release target and Tomcat version used in the pom.
I'll update the graal.html to at least point to the 10.1.x branch.

Rémy

> Please kindly provide any insights on this.
> Thank you
>
> Jun
>
> -
> 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: 9.0.83 addSslHostConfig JMX Operation Regression (Sample Code Attached)

[Rémy Maucherat]

On Wed, Dec 13, 2023 at 9:43 PM Daniel Skiles
 wrote:
>
> The object and operation I'm trying to address is Catalina -->
> ProtocolHandler -->  -->  --> operations --> addSslHostConfig.
>
> The parameters are an SslHostConfig object and the boolean value "true".
>
> The operation is "addSslHostConfig".
>
> The code I sent in the previous message works 100% of the time in 9.0.82.
> In 9.0.83, it works about 50% of the time.  I can always query that the
> operation exists, but roughly half the time it will fail with a JMX
> exception saying that the operation does not exist.
>
> I am not positive, but I believe the behavior in 9.0.83 might have to do
> with the fact that the catalina java code now has a one argument and two
> argument variant of the same method.

I'm pretty sure you got the explanation right. It is very similar to
using reflection here. You're doing the lookup based on the method
name, which matches something. However, if you want to avoid an error,
you also have to check that the arguments match, otherwise you're
going to randomly pick one of the two methods and fail half the time.

Rémy

> On Wed, Dec 13, 2023 at 10:27 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Daniel,
> >
> > On 12/12/23 19:45, Daniel Skiles wrote:
> > > I apologize for it being a bit rough - it's what I was using to
> > > troubleshoot locally.
> > >
> > > import static java.util.Objects.nonNull;
> > >
> > > import java.lang.management.ManagementFactory;
> > > import java.util.Arrays;
> > > import java.util.HashMap;
> > > import java.util.Map;
> > > import java.util.Optional;
> > > import java.util.function.Predicate;
> > >
> > > import javax.management.MBeanInfo;
> > > import javax.management.MBeanOperationInfo;
> > > import javax.management.MBeanServer;
> > > import javax.management.ObjectName;
> > >
> > > import org.apache.logging.log4j.LogManager;
> > > import org.apache.logging.log4j.Logger;
> > > import org.apache.tomcat.util.net.SSLHostConfig;
> > > import org.apache.tomcat.util.net.SSLHostConfigCertificate;
> > > import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
> > >
> > > @javax.annotation.ManagedBean
> > > public class MbeanFailure {
> > > private static final Logger LOGGER = LogManager.getLogger();
> > >
> > > private static final String LOCALHOST = "127.0.0.1";
> > > private static final String SUBTYPE = "subType";
> > > private static final String ADD_SSL_HOST_CONFIG_OP = "addSslHostConfig";
> > >
> > > private static final Predicate NOT_LOCALHOST =
> > Predicate.not(on
> > > ->
> > >
> > Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(LOCALHOST));
> > > private static final Predicate  NOT_SUBTYPE =
> > Predicate.not(on
> > > ->
> > >
> > Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(SUBTYPE));
> > >
> > > @javax.annotation.PostConstruct
> > > public void run() throws Exception {
> > > final MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> > >
> > > final SSLHostConfig config = new SSLHostConfig();
> > >
> > > config.setProtocols("TLSv1.2");
> > > config.setHostName("test.test.com");
> > > config.setCiphers("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256");
> > >
> > > final SSLHostConfigCertificate cert = new
> > SSLHostConfigCertificate(config,
> > > Type.UNDEFINED);
> > >
> > > config.addCertificate(cert);
> > > final Map references =
> > getObjectReferences(server,
> > > "ProtocolHandler");
> > >
> > > references.forEach((s, op) -> invoke(s, op, ADD_SSL_HOST_CONFIG_OP, new
> > > Object[] {config}, new String[]
> > {SSLHostConfig.class.getCanonicalName()}));
> > > }
> > >
> > > public Map getObjectReferences(final MBeanServer
> > > server, final String discriminator) {
> > >
> > > final  Map results = new HashMap<>();
> > >
> > > final Predicate extendedFilters =
> > > NOT_LOCALHOST.and(NOT_SUBTYPE);
> > >
> > > final Optional candidate = server.queryNames(null,
> > > null).stream()
> > > .filter(on -> nonNull(on.getCanonicalName()))
> > > .filter(on -> on.getCanonicalName().contains(discriminator))
> > > .filter(extendedFilters)
> > > .findAny();
> > >
> > > candidate.ifPresent(on -> results.put(server, on));
> > >
> > > return Map.copyOf(results);
> > > }
> > >
> > > public Object invoke(final MBeanServer server, final ObjectName
> > objectName,
> > > final String method, final Object[] params, final String[] signature) {
> > > try {
> > > //This should return addSslHostConfig(SSLHostConfig, boolean)
> > > final MBeanInfo info = server.getMBeanInfo(objectName);
> > >
> > > final MBeanOperationInfo methodInfo = Arrays.stream(info.getOperations())
> > > .filter(i -> i.getName().equals(method))
> > > .findAny()
> > > .orElseThrow(() -> new RuntimeException("Could not find method  named" +
> > > method));
> > >
> > > LOGGER.error("Found available operation {}", methodInfo);
> > >
> > > final Object result = server.invoke(objectName, method, params,
> > signature);
> > > return result;
> > > } 

[ANN] Apache Tomcat 9.0.84 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.84.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.84 is a bugfix and feature release. The notable
changes compared to 9.0.83 include:

- Background processes for a Container no longer execute while lifecycle
   operations are in progress for that Container.

- Correct unintended escaping of XML in some WebDAV responses.

- Use a 408 status code if a read timeout occurs during HTTP
   HTTP request processing instead of an HTTP 400 status.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.83 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.83.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.83 is a bugfix and feature release. The notable
changes compared to 9.0.82 include:

- Fix reloading TLS configuration could cause the Connector to
   refuse new connections or the JVM to crash.

- Ensure that an IOException during the reading of the request
   always triggers error handling, regardless of whether the
   application swallows the exception.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Testing OpenSSL integration using the FFM API with Tomcat 11 on Windows 10

[Rémy Maucherat]

On Fri, Nov 10, 2023 at 4:27 PM Mark Thomas  wrote:
>
> On 10/11/2023 14:44, Eduardo Guadalupe wrote:
> > Thanks Mark,
> >
> > I found the issue, I assumed OpenSSL was installed because I had seen in
> > some logs the message “OpenSSL successfully initialized [OpenSSL 3.0.11 19
> > Sep 2023].”
>
> That may be the OpenSSL version that is static linked to the Tomcat
> Native library. I don't think you can use that directly.

Most likely it would be AprLifecycleListener, which uses the same
message when it's done with the OpenSSL init. Meh, my bad, although
all messages are completely correct.
I guess it is more likely to happen on Windows, where OpenSSL is not
bundled, but our tomcat-native binary with statically linked OpenSSL
would be on the library path. Then OpenSSLLifecycleListener won't be
able to load OpenSSL, but AprLifecycleListener would.

Rémy

> > I double checked and OpenSSL exe is not available on the PATH.
> >
> > Is there any recommendations on how to install on Windows? O build from
> > source is the best alternative?
>
> I haven't tried this on Windows yet. I've only got as far as noting
> we'll need to think about this for Tomcat 12 if we are going to switch
> to FFM and some initial research.
>
> Based on my initial research I suggest:
> - look on the OpenSSL wiki for binary windows disributions
> - pick one that offers DLLs with no additional dependencies
> - download it
> - put libssl.dll (or whatever it is called) in an appropriate directory
> - ensure that directory is included in java.library.path (use
>setenv.bat)
> - ensure the OpenSSLLifecycleListener is configured in server.xml
> - start Tomcat
>
> HTH,
>
> Mark
>
>
> >
> > On Fri, Nov 10, 2023, 01:48 Mark Thomas  wrote:
> >
> >> On 10/11/2023 00:59, Eduardo Guadalupe wrote:
> >>> Hi,
> >>>
> >>> I wanted to test the OpenSSL integration using the FFM API rather than
> >>> Tomcat Native in Apache Tomcat 11.0.0-M14.
> >>>
> >>> Starting Tomcat is printing an error:
> >>>
> >>>
> >>> Failed to initialize the SSLEngine. java.lang.UnsatisfiedLinkError: no
> >> ssl
> >>> in java.library.path
> >>>
> >>>
> >>> I am running on Windows 10 with openjdk-22-ea+22.
> >>>
> >>> Tomcat downloaded from
> >>>
> >> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M14/bin/apache-tomcat-11.0.0-M14-windows-x64.zip
> >>>
> >>> Is there additional steps/configurations required?
> >>
> >> Which OpenSSL binary did you install and where did you install it?
> >>
> >> 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

[ANN] Apache Tomcat 9.0.82 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.82.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.82 is a bugfix and feature release. The notable
changes compared to 9.0.81 include:

- Correct a regression in 9.0.81 that broke the Tomcat JBDC
   connection pool.

- Correct a regression in 9.0.81 that broke HTTP compression.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.81 Degraded ssl performance

[Rémy Maucherat]

On Fri, Oct 13, 2023 at 9:25 AM Rathore, Rajendra  wrote:
>
> Hi Team,
>
> Can you please share the release plan for 9.0.82 version, as we are planning 
> to update it?

You can get it at the usual place: https://tomcat.apache.org/download-90.cgi

Rémy

>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: i...@flyingfischer.ch 
> Sent: Thursday, October 12, 2023 10:54 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.81 Degraded ssl performance
>
> Am 12.10.23 um 03:01 schrieb Paul Zepernick:
> > Thank you Chuck
> >
> > Paul
> > 
> > From: Chuck Caldarale 
> > Sent: Wednesday, October 11, 2023 8:54:59 PM
> > To: Tomcat Users List 
> > Subject: Re: Tomcat 9.0.81 Degraded ssl performance
> >
> > NOTICE: This email originated from outside of the organization. Do not 
> > click links or open attachments unless you recognize the sender and know 
> > the content is safe.
> >
> >> On Oct 11, 2023, at 19:44, Paul Zepernick  
> >> wrote:
> >>
> >> Tomcat Version: 9.0.81
> >> OS: Windows Server 2016
> >>
> >> We recently patched one of our QA servers to test 9.0.81 and ran into 
> >> performance issues.  Page loads that normally take 1-2 seconds are now 
> >> taking 50-60 seconds.  We were finally able to narrow the issue down to 
> >> the SSL connector.  Adding an HTTP connector and bypassing ssl resolves 
> >> the performance issue.  We have also tested rolling back to 9.0.80 with 
> >> the same configuration and verified the issue does not exist.
> >>
> > This was due to a regression introduced in 9.0.81, as noted here:
> > https://bz.a/
> > pache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D67670=05%7C01%7Crarath
> > ore%40ptc.com%7C1792927bf49742d936b208dbcae3a63e%7Cb9921086ff774d0d828
> > acb3381f678e2%7C0%7C0%7C638326851325327468%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> > %7C%7C%7C=jJCF0r%2F8vUBpRjc04kWHuGrRiOygwANqpVpfBKXQYEo%3D
> > ved=0 > 2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D67670=05%7C01%7C
> > rarathore%40ptc.com%7C1792927bf49742d936b208dbcae3a63e%7Cb9921086ff774
> > d0d828acb3381f678e2%7C0%7C0%7C638326851325483103%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C3000%7C%7C%7C=IHAB3t%2B41LTsxAYh6uwFx7sa7gy%2F7Our4b%2Fj56FELA
> > s%3D=0>
> >
> > The problem has been fixed in 9.0.82 which is currently being voted on; 
> > release will likely occur in another day or two.
> >
> >- Chuck
> >
> > This e-mail, including attachments, may include confidential and/or
> > proprietary information, and may be used only by the person or entity
> > to which it is addressed. If the reader of this e-mail is not the
> > intended recipient or intended recipient's authorized agent, the
> > reader is hereby notified that any dissemination, distribution or
> > copying of this e-mail is prohibited. If you have received this e-mail
> > in error, please notify the sender by replying to this message and delete 
> > this e-mail immediately.
>
> You may also set on the connector as a workaround
>
> compression="off"
>
> This will resolve the issue for the time being without the need to downgrade 
> to an insecure version.
>
>
> Markus
>
>
>
>
> -
> 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: Change in behavior Tomcat 9.0.81

[Rémy Maucherat]

On Wed, Oct 11, 2023 at 11:30 AM i...@flyingfischer.ch
 wrote:
>
> Strange change in behavior, when updating to the latest Tomcat 9.0.81
> version:
>
> Calling static files (.js / .css) from a server running Tomcat 9.0.81
> over httpclient now results in
>
> org.apache.http.ConnectionClosedException: Premature end of
> Content-Length delimited message body (expected: 8’170; received: 1’927)
>
> Downgrading the server running the webapp serving the static files to
> Tomcat 9.0.80 does not show the issue.
>
> Has there been a change that triggers this error, related to the many
> security fixes in 9.0.81?

https://bz.apache.org/bugzilla/show_bug.cgi?id=67670

Rémy

>
> Thanks for considering.
>
> Best regards
> Markus
>
> -
> 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

[ANN] Apache Tomcat 9.0.81 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.81.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.81 is a bugfix and feature release. The notable
changes compared to 9.0.80 include:

- Update Tomcat Native to 1.2.39 to pick up Windows binaries built with
   OpenSSL 3.0.11.

- Provide a lifecycle listener that will automatically reload TLS
   configurations a set time before the certificate is due to expire.
   This is intended to be used with third-party tools that regularly
   renew TLS certificates.

- Improve performance of EL expressions in JSPs that use implicit
   objects.

- Several improvements to thread safety and recycling cleanup.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.79 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.79.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.79 is a bugfix and feature release. The notable
changes compared to 9.0.78 include:

- Refactor HTTP/2 implementation to reduce pinning when using virtual
   threads.

- Pass through ciphers referring to an OpenSSL profile, such as
   PROFILE=SYSTEM instead of producing an error trying to parse it.

- Update Tomcat Native to 2.0.5.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Pinned threads for HTTP2 using Virtual Threads on Tomcat 10.1.7

[Rémy Maucherat]

On Thu, Jul 27, 2023 at 5:04 PM Mark Thomas  wrote:
>
> I've refactored things to the point where the unit tests run without
> generating any warnings for pinning. I suspect further issues will be
> identified over time and we can address those as they are found.

Ok, so the changes for Loom are: sync -> equivalent lock. That's ok
but it's a bit riskier (syncs are hard to avoid releasing).

> Mark
>
>
> On 25/07/2023 10:21, Mark Thomas wrote:
> > Never mind. Pretty much as soon as I hit send I managed to trigger the
> > issue.
> >
> > Mark
> >
> >
> > On 25/07/2023 10:19, Mark Thomas wrote:
> >> Daniel,
> >>
> >> How did you trigger the pinning? I'm running some basic tests with
> >> -Djdk.tracePinnedThreads=short and I'm not seeing any pinned threads
> >> reported.
> >>
> >> Mark
> >>
> >>
> >> On 07/07/2023 13:45, Daniel Andres Pelaez Lopez wrote:
> >>> Mark,
> >>>
> >>> Thanks for letting me know. I will wait for the August release to test.
> >>>
> >>> Regards.
> >>>
> >>>
> >>> El jue, 6 jul 2023 a las 15:13, Mark Thomas ()
> >>> escribió:
> 
> 
>  6 Jul 2023 20:09:01 Daniel Andres Pelaez Lopez :
> 
> > I am aware Tomcat community did a great effort to move Tomat to
> > Virtual Threads friendly, but I am not sure why HTTP2 was not part of
> > that effort?
> 
>  The plan was always to see where the bottlenecks were as folks start to
>  experiment with Loom support and fix issues as they arose. It helps
>  focus
>  effort on where it is really needed.
> 
>  These fixes look fairly simple. We should be able to get them done for
>  the August releases (the July releases have already been tagged). We
>  can
>  make -dev builds available earlier or you can build Tomcat from
>  source to
>  test the changes if you are interested.
> 
>  As it happens I've spent most of today looking at ThreadLocal vs
>  SynchronizedStack vs new Object() in various places in the Tomcat code
>  base without reaching a clear conclusion. Which kind of proves the
>  point
>  that if we guess where bottlenecks might be we'll probably be wrong.
> 
>  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
> >
>
> -
> 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

[ANN] Apache Tomcat 9.0.78 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.78.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.78 is a bugfix and feature release. The notable
changes compared to 9.0.76 include:

- Add ContextNamingInfoListener, a listener which creates context naming
   information environment entries.

- Add PropertiesRoleMappingListener, a listener which populates the
   context's role mapping from a properties file.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RateLimitFilter

[Rémy Maucherat]

On Fri, Jul 7, 2023 at 6:07 PM Peter Eichenauer
 wrote:
>
> Hi,
>
> thank you for adding the RateLimitFilter in Tomcat 9.0.76. It is working
> as expected, but I wonder if the log message during initialisation is
> correct: Actual is [{3}] per [{4}] milliseconds. [{5}].
>
> To me it looks like that parameter {4} is printed in seconds.
>
> For example, this is my web.xml configuration:
> 
> RateLimitFilter
> 
> org.apache.catalina.filters.RateLimitFilter
> 
> bucketDuration
> 10
> 
> 
> bucketRequests
> 10
> 
> 
>
> my log shows:
> [RateLimitFilter] initialized with [10] requests per [10] seconds.
> Actual is [16] per [16] milliseconds.

Ok, it should be seconds instead.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9 returns INameEnvironment error

[Rémy Maucherat]

On Thu, Jun 15, 2023 at 9:54 PM Mark Thomas  wrote:
>
> On 15/06/2023 19:23, Joel Griffith wrote:
> > It looks like the JDT you mention is the Ubuntu package
> > `libeclipse-jdt-core-java`.
> >
> > When I installed Tomcat 9 (9.0.31) on the functioning Ubuntu 20.04 system,
> > version 3.18.0+eclipse4.12-1 of this JDT package was installed as a
> > dependency.  When I installed Tomcat 9 (9.0.58) on the Ubuntu 22.04 system,
> > version 3.27.0+eclipse4.21-1 was installed.  Assuming the "4.12" and "4.21"
> > numbers are the JDT versions you're referring to, it seems like you're
> > right about the cause.
> >
> > According to this table (https://tomcat.apache.org/whichversion.html),
> > Tomcat 9 is supposed to be compatible with Java 8, yet in this case it
> > seems to have broken compatibility on a patch update between 9.0.31 and
> > 9.0.58.  In order to regain compatibility, the dependency on JDT should be
> > adjusted to a lower version.  Is this something the Tomcat people have to
> > handle, or is it the package maintainers at Canonical who make that choice?
>
> That would be Canonical.
>
> If you get Tomcat 9 from the ASF it works out of the box on Java 8. (You
> actually get the reverse issue with really new JDKs and very old JDTs
> but that isn't what is happening here).

JDT seems to be getting more and more aggressive with bumping Java
requirements. For example, Tomcat 10.1 uses Java 11 as the minimum,
but JDT 4.28 is *already* Java 17+. So Tomcat 10.1 will stay on 4.27
forever basically.

Rémy

> Mark
>
>
> >
> > Thanks,
> > Joel
> >
> > On Thu, Jun 15, 2023 at 11:26 AM Rémy Maucherat  wrote:
> >
> >> On Thu, Jun 15, 2023 at 5:17 PM Joel Griffith 
> >> wrote:
> >>>
> >>> I'm setting up a JSP webapp on an Ubuntu 22.04 system.  The webapp uses
> >>> Tomcat 9 proxied through Apache 2, just as described here
> >>> <https://tomcat.apache.org/tomcat-9.0-doc/proxy-howto.html> .  I'm
> >>> recreating a setup that works on an Ubuntu 20.04/Tomcat 9 system, and has
> >>> worked in the past for earlier versions of both Ubuntu and Tomcat.
> >>>
> >>> When I access the page https://localhost/app/foo, I get a 500 Internal
> >>> Server Error.  The error message is
> >>>
> >>> java.lang.UnsupportedClassVersionError:
> >>> org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled
> >> by
> >>> a more recent version of the Java Runtime (class file version 55.0), this
> >>> version of the Java Runtime only recognizes class file versions up to
> >> 52.0
> >>>
> >>> The exception is
> >>>
> >>> javax.servlet.ServletException: java.lang.UnsupportedClassVersionError:
> >>> org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled
> >> by
> >>> a more recent version of the Java Runtime (class file version 55.0), this
> >>> version of the Java Runtime only recognizes class file versions up to
> >> 52.0
> >>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:332)
> >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
> >>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> >>>
> >>> There is no file by any variation of the name `INameEnvironment` in my
> >>> webapp code, and that string does not appear in any file.  I recognize
> >>> Eclipse as a popular IDE, but I don't use it.  The full stack trace
> >> (which
> >>> I can provide if anyone thinks it would be useful) doesn't refer to any
> >>> other file I recognize.
> >>>
> >>> Searching through the Tomcat source code on GitHub, I found the file `
> >>> java/org/apache/jasper/compiler/JDTCompiler.java` that appears to be the
> >>> source of the error.  This link takes you to the code snippet in
> >> question:
> >>>
> >>>
> >> https://github.com/search?q=repo%3Aapache%2Ftomcat%20INameEnvironment=code
> >>>
> >>> Is this a bug?  It seems strange that it affects only one system when
> >> I've
> >>> set up Tomcat 9 on many systems.  Is there something on the Ubuntu 22.04
> >>> system that might cause the bug to be thrown that I can fix?
> >>>
> >>> The Java version on the Ubuntu 22.04 system (localhost) is
> >>> ```
> >>> $ java -version
> >>> openjdk version "1.8.0_362"
> >>>

Re: Tomcat 9 returns INameEnvironment error

[Rémy Maucherat]

On Thu, Jun 15, 2023 at 5:17 PM Joel Griffith  wrote:
>
> I'm setting up a JSP webapp on an Ubuntu 22.04 system.  The webapp uses
> Tomcat 9 proxied through Apache 2, just as described here
>  .  I'm
> recreating a setup that works on an Ubuntu 20.04/Tomcat 9 system, and has
> worked in the past for earlier versions of both Ubuntu and Tomcat.
>
> When I access the page https://localhost/app/foo, I get a 500 Internal
> Server Error.  The error message is
>
> java.lang.UnsupportedClassVersionError:
> org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled by
> a more recent version of the Java Runtime (class file version 55.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0
>
> The exception is
>
> javax.servlet.ServletException: java.lang.UnsupportedClassVersionError:
> org/eclipse/jdt/internal/compiler/env/INameEnvironment has been compiled by
> a more recent version of the Java Runtime (class file version 55.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:332)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
>
> There is no file by any variation of the name `INameEnvironment` in my
> webapp code, and that string does not appear in any file.  I recognize
> Eclipse as a popular IDE, but I don't use it.  The full stack trace (which
> I can provide if anyone thinks it would be useful) doesn't refer to any
> other file I recognize.
>
> Searching through the Tomcat source code on GitHub, I found the file `
> java/org/apache/jasper/compiler/JDTCompiler.java` that appears to be the
> source of the error.  This link takes you to the code snippet in question:
>
> https://github.com/search?q=repo%3Aapache%2Ftomcat%20INameEnvironment=code
>
> Is this a bug?  It seems strange that it affects only one system when I've
> set up Tomcat 9 on many systems.  Is there something on the Ubuntu 22.04
> system that might cause the bug to be thrown that I can fix?
>
> The Java version on the Ubuntu 22.04 system (localhost) is
> ```
> $ java -version
> openjdk version "1.8.0_362"
> OpenJDK Runtime Environment (build 1.8.0_362-8u362-ga-0ubuntu1~22.04-b09)
> OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
> ```
>
> and the Tomcat version is
> ```
> $ java -cp catalina.jar org.apache.catalina.util.ServerInfo
> Server version: Apache Tomcat/9.0.58 (Ubuntu)
> Server built:   Jan 6 1970 15:09:28 UTC
> Server number:  9.0.58.0
> OS Name:Linux
> OS Version: 5.19.0-38-generic
> Architecture:   amd64
> JVM Version:1.8.0_362-8u362-ga-0ubuntu1~22.04-b09
> JVM Vendor: Private Build
> ```
>
> The Java version on the Ubuntu 20.04 server for which the webapp works is
> effectively identical:
> ```
> $ java -version
> openjdk version "1.8.0_362"
> OpenJDK Runtime Environment (build
> 1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09)
> OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
> ```
>
> and its Tomcat version is
> ```
> $ java -cp catalina.jar org.apache.catalina.util.ServerInfo
> Server version: Apache Tomcat/9.0.31 (Ubuntu)
> Server built:   Nov 18 2022 19:07:15 UTC
> Server number:  9.0.31.0
> OS Name:Linux
> OS Version: 5.4.0-150-generic
> Architecture:   amd64
> JVM Version:1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09
> JVM Vendor: Private Build
> ```
>
> Thanks for any help you can give me.

JDT 4.20 (used for compiling generated code from your JSP) would be
the last version which supports Java 8. You seem to be using a newer
version through your distribution, which now requires Java 11.

Rémy

>
> Joel

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 11 Release Date

[Rémy Maucherat]

On Fri, Jun 9, 2023 at 10:38 AM Mark Thomas  wrote:
>
> On 08/06/2023 21:37, William Crowell wrote:
> > Mark,
> >
> > Thank you for your reply.  Any ideas on Tomcat 11 features that will be 
> > included with a final release next year?
>
> Virtual thread support was the the first major new feature and that was
> included in the recent 11.0.0-M7 release. There will probably be more
> loom related changes as it starts being used and bottlenecks are discovered.
>
> We hoped to take advantage of project Panama to simplify OpenSSL
> integration but that looks like it will remain in preview for Java 21.
>
> QUIC is still on the radar but without Panama support it looks unlikely
> that we'll add QUIC support to Tomcat 11.

First item would be: Panama is non preview in Java 22. I really hope so !
Following this, it should become possible to compile with 22 and
target 21 (except for the classes actually using Panama).

Rémy

> The Jakarta spec changes look to be mostly about clarifying grey areas
> and small feature improvements.
>
> Other than that, the best thing to do is follow the change log and if
> there are features you'd like to see, speak up.
>
> Mark#
>
>
> >
> > Regards,
> >
> > William Crowell
> >
> > From: Mark Thomas 
> > Date: Thursday, June 8, 2023 at 4:05 PM
> > To: users@tomcat.apache.org 
> > Subject: Re: Tomcat 11 Release Date
> > On 08/06/2023 19:56, William Crowell wrote:
> >> Good afternoon,
> >>
> >> I know we are in milestone 7 of Apache Tomcat 11, but do any of you know 
> >> when the release date will be for Apache Tomcat 11? It does not have to be 
> >> an exact date, but just a ballpark date.
> >
> > The criteria for a stable release are:
> > - All implemented Jakarta specifications are released
> > - Tomcat has fully implemented all the specifications
> > - Committer judgement
> >
> > Expanding on those, my best guess for the Jakarta EE specs to be
> > released is March. Tomcat follows the Jakarta development pretty closely
> > so I am fairly confident that Tomcat will have fully implemented the
> > relevant Jakarta EE 11 APIs long before the specs are finally released.
> >
> > The committer judgement has changed over the years. Back when the major
> > Tomcat versions had significantly different code bases, we wanted to
> > allow time for bugs to be found before declaring a major release stable.
> > Currently we try and keep the code bases more in-line and are actively
> > looking for opportunities to reduce differences where we can. The major
> > benefit of this is a greater degree of confidence in the code. My best
> > guess in that the committers will declare Tomcat 11 stable a few Tomcat
> > release cycles after the Jakarta EE 11 release.
> >
> > All that adds up to somewhere around June 2024 as a best guess at the
> > moment.
> >
> > HTH,
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> >
> > CAUTION: This email originated from outside of the organization. Do not 
> > click on links or open attachments unless you recognize the sender and know 
> > the content is safe.
> >
> >
> > This e-mail may contain information that is privileged or confidential. If 
> > you are not the intended recipient, please delete the e-mail and any 
> > attachments and notify us immediately.
> >
> >
>
> -
> 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

[ANN] Apache Tomcat 9.0.76 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.76.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.76 is a bugfix and feature release. The notable
changes compared to 9.0.75 include:

- Add support for virtual threads. (Java 21+ only)

- Update HTTP/2 to use the RFC-9218 prioritization scheme.

- Deprecate the xssProtectionEnabled from HttpHeaderSecurityFilter
   and set the default value to false.

- Update Tomcat Native to 2.0.4 which includes binaries for Windows
   built with OpenSSL 3.0.9.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.75 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.75.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.75 is a bugfix and feature release. The notable
changes compared to 9.0.74 include:

- Many improvements to the json access log valve.

- Deprecate support for the HTTP Connector settings
rejectIllegalHeader and allowHostHeaderMismatch.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
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.74 available

[Rémy Maucherat]

On Tue, Apr 18, 2023 at 2:05 PM Maxim Solodovnik  wrote:
>
> from mobile (sorry for typos ;)
>
>
> On Tue, Apr 18, 2023, 18:58 Rémy Maucherat  wrote:
>
> > On Tue, Apr 18, 2023 at 1:49 PM Maxim Solodovnik 
> > wrote:
> > >
> > > Hello,
> > >
> > > For some reason there are no binary artifacts here:
> > > https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.74 :(
> >
> > Please do not use the archive for regular downloads, you should use
> > the cdn instead: https://tomcat.apache.org/download-90.cgi or
> > https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.74/
>
>
> I wasn't aware archived downloads are available via CDN, thanks for the
> pointer!
> I'll update our maven build

Only the up to date build is available in the CDN. The archive has all
older builds but uses the ASF bandwidth (and also needs more time to
sync, it is not a bug).

Rémy

>
> >
> >
> > Rémy
> >
> > >
> > > from mobile (sorry for typos ;)
> > >
> > >
> > > On Tue, Apr 18, 2023, 15:55 Rémy Maucherat  wrote:
> > >
> > > > The Apache Tomcat team announces the immediate availability of Apache
> > > > Tomcat 9.0.74.
> > > >
> > > > Apache Tomcat 9 is an open source software implementation of the Java
> > > > Servlet, JavaServer Pages, Java Unified Expression Language, Java
> > > > WebSocket and JASPIC technologies.
> > > >
> > > > Apache Tomcat 9.0.74 is a bugfix and feature release. The notable
> > > > changes compared to 9.0.73 include:
> > > >
> > > > - Correct a regression in the fix for bug 66442 that meant that streams
> > > >without a response body did not decrement the active stream count
> > > >when completing, leading to
> > > >ERR_HTTP2_SERVER_REFUSED_STREAM for some connections.
> > > >
> > > > - Add an access log valve that uses a json format. Based on pull
> > request
> > > >#539 provided by Thomas Meyer.
> > > >
> > > > - Refactor synchronization blocks locking on SocketWrapper to use
> > > >ReentrantLock to support users wishing to experiment with project
> > Loom.
> > > >
> > > >
> > > > Along with lots of other bug fixes and improvements.
> > > >
> > > > Please refer to the change log for the complete list of changes:
> > > > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html
> > > >
> > > >
> > > > Downloads:
> > > > https://tomcat.apache.org/download-90.cgi
> > > >
> > > > Migration guides from Apache Tomcat 7.x and 8.x:
> > > > https://tomcat.apache.org/migration.html
> > > >
> > > > Enjoy!
> > > >
> > > > - The Apache Tomcat team
> > > >
> > > > -
> > > > 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: [ANN] Apache Tomcat 9.0.74 available

[Rémy Maucherat]

On Tue, Apr 18, 2023 at 1:49 PM Maxim Solodovnik  wrote:
>
> Hello,
>
> For some reason there are no binary artifacts here:
> https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.74 :(

Please do not use the archive for regular downloads, you should use
the cdn instead: https://tomcat.apache.org/download-90.cgi or
https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.74/

Rémy

>
> from mobile (sorry for typos ;)
>
>
> On Tue, Apr 18, 2023, 15:55 Rémy Maucherat  wrote:
>
> > The Apache Tomcat team announces the immediate availability of Apache
> > Tomcat 9.0.74.
> >
> > Apache Tomcat 9 is an open source software implementation of the Java
> > Servlet, JavaServer Pages, Java Unified Expression Language, Java
> > WebSocket and JASPIC technologies.
> >
> > Apache Tomcat 9.0.74 is a bugfix and feature release. The notable
> > changes compared to 9.0.73 include:
> >
> > - Correct a regression in the fix for bug 66442 that meant that streams
> >without a response body did not decrement the active stream count
> >when completing, leading to
> >ERR_HTTP2_SERVER_REFUSED_STREAM for some connections.
> >
> > - Add an access log valve that uses a json format. Based on pull request
> >#539 provided by Thomas Meyer.
> >
> > - Refactor synchronization blocks locking on SocketWrapper to use
> >ReentrantLock to support users wishing to experiment with project Loom.
> >
> >
> > Along with lots of other bug fixes and improvements.
> >
> > Please refer to the change log for the complete list of changes:
> > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html
> >
> >
> > Downloads:
> > https://tomcat.apache.org/download-90.cgi
> >
> > Migration guides from Apache Tomcat 7.x and 8.x:
> > https://tomcat.apache.org/migration.html
> >
> > Enjoy!
> >
> > - The Apache Tomcat team
> >
> > -
> > 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

[ANN] Apache Tomcat 9.0.74 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.74.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.74 is a bugfix and feature release. The notable
changes compared to 9.0.73 include:

- Correct a regression in the fix for bug 66442 that meant that streams
   without a response body did not decrement the active stream count
   when completing, leading to
   ERR_HTTP2_SERVER_REFUSED_STREAM for some connections.

- Add an access log valve that uses a json format. Based on pull request
   #539 provided by Thomas Meyer.

- Refactor synchronization blocks locking on SocketWrapper to use
   ReentrantLock to support users wishing to experiment with project Loom.


Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: java.lang.AbstractMethodError: Receiver class org.apache.tomcat.websocket.server.WsSessionListener does not define or inherit an implementation

[Rémy Maucherat]

On Mon, Mar 20, 2023 at 1:59 PM Harri Pesonen  wrote:
>
> Hello,
>
> I changed:
>
>   *   source code target from Java 8 to Java 11
>   *   Tomcat from 8.5 to 9.0.73
>   *   Java runtime from Java 11 to Java 17
> and now I see extra error in Tomcat log, which did not happen before:

The Servlet API was changed so that in the HttpSessionListener
interface the sessionCreated method is now a "default". So something
is not right in this area after your upgrade.

Rémy

>
> (http-nio-8080-exec-8) (org.apache.catalina.session.StandardSession#tellNew) 
> Session event listener threw exception
> java.lang.AbstractMethodError: Receiver class 
> org.apache.tomcat.websocket.server.WsSessionListener does not define or 
> inherit an implementation of the resolved method 'abstract void 
> sessionCreated(javax.servlet.http.HttpSessionEvent)' of interface 
> javax.servlet.http.HttpSessionListener.
>  at 
> org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:390)
>  at 
> org.apache.catalina.session.StandardSession.setId(StandardSession.java:363)
>  at 
> org.apache.catalina.session.StandardSession.setId(StandardSession.java:342)
>  at 
> org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:763)
>  at 
> org.apache.catalina.connector.Request.doGetSession(Request.java:3008)
>  at 
> org.apache.catalina.connector.Request.getSession(Request.java:2422)
>  at 
> org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:650)
>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:568)
>  at 
> org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1268)
>  at 
> org.jvnet.hk2.internal.MethodInterceptorImpl.internalInvoke(MethodInterceptorImpl.java:85)
>  at 
> org.jvnet.hk2.internal.MethodInterceptorImpl.invoke(MethodInterceptorImpl.java:101)
>  at 
> org.jvnet.hk2.internal.MethodInterceptorInvocationHandler.invoke(MethodInterceptorInvocationHandler.java:39)
>  at 
> jdk.proxy4/jdk.proxy4.$Proxy72.getSession(Unknown Source)
>  at 
> com.sap.cctr.ri.context.AuthenticationFilter.filter(AuthenticationFilter.java:341)
>  at 
> org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:108)
>  at 
> org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:44)
>  at 
> org.glassfish.jersey.process.internal.Stages.process(Stages.java:173)
>  at 
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:248)
>  at 
> org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
>  at 
> org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
>  at 
> org.glassfish.jersey.internal.Errors.process(Errors.java:292)
>  at 
> org.glassfish.jersey.internal.Errors.process(Errors.java:274)
>  at 
> org.glassfish.jersey.internal.Errors.process(Errors.java:244)
>  at 
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
>  at 
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:235)
>  at 
> org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)
>  at 
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
>  at 
> org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)
>  at 
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:358)
>  at 
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:311)
>  at 
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:209)
>  at 
> 

[ANN] Apache Tomcat 9.0.73 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.73.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.73 is a bugfix and feature release. The notable
changes compared to 9.0.72 include:

- Correct a regression introduced in the fix for bug
  66196 that meant that the HTTP headers and/or request line
  could get corrupted (one part overwriting another part) within a single
  request.

- Provide a more appropriate response (501 rather than 400) when rejecting
  an HTTP request using the CONNECT method.

- Add support for txt: and rnd: rewrite map types from mod_rewrite. Based
  on a pull request provided by Dimitrios Soumis.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.72 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.72.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.72 is a bugfix and feature release. The notable
changes compared to 9.0.71 include:

- Add an error report valve that allows redirecting to or proxying from an
  external web server.

- Log basic information for each configured TLS certificate when
  Tomcat starts.

- Add the shared address space specified by RFC 6598 (100.64.0.0/10)
   to the list of trusted proxies for RemoteIPValve/Filter.

- Limit access to the examples web application to localhost by default.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: changes in Tomcat 10 break Spring Boot 3 executable JARs

[Rémy Maucherat]

On Tue, Jan 31, 2023 at 5:14 PM Garret Wilson  wrote:
>
> I'm passing on an issue discussed on Spring Boot GitHub which may not
> have been passed on to you. The main ticket is
> https://github.com/spring-projects/spring-boot/issues/33633 .
>
> Spring Boot 3 executable JARs with Java 17 will break with
> "java.lang.IllegalStateException: zip file closed" when Tomcat 10 tries
> to start. You can see an example stack trace at
> https://github.com/spring-projects/spring-boot/issues/34028 .
>
> Apparently Tomcat 9 used to do a JAR file multi-release check like this:
>
> ```java
> @Override
> public boolean jarFileIsMultiRelease(JarFile jarFile) {
>  try {
>  return ((Boolean)
> isMultiReleaseMethod.invoke(jarFile)).booleanValue();
>  } catch (ReflectiveOperationException | IllegalArgumentException e) {
>  return false;
>  }
> }
> ```
>
> In Tomcat 10.1 it looks like this:
>
> ```java
> multiRelease = jarFile.isMultiRelease();
> ```
>
> I don't know anything about this code (I'm merely passing on what is in
> the ticket), but I can guess that Tomcat wants to get away from
> reflective operations, especially with later Java versions. That's fine
> and probably a good idea. Unfortunately the new code does no error
> handling whatsoever, so that the `IllegalStateException` kills
> everything. If you could at least catch the `IllegalStateException` and
> assume `false` I would imagine that would work around this issue.
>
> The Spring Boot ticket acknowledges that they should improve their
> `JarUrlConnection` so that it wouldn't return a `JarFile` that was
> closed in the first place. Unfortunately there's no indication when that
> would be done, and right now the entire Spring Boot 3 executable JAR
> system is broken, requiring a system property to be added as a workaround.
>
> Would you consider adding more error handling in a Tomcat 10 patch so
> that users to explicitly override the Tomcat 10 version and get their
> Spring Boot 3 executable JARs working again?

After looking at the code (including in Java), it would seem this is a
bug of both Spring (bad jar) and Java (inconsistent API that returns
false on IOE, no javadoc for the possible ISE). However, I prefered
restoring the previous behavior so the ISE is now caught again and
multi release defaults to false in that case.

Rémy

> Thanks,
>
> Garret
>
>
> -
> 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: changes in Tomcat 10 break Spring Boot 3 executable JARs

[Rémy Maucherat]

On Tue, Jan 31, 2023 at 5:14 PM Garret Wilson  wrote:
>
> I'm passing on an issue discussed on Spring Boot GitHub which may not
> have been passed on to you. The main ticket is
> https://github.com/spring-projects/spring-boot/issues/33633 .
>
> Spring Boot 3 executable JARs with Java 17 will break with
> "java.lang.IllegalStateException: zip file closed" when Tomcat 10 tries
> to start. You can see an example stack trace at
> https://github.com/spring-projects/spring-boot/issues/34028 .
>
> Apparently Tomcat 9 used to do a JAR file multi-release check like this:
>
> ```java
> @Override
> public boolean jarFileIsMultiRelease(JarFile jarFile) {
>  try {
>  return ((Boolean)
> isMultiReleaseMethod.invoke(jarFile)).booleanValue();
>  } catch (ReflectiveOperationException | IllegalArgumentException e) {
>  return false;
>  }
> }
> ```
>
> In Tomcat 10.1 it looks like this:
>
> ```java
> multiRelease = jarFile.isMultiRelease();
> ```
>
> I don't know anything about this code (I'm merely passing on what is in
> the ticket), but I can guess that Tomcat wants to get away from
> reflective operations, especially with later Java versions. That's fine
> and probably a good idea. Unfortunately the new code does no error
> handling whatsoever, so that the `IllegalStateException` kills
> everything. If you could at least catch the `IllegalStateException` and
> assume `false` I would imagine that would work around this issue.
>
> The Spring Boot ticket acknowledges that they should improve their
> `JarUrlConnection` so that it wouldn't return a `JarFile` that was
> closed in the first place. Unfortunately there's no indication when that
> would be done, and right now the entire Spring Boot 3 executable JAR
> system is broken, requiring a system property to be added as a workaround.
>
> Would you consider adding more error handling in a Tomcat 10 patch so
> that users to explicitly override the Tomcat 10 version and get their
> Spring Boot 3 executable JARs working again?

The initial version of the compat code already had the try/catch for
the ISE, so it would basically have worked by accident, and the result
of the method is basically not accurate (it could return false for a
multi release JAR - obviously this is not super likely to break
something since those are not that common). This compat code is now
removed since Tomcat 10.1 is Java 11+ so it has the necessary real
API. And we didn't know that the ISE was a problem. Not sure what to
do about that though ...

Rémy

> Thanks,
>
> Garret
>
>
> -
> 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

[ANN] Apache Tomcat 9.0.71 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.71.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.71 is a bugfix and feature release. The notable
changes compared to 9.0.70 include:

- Correct a regression in the refactoring that replaced the use of the
   URL constructors. The regression broke lookups for resources that
   contained one or more characters in their name that required escaping
   when used in a URI path.

- When resetting an HTTP/2 stream because the final response has been
   generated before the request has been fully read, use the HTTP/2 error
   code NO_ERROR so that client does not discard the response. Based on a
   suggestion by Lorenzo Dalla Vecchia.

- Change the default of the org.apache.el.GET_CLASSLOADER_USE_PRIVILEGED
   system property to true unless the EL library is running on Tomcat in
   which case the default remains false as the EL library is already
   called from within a privileged block and skipping the unnecessary
   privileged block improves performance.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Possibilities for fetching config information from Kubernetes

[Rémy Maucherat]

On Tue, Jan 10, 2023 at 3:11 PM Christopher Schultz
 wrote:
>
> Mark,
>
> On 1/10/23 03:22, Mark Thomas wrote:
> > On 09/01/2023 22:17, Christopher Schultz wrote:
> >> All,
> >>
> >> I'm aware that there is a k8s manager for clustering
> >> (CloudMembershipService) but I was wondering if / how that could be
> >> extended in order to provide any other types of automated
> >> configuration information for a Tomcat installation.
> >>
> >> For example, I'd love to be able to deploy a Tomcat node and have it
> >> grab its primary database connection information from k8s.
> >>
> >> I spent like 5 minutes reading through the CloudMembershipService and
> >> KubernetesMembershipProvider classes and it seems to be all bundled
> >> together and very geared toward fetching cluster information.
> >>
> >> It seems that most of the KubernetesMembershipProvider.start method
> >> could be moved into a separate support class which just manages k8s
> >> connection information (e.g. fetching from the environment, building
> >> URLs to various interesting paths, wrapping fethcing-and-JSON-parsing,
> >> etc.) and that could be re-used for a parameter-resolver for XML
> >> config files like we can do for system properties like
> >>
> >> 
> >>
> >> It occurs to be that we should be able to do something like this:
> >>
> >> 
> >>
> >> ... and write a resolver that fetches that value on the fly.
> >> (Hopefully it would cache stuff, so that a dozen different
> >> environmental references don't have to be resolved separately.)
> >
> > Isn't this why ServiceBindingPropertySource was contributed? I only
> > dabble with k8s very occasionally but my understanding is that this is
> > the 'proper' way to pick up config in a k8s environment.
>
> Yeah, I think you are right. I hadn't noticed that class before, and it
> looks like it doesn't interact with k8s (or similar) in any way: it just
> assumes that the orchestration framework has already dropped a cache of
> useful configuration files onto the system before the service is launched.
>
> It looks like the KubernetesMembershipProvider needs to be separate from
> that because it actually has to communicate directly with k8s for, well,
> membership services. It's not just reading configuration values.
>
> So, I guess... nothing to see here!

The KubernetesMembershipProvider is the cleanest way to access the
Kube namespace. Then you can use it to list the pods (as here) or
pretty much anything else. There's a problem though: it needs the
token to connect to the service account (= configuration !) *and*
configure the appropriate permissions in Kube to allow the desired
access (= annoying configuration !). I liked it because once it works
it is predictable and reliable.

DNSMembershipProvider is an equivalent to get the list of pods with
far less configuration. However it uses DNS which is prone to
"issues".

So basically yeah, you would need to write a PropertySource that does
somewhat the connection and json parsing that
KubernetesMembershipProvider does. I don't see how the processing can
be generic for everything that is in the Kube namespace, so it would
allow access to some specific values. The problem then is that
security configuration (in Kube) will still be horrible. But it could
work eventually.

In KubernetesMembershipProvider, the connection with the token to the
service account is generic. The URL used in the Kube namespace is
hardcoded. And the json parsing is obviously specific to processing
the list of (running) pods in the cluster.

Rémy

> Thanks,
> -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

Re: apache-tomcat-9.0.70 >> JNDI look up fails in a different thread context class loader !!

[Rémy Maucherat]

On Tue, Dec 13, 2022 at 9:36 AM dineshk  wrote:
>
>
> Hi Mark,
> I guess you are right , I tried with simple web application and JNDI look up 
> fails in both tomcat 7.x and 9.x if the current thread context class loader 
> is changed but strangely when we deploy our application which uses hibernate 
> (4.3.11) , it does work in tomcat 7.x  but not in 9.x. Not sure what is 
> causing this to work in tomcat 7.x and not in tomcat 9.x.
> Secondly , is this implementation "JNDI binding with context class loader" 
> tomcat specific as it  works in both JBoss EAP and IBM WebSphere , any inputs 
> why JNDI look up works in these application servers and not in tomcat?
> RegardsDinesh

Tomcat only uses the context class loader because it works. The
current thread can also be used, you can write a valve that binds it
using this call:
https://github.com/apache/tomcat/blob/main/java/org/apache/naming/ContextBindings.java#L138
It is used during startup here, as an example:
https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/StandardContext.java#L5740

Rémy

> On Monday, December 12, 2022 at 09:49:50 PM GMT+5:30, Mark Thomas 
>  wrote:
>
>  On 12/12/2022 16:07, dineshk wrote:
> >
> > Hi Mark,
> > We could reproduce this issue very easily with simple java program as well. 
> > Just before doing the JNDI look up , set  any custom class loader in the 
> > current thread as context class loader , this will fail the JNDI look up 
> > where as if we don't set any custom class loader , it works fine.
>
> That is the expected behaviour.
>
> What is curious is how this ever worked for Tomcat 7 given that Tomcat
> has used class loader binding with JNDI look-ups 4.1.x (and possible
> earlier).
>
> If you can provide a simple test case that demonstrates the look-up
> working in Tomcat 7 and failing in Tomcat 9 I'll take a look.
>
> It should be possible to demonstrate the issue with a simple web
> application that defines an environment entry in web.xml and then looks
> it up in a JSP.
>
> Mark
>
>
> > Let me know , if we have any solution for this.
> > RegardsDinesh
> >  On Monday, December 12, 2022 at 07:01:24 PM GMT+5:30, dineshk 
> >  wrote:
> >
> >
> > Hi Mark ,
> > I don't think we should suspect the custom class loader here as its very 
> > old code and works fine across all application servers e.g. IBM WebSphere 
> > and JBoss EAP 7.X. The custom class loader  is required as our java classes 
> > are part of the Database which we need to load and hence required.
> > It works in Tomcat 7.X as well but when we moved to 8.x or 9.x in both it 
> > failed.
> > RegardsDinesh
> >  On Monday, December 12, 2022 at 06:33:56 PM GMT+5:30, Mark Thomas 
> >  wrote:
> >
> >  The JNDI binding code is unchanged (apart from the removal of some
> > deprecated methods) between 7.0.x and 9.0.x (and beyond that range). I
> > think you'll need to do some debugging to figure out exactly why this
> > isn't working but I suspect the custom class loader is at least a part
> > of the reason.
> >
> > There may be better options that using a custom class loader. What are
> > the requirements that mean you need to use one?
> >
> > Mark
> >
> >
> > On 12/12/2022 12:42, dineshk wrote:
> >> Hi ,
> >> We are trying to deploy our application on tomcat 9.0.70. Before the 
> >> hibernate bootstraps in our application , we do change the "Current Thread 
> >> Context Class Loader " in the running thread to our "Custom class loader" 
> >> which is required.
> >> Changing the "Current Thread Context Class Loader "  fails the JNDI look 
> >> up for data source done by hibernate.
> >> if the "Current Thread Context Class Loader "  is not changed than JNDI 
> >> look up works.
> >> We have also deployed the same application with the same configurations on 
> >> apache-tomcat-7.0.57 and it works fine there , no issues with JNDI look up.
> >> We have not faced this issues on IBM WebSphere and JBoss EAP but  
> >> apache-tomcat-7.0.57  onwards.
> >> It will be great help if we could get a solution for this.
> >>
> >> RegardsDinesh
> >
> > -
> > 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: Receiving HTTP (any version but 3 prefered) over UDP

[Rémy Maucherat]

On Fri, Dec 9, 2022 at 10:02 AM Mark Thomas  wrote:
>
> On 08/12/2022 21:55, Aryeh Friedman wrote:
> > I just tried the following command to test if tomcat does in fact listen on 
> > UDP:
> >
> > aryeh@sarek1024% nc -u localhost 8080
> > GET / HTTP/1.1
> >
> >
> > aryeh@sarek1024%
> >
> > Which is nice to see tomcat is listening
>
> That command doesn't do what you think it does.
>
> UDP doesn't work the way you think it does.
>
> Even if Tomcat was listening for UDP packets, HTTP/3 has a completely
> different wire format to HTTP/1.1 and the above wouldn't work.
>
> Tomcat is NOT listening for UDP packets.
>
> Tomcat does not support HTTP/3 or QUIC.
>
> 

According to the roadmap: https://www.openssl.org/roadmap.html
I'll look at it with 3.3, basically.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.70 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.70.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.70 is a bugfix and feature release. The notable
changes compared to 9.0.69 include:

- When an HTTP/2 stream was reset, the current active stream count was
   not reduced. If enough resets occurred on a connection, the current
   active stream count limit was reached and no new streams could be
   created on that connection.

- Update to Commons Daemon 1.3.3.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat version retirement plan

[Rémy Maucherat]

Hi,

On Thu, Nov 24, 2022 at 10:54 AM Rathore, Rajendra  wrote:
>
> Hi Team,
>
> Can you please share the timeline for retiring the individual tomcat release ?
>
> Tomcat retirement plan date(tentative)
> 8.5.x
> 9.x.x
> 10.0.x
> 10.1.x
>
> Based on above table we will plan which tomcat is long term supported so that 
> we can use it for our software.

The current plan for present and future branches is here:
https://apachecon.com/acna2022/slides/03_MAUCHERAT_NEW.pdf

Rémy

>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Why does LockOutRealm not support CredentialHandler?

[Rémy Maucherat]

On Thu, Nov 17, 2022 at 11:22 AM Mark Thomas  wrote:
>
> On 17/11/2022 10:07, Rémy Maucherat wrote:
> > On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz
>
> 
>
> >> I guess we could add a configuration option to CombinedRealm:
> >>
> >>  inheritCredentialHandler="first|last|numeric-position|false/off/no"
> >>
> >> ?
> >>
> >> Then you'd only have to declare it once and then you have the
> >> flexibility of inheriting it or not. But you'd have to opt-into it
> >> instead of getting a surprise.
> >
> > Right now the feature is simply too weird, so I'll simply improve it:
> > - It doesn't work if this is a CombinedRealm, so since they are now
> > used all the time this is rather annoying.
> > - For some reason it only sets the attribute if the Realm is on the
> > Context. For example it will not set anything if the realm is on the
> > Host.
> >
> > So instead, I will make these changes:
> > - CombinedRealm will get its own special credential handler if none is
> > set (it will behave like the nested credential handler, except on
> > nested realm.getCredentialHandler()).
> > - In StandardContext, the attribute will be set based on getRealm()
> > instead of getRealmInternal().
>
> I don't think we do that as it creates a security concern. An untrusted
> application would be able to brute force a Realm it hasn't defined.
>
> A trusted app can obtain a reference to the Realm via other means.
>
> I know untrusted apps are rare and becoming rarer but at long as we have
> to support the SecurityManager (hopefully not for much longer) then we
> have to consider untrusted apps.

Ok, I (kind of) understand, and I will remove that part of the change then.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Why does LockOutRealm not support CredentialHandler?

[Rémy Maucherat]

On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> On 11/16/22 07:53, Rémy Maucherat wrote:
> > On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz
> >  wrote:
> >>
> >> Thorsten,
> >>
> >> On 11/16/22 03:20, Thorsten Schöning wrote:
> >>> Guten Tag Christopher Schultz,
> >>> am Mittwoch, 16. November 2022 um 04:50 schrieben Sie:
> >>>
> >>>>  >>>> resourceName="UserDatabase">
> >>>>  >>>> className="org.apache.catalina.realm.SecretKeyCredentialHandler"
> >>>>algorithm="PBKDF2WithHmacSHA512"
> >>>>iterations="10"
> >>>>keyLength="256"
> >>>>saltLength="16"
> >>>> 
> >>>
> >>> That worked right from the start, I had a DIGEST in tomcat-users.xml
> >>> and was able to login with plain-text password provided to the
> >>> browser.
> >>
> >> The use of the word "digest" is overloaded, particularly for this
> >> discussion. Please try to use "HTTP DIGEST" when you mean the
> >> on-the-wire authentication protocol and "hashed credential" when you
> >> mean the stuff you drop into an authentication database. It will make
> >> things a lot easier to understand for all parties involved.
> >>
> >>>> 
> >>>> ...
> >>>> 
> >>>
> >>> Adding that didn't work, I was only able to login with providing the
> >>> DIGEST of tomcat-users.xml as password to the browser, which actually
> >>> made it a plain-text password at the server. The following fit as well
> >>> to what I recognized:
> >>>
> >>> https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm
> >>>
> >>> BUT: I gave things an additional try now and especially after the
> >>> discussion about auth-method BASIC vs. DIGEST and login DOES work now!
> >>
> >> So both the UserDatabase realm and the LockOutRealm as I suggested above
> >> are now working as expected?
> >>
> >>> I most likely not only added LockOutRealm at some point, but switched
> >>> from BASIC auth to DIGEST as well, because I've read that in the CIS
> >>> spec I worked with. That combination can't work and at some point I
> >>> most likely became frustrated and changed DIGEST back to BASIC, while
> >>> having changed other aspects of the realms already or might have
> >>> simply forgotten to change passwords vs. digests in tomcat-users.xml
> >>> or whatever.
> >>>
> >>> So, I guess the reason for the warnign about an ignored credential
> >>> helper in LockOutRealm simply is because it doesn't handle credentials
> >>> at all? And as LockOutRealm forwards actual login to its children
> >>> THEIR assigned credential handlers are properly taken into account?
> >>
> >> Yes, no CombinedRealm ever uses its configured CredentialHandler, which
> >> is why the warning is shown.
> >>
> >> There is a very specific case in which you WANT to configure a
> >> CredentialHandler for a CombinedRealm, and that's when your application
> >> is using the CredentialHandler directy for certain things. That doesn't
> >> seem to be your use-case, so I won't detail that, here. If you re-visit
> >> the SO question you posted yesterday, you'll see that I posted an Answer
> >> which describes that a little more.
> >>
> >>> So whatever the SO-guy sees, might have a different root cause, as it
> >>> was the case for me.
> >>>
> >>> Thanks for triggering me to try again! Might have been to late already
> >>> at Monday as well. :-)
> >>
> >> I'm glad it's working.
> >>
> >> After reading Rémy's initial response, I was thinking that something
> >> needed to be done, but there is no problem IMO. If you need a
> >> CredentialHandler in your application, you can still use LockOutRealm
> >> (or any other CombinedRealm); you just have to specify a
> >> CredentialHandler to use on that outer Realm and all is well.
> >>
> >> And you have to ignore that warning.
> >
> > Su

Re: Why does LockOutRealm not support CredentialHandler?

[Rémy Maucherat]

On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz
 wrote:
>
> Thorsten,
>
> On 11/16/22 03:20, Thorsten Schöning wrote:
> > Guten Tag Christopher Schultz,
> > am Mittwoch, 16. November 2022 um 04:50 schrieben Sie:
> >
> >>  >> resourceName="UserDatabase">
> >>  >> className="org.apache.catalina.realm.SecretKeyCredentialHandler"
> >>   algorithm="PBKDF2WithHmacSHA512"
> >>   iterations="10"
> >>   keyLength="256"
> >>   saltLength="16"
> >> 
> >
> > That worked right from the start, I had a DIGEST in tomcat-users.xml
> > and was able to login with plain-text password provided to the
> > browser.
>
> The use of the word "digest" is overloaded, particularly for this
> discussion. Please try to use "HTTP DIGEST" when you mean the
> on-the-wire authentication protocol and "hashed credential" when you
> mean the stuff you drop into an authentication database. It will make
> things a lot easier to understand for all parties involved.
>
> >> 
> >> ...
> >> 
> >
> > Adding that didn't work, I was only able to login with providing the
> > DIGEST of tomcat-users.xml as password to the browser, which actually
> > made it a plain-text password at the server. The following fit as well
> > to what I recognized:
> >
> > https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm
> >
> > BUT: I gave things an additional try now and especially after the
> > discussion about auth-method BASIC vs. DIGEST and login DOES work now!
>
> So both the UserDatabase realm and the LockOutRealm as I suggested above
> are now working as expected?
>
> > I most likely not only added LockOutRealm at some point, but switched
> > from BASIC auth to DIGEST as well, because I've read that in the CIS
> > spec I worked with. That combination can't work and at some point I
> > most likely became frustrated and changed DIGEST back to BASIC, while
> > having changed other aspects of the realms already or might have
> > simply forgotten to change passwords vs. digests in tomcat-users.xml
> > or whatever.
> >
> > So, I guess the reason for the warnign about an ignored credential
> > helper in LockOutRealm simply is because it doesn't handle credentials
> > at all? And as LockOutRealm forwards actual login to its children
> > THEIR assigned credential handlers are properly taken into account?
>
> Yes, no CombinedRealm ever uses its configured CredentialHandler, which
> is why the warning is shown.
>
> There is a very specific case in which you WANT to configure a
> CredentialHandler for a CombinedRealm, and that's when your application
> is using the CredentialHandler directy for certain things. That doesn't
> seem to be your use-case, so I won't detail that, here. If you re-visit
> the SO question you posted yesterday, you'll see that I posted an Answer
> which describes that a little more.
>
> > So whatever the SO-guy sees, might have a different root cause, as it
> > was the case for me.
> >
> > Thanks for triggering me to try again! Might have been to late already
> > at Monday as well. :-)
>
> I'm glad it's working.
>
> After reading Rémy's initial response, I was thinking that something
> needed to be done, but there is no problem IMO. If you need a
> CredentialHandler in your application, you can still use LockOutRealm
> (or any other CombinedRealm); you just have to specify a
> CredentialHandler to use on that outer Realm and all is well.
>
> And you have to ignore that warning.

Sure, but I plan to try something a little better because why not.

Rémy

> I really don't know why you are seeing that warning. You aren't
> explicitly-setting a CredentialHandler on your LockOutRealm and that's
> the only time this warning should be shown. When
> CombinedRealm.startInternal runs, it creates a trivial CredentialHandler
> (I'm not sure why it does that, actually) but only if the reference is
> null and then it sets the class member directly instead of calling
> setCredentialHandler.
>
> So I'm still a little confused as to why you are seeing what you are seeing.
>
> -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

Re: Why does LockOutRealm not support CredentialHandler?

[Rémy Maucherat]

On Tue, Nov 15, 2022 at 11:11 AM Thorsten Schöning
 wrote:
>
> Hi everyone,
>
> I have some webapp hosted by Tomcat and need to restrict user access
> to some part of that. One additional requirement is that this app
> needs to be CIS benchmark compliant and that requires to use
> LockOutRealm and restricts to store plain-text passwords. Therefore,
> the ultimate solution in my case would be the following:
>
> > 
> >> resourceName="UserDatabase">
> >  > className="org.apache.catalina.realm.SecretKeyCredentialHandler"
> > algorithm="PBKDF2WithHmacSHA512"
> > iterations="10"
> > keyLength="256"
> > saltLength="16"
> > />
> >   
> > 
>
> But that doesn't work, because LockOutRealm ignores any credential
> handler. Additionally, with my used Tomcat 10, I'm unable to set any
> "digest" attribute on the realm itself anymore as well. The only way
> to fulfill both requirements is to implement a custom realm.
>
> > Nov 14, 2022 9:03:48 PM org.apache.catalina.realm.CombinedRealm 
> > setCredentialHandler
> > WARNUNG: A CredentialHandler was set on an instance of the
> > CombinedRealm (or a sub-class of CombinedRealm). CombinedRealm
> > doesn't use a configured CredentialHandler. Is this a configuration
> > error?
>
> https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/LocalStrings.properties#L23
> https://github.com/apache/tomcat/blob/1e8ed80849f2766d3c5b27e09ef53029e1a1a88e/java/org/apache/catalina/realm/CombinedRealm.java#L466
> https://tomcat.apache.org/tomcat-9.0-doc/changelog.html
> https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm
>
> So, what's the reason of not supporting credential handlers for
> LockOutRealm?
>
> Doesn't make too much sense to me, especially as most docs I came
> across use LockOutRealm in combination with some other realm and
> there's no docs that a fundamental concept like credential helpers
> won't work at all in this setup. Additionally, when researching about
> that task, some people even claim that the above XML config works, but
> it simply can't. I don't see any code in LockOutRealm to ask other
> realms about their credential handlers.
>
> I've had a look at the bugtracker already and couldn't find this topic
> discussed or a reason for the implementation. OTOH, someone did add
> some code to explicitly log a warning message instead of fixing the
> underlying problem.
>
> Is the problem really to decide which of the child realms to choose
> for its credential handler to use? In the easiest case simply use the
> first credential handler found with a depth-first search, that should
> work for the majority of use-cases. Other aspects of the config like
> default assumed nesting level of realms and stuff seem hard-coded as
> well.
>
> Would be glad to read some thoughts, as I need to decide how to deal
> with this limitation right now. Thanks!

Ok, this is a bit confusing. Everything is configured properly if you
nest the CredentialHandler on the right realm (the UserDatabaseRealm).
However, the CredentialHandler exposed by
getAttribute(Globals.CREDENTIAL_HANDLER) is always the
CredentialHandler from the realm attached to the context, here it is
LockOutRealm, which isn't very useful.

Maybe NestedCredentialHandler could be used to construct a
CredentialHandler that could be useful to the application, but this
needs more thought.

Rémy

>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   +49 5151-  9468- 0
> Tel:   +49 5151-  9468-55
> Mobil: +49  178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
>
> Telefon: +49 5151 9468-55
> Fax:
> E-Mail: tschoen...@am-soft.de
>
> AM-Soft IT-Service - Bitstore Hameln GmbH
> Brandenburger Straße 7c
> 31789 Hameln
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen 
> und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf 
> diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie 
> nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, 
> informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. 
> Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen 
> jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das 
> Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte 
> Information untersagt.
>
> This e-mail may contain 

[ANN] Apache Tomcat 9.0.69 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.69.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.69 is a bugfix and feature release. The notable
changes compared to 9.0.68 include:

- Fix concurrency issue in evaluation of expression language containing
   lambda expressions.

- Correct the date format used with the expires attribute of HTTP
   cookies. A single space rather than a single dash should be used to
   separate the day, month and year components to be compliant with RFC
   6265.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
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.67 available

[Rémy Maucherat]

On Thu, Sep 29, 2022 at 10:06 AM Greg Huber  wrote:
>
> Hello,
>
> I am testing this release and are getting lots of these type of random
> errors :
>
> <%@include file="../widgets/lazyload.jsp" %>
>
>
> Caused by: org.apache.jasper.JasperException:
> /WEB-INF/jsps/core/listMe.jsp (line: [91], column: [2]) JSP file
> [../widgets/lazyload.jsp] not found
>
> at
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:41)
>  at
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:292)
>  at
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:98)
>  at
> org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:349)
>  at
> org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:384)
>  at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:485)
>  at
> org.apache.jasper.compiler.Parser.parseFileDirectives(Parser.java:1802)
>  at org.apache.jasper.compiler.Parser.parse(Parser.java:141)
>  at
> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:245)
>  at
> org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
>  at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:202)
>  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:391)
>  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:367)
>  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
>  at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:605)
>  at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
>  at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
>  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:779)
>  at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
>  at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>  at
> org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:64)
>  at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>  at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>  at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:711)
>  at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:578)
>  at
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:517)
>  at
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:994)
>  at
> org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:485)
>  at
> org.apache.tiles.request.jsp.JspRequest.doInclude(JspRequest.java:123)
>  ... 213 more
>
> If I go back to 9.0.65 everything is ok.
>
> Have there been any changes?

https://bz.apache.org/bugzilla/show_bug.cgi?id=66277
Discovered shortly after the release announcement. It is expected
there will be a .68 release with the fix next week.

Rémy

> Cheers Greg
>
>
> -
> 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

[ANN] Apache Tomcat 9.0.67 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.67.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.67 is a bugfix and feature release. The notable
changes compared to 9.0.65 include:

- Add support for authenticating WebSocket clients with an HTTP forward
   proxy when establishing a connection to a WebSocket endpoint via a
   forward proxy that requires authentication. Based on a patch provided
   by Joe Mokos.

- Various fixes for edge case bugs in EL processing.

- Improve host header handling for HTTP/2 requests.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [ANN] New committer: Han Li

[Rémy Maucherat]

On Tue, Sep 6, 2022 at 9:39 AM Mark Thomas  wrote:
>
> On behalf of the Tomcat committers I am delighted to announce that
> Han Li (lihan) has been voted in as a new Tomcat committer.
>
> Please join me in congratulating Han.

Welcome ! :)

Remy

> Kind regards,
>
> 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

[ANN] Apache Tomcat 9.0.65 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.65.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.65 is a bugfix and feature release. The notable
changes compared to 9.0.64 include:

- Implement support for repeatable builds.

- Update the packaged version of the Tomcat Native Library to 1.2.35.
   This includes Windows binaries built with OpenSSL 1.1.1q.

- Fix CVE-2022-34305, a low severity XSS vulnerability in the Form
   authentication example.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: State of the Cat 2022

[Rémy Maucherat]

On Thu, Jun 30, 2022 at 6:41 PM Christopher Schultz
 wrote:
>
> Rémy, all,
>
> On 6/28/22 09:58, Rémy Maucherat wrote:
> > On Tue, Jun 28, 2022 at 3:38 PM Christopher Schultz
> >  wrote:
> >>
> >> Rémy,
> >>
> >> On 6/28/22 05:33, Rémy Maucherat wrote:
> >>> On Mon, Jun 27, 2022 at 11:37 PM Christopher Schultz
> >>>  wrote:
> >>>>
> >>>> Cathy,
> >>>>
> >>>> On 6/27/22 15:01, Cathy Spears wrote:
> >>>>> Wondering if there will be a State of the cat 2022.
> >>>>
> >>>> Rémy is scheduled to give a talked called "[Tomcat:] New and Upcoming"
> >>>> at ApacheCon North America in October. I would imagine it would be very
> >>>> similar to State of the Cat though perhaps without any retrospective 
> >>>> info.
> >>>
> >>> I'll integrate a lot of the content from the state of the cat, since
> >>> Mark is not coming this time.
> >>>
> >>> BTW, when is the full conference schedule going to be out ?
> >>
> >> When all of the "your presentation has been accepted" messages went out,
> >> there were a FLOOD of requests for specific times, specific days, etc.
> >> and so the folks working on the schedule (mostly Brian Proffitt, I
> >> think) are losing their minds trying to figure it all out.
> >>
> >> I'm not sure what their target date is for having the schedule complete,
> >> but they are "working on it."
> >
> > Makes sense. Since the Tomcat track is only one day, I'm not planning
> > on staying a full week. So have to wait for the schedule now.
>
> Looks like it's up:
>
> https://www.apachecon.com/acna2022/schedule.html
>
> Unfortunately, there is no overarching schedule or anything on there,
> yet. Just a huge list of presentations and their date/times.
>
> It looks like the Tomcat Track is on Wednesday 5 October. You are
> first-thing in the morning.

Awesome. So indeed it's a bit hard to read, but I have the info I need.

Many thanks !

Rémy

> -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

Re: State of the Cat 2022

[Rémy Maucherat]

On Tue, Jun 28, 2022 at 3:38 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> On 6/28/22 05:33, Rémy Maucherat wrote:
> > On Mon, Jun 27, 2022 at 11:37 PM Christopher Schultz
> >  wrote:
> >>
> >> Cathy,
> >>
> >> On 6/27/22 15:01, Cathy Spears wrote:
> >>> Wondering if there will be a State of the cat 2022.
> >>
> >> Rémy is scheduled to give a talked called "[Tomcat:] New and Upcoming"
> >> at ApacheCon North America in October. I would imagine it would be very
> >> similar to State of the Cat though perhaps without any retrospective info.
> >
> > I'll integrate a lot of the content from the state of the cat, since
> > Mark is not coming this time.
> >
> > BTW, when is the full conference schedule going to be out ?
>
> When all of the "your presentation has been accepted" messages went out,
> there were a FLOOD of requests for specific times, specific days, etc.
> and so the folks working on the schedule (mostly Brian Proffitt, I
> think) are losing their minds trying to figure it all out.
>
> I'm not sure what their target date is for having the schedule complete,
> but they are "working on it."

Makes sense. Since the Tomcat track is only one day, I'm not planning
on staying a full week. So have to wait for the schedule now.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: State of the Cat 2022

[Rémy Maucherat]

On Mon, Jun 27, 2022 at 11:37 PM Christopher Schultz
 wrote:
>
> Cathy,
>
> On 6/27/22 15:01, Cathy Spears wrote:
> > Wondering if there will be a State of the cat 2022.
>
> Rémy is scheduled to give a talked called "[Tomcat:] New and Upcoming"
> at ApacheCon North America in October. I would imagine it would be very
> similar to State of the Cat though perhaps without any retrospective info.

I'll integrate a lot of the content from the state of the cat, since
Mark is not coming this time.

BTW, when is the full conference schedule going to be out ?

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.64 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.64.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.64 is a bugfix and feature release. The notable
changes compared to 9.0.63 include:

- Correct a regression in the support added for encrypted PKCS#1
   formatted private keys in the previous release that broke support
   for unencrypted PKCS#1 formatted private keys.

- Increase the default buffer size for cluster messages from 43800
   to 65536 bytes. This is expected to improve performance for large
   messages when running on Linux based systems.

- When using TLS with non-blocking writes and the NIO connector,
   ensure that flushing the buffers attempts to empty all of the
   output buffers.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.63 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.63.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.63 is a bugfix and feature release. The notable
changes compared to 9.0.62 include:

- Provide a property source that sources values from Kubernetes service
   bindings. Provided by Sumit Kulhadia and Gareth Evans.

- The root cause of the Linux kernel duplicate accept bug has been
   identified along with the version of the kernel that includes the fix.
   The error message displayed when this bug occurs has been updated to
   reflect this new information and to advise users to update to a
   version of the OS that uses kernel 5.10 or later. Thanks to
   Christopher Gual for the research into this issue.

- Update the packaged version of the Tomcat Native Library to 1.2.33 to
   pick up Windows binaries built with OpenSSL 1.1.1o.

- Add support for encrypted PKCS#1 formatted private keys when configuring
   the internal, in memory key store.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 9.0.60 fix question

[Rémy Maucherat]

On Thu, Apr 7, 2022 at 8:41 PM Robert Hicks  wrote:
>
>- [image: Fix:] Fix potential thread-safety issue that could cause
>HTTP/1.1 request processing to wait, and potentially timeout, waiting for
>additional data when the full request has been received. (markt)
>
>
> What would that actually look like? Tomcat spinning its gears and not
> serving anything?

It would supposedly timeout (then close) that single connection where
the issue occurred and that's it.

Rémy

> Thanks,
>
> Bob

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: PostConstruct annotation in a filter since version 9.0.60

[Rémy Maucherat]

On Tue, Apr 5, 2022 at 4:02 PM Cherio  wrote:
>
> Yes, I confirm. For this project I download Tomcat from here:
> https://archive.apache.org/dist/tomcat/tomcat-$MAJOR_VER/v$VER/bin/apache-tomcat-$VER.tar.gz
>
> BTW @PostConstruct doesn't have to do with dependency injection. It is
> about lifecycle processing.
>
> The change in behavior was narrowed down to switching versions from 9.0.59
> to 9.0.60.

Thanks to the effort to isolate the problem, but this is not likely:
https://github.com/apache/tomcat/compare/9.0.59...9.0.60
No relevant changes, so Tomcat's annotation scanning behavior won't change.

The DefaultInstanceManager is used, it seems it wasn't used before
then. Since you're using Spring, maybe the problem could come from
there ?

>
> The code that adds the filter is super simple:
>
> FilterRegistration.Dynamic filterName =
> servletContext.addFilter(FILTER_NAME, filterObject);
> sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST),
> true, "/*");
>
> The filter is a Spring an annotated class. in version 9.0.59 and
> before @PostConstruct was only handled by Spring. Starting with version
> 9.0.60, Tomcat attempts to handle PostConstruct. It produces an exception
> (see below) and fails to start the application.
>
> 12:34:56.789 ERROR o.a.c.c.C.[.[.[/project-name]  - Exception starting
> filter [filterName]
> java.lang.IllegalArgumentException: Invalid javax.annotation.PostConstruct

Is the error message accurate (= is the annotation target funny ?). I
understand that this is supposedly not Tomcat that should process the
annotation (if you say so), but PostConstruct is from EE so there's
likely a problem. Maybe it "used to work" but maybe that's a good hint
too.

Rémy

> annotation
> at
> org.apache.catalina.core.DefaultInstanceManager.findLifecycleCallback(DefaultInstanceManager.java:719)
> at
> org.apache.catalina.core.DefaultInstanceManager.findPostConstruct(DefaultInstanceManager.java:693)
> at
> org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCache(DefaultInstanceManager.java:370)
> at
> org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:172)
> at
> org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:165)
> at
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:105)
> at
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4613)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
>
>
> On Sun, Apr 3, 2022 at 9:54 AM Peter Rader  wrote:
>
> > PostConstruct is for dependency-injection. A 

[ANN] Apache Tomcat 9.0.62 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.62.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.62 is a bugfix and feature release. The notable
changes compared to 9.0.60 include:

- Update the packaged version of the Tomcat Native Library to 1.2.32 to
   pick up Windows binaries built with OpenSSL 1.1.1n.

- Improve logging of unknown HTTP/2 settings frames. Pull request by
   Thomas Hoffmann.

- Add additional warnings if incompatible TLS configurations are used
   such as HTTP/2 with CLIENT-CERT authentication

- Harden the class loader to provide a mitigation for CVE-2022-22965
   a Spring Framework vulnerability

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unknown http2 settings is logged with wrong settings key

[Rémy Maucherat]

On Wed, Mar 23, 2022 at 8:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Christopher Schultz 
> > Gesendet: Mittwoch, 23. März 2022 16:56
> > An: users@tomcat.apache.org
> > Betreff: Re: Unknown http2 settings is logged with wrong settings key
> >
> > Thomas,
> >
> > On 3/23/22 10:13, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > > Hello,
> > >
> > > I got some warnings logged from http2 protocol and the logged values
> > seem to be wrong.
> > > If an unknown http2 settings is received, it logs the key and the value to
> > the logfile:
> > >
> > > /org/apache/coyote/http2/ConnectionSettingsBase.java, line 90:
> > >
> > >  case UNKNOWN:
> > >  // Unrecognised. Ignore it.
> > >  log.warn(sm.getString("connectionSettings.unknown",
> > >  connectionId, setting, Long.toString(value)));
> > >  return;
> > >
> > > The value of the settings-variable was unfortunately converted before
> > > to Integer.MAX_VALUE within the settings.java
> > >
> > > enum Setting {
> > >  HEADER_TABLE_SIZE(1),
> > >  ENABLE_PUSH(2),
> > >  MAX_CONCURRENT_STREAMS(3),
> > >  INITIAL_WINDOW_SIZE(4),
> > >  MAX_FRAME_SIZE(5),
> > >  MAX_HEADER_LIST_SIZE(6),
> > >  UNKNOWN(Integer.MAX_VALUE);
> > >
> > > Thus, the logfile doesn’t contain the received, unknown settings-key but
> > MAX_VALUE instead.
> > >
> > > Is it possible to log the real settings key, which was received by the 
> > > server?
> > > Maybe the logging can be moved to the Setting.java instead or the real
> > > key value would have to be transferred to the function which logs(?)
> >
> > I think the existing log can probably just be fixed, no? Want to take a 
> > stab at
> > writing a PR for this?
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Hello Chris,
>
> I forked tomcat and commited/pushed a change.
> Somehow I got lost with the pull request. I haven’t created one yet because I 
> committed one file which shouldn’t be contained in the commit.
> But somehow the commit was already authored (?)
> Not sure if I messed up something up to now.
>
> Can I create a pull request even if one file (gitignore) was accidentally 
> contained in the commit?
> How can my push already be authored before any pull request?
> https://github.com/HoffmannTom/tomcat/commit/6da6f9444192a1ca1d8d0eda1c6694b7c12451ef

In your patch, you are still logging Setting.UNKNOWN:
Setting key = Setting.valueOf(id);
if (log.isDebugEnabled() && key == Setting.UNKNOWN) {
log.warn(sm.getString("connectionSettings.unknown",
connectionId, key, Long.toString(value)));
}

Instead, you should be logging the original id:
log.warn(sm.getString("connectionSettings.unknown",
connectionId, Integer.toString(id),
Long.toString(value)));

Rémy

> Could you help me out how to continue?
> If my change is a mess, then you can tell me and I skip the pull request.
>
> Thanks! Thomas
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unknown http2 settings is logged with wrong settings key

[Rémy Maucherat]

On Wed, Mar 23, 2022 at 8:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Christopher Schultz 
> > Gesendet: Mittwoch, 23. März 2022 16:56
> > An: users@tomcat.apache.org
> > Betreff: Re: Unknown http2 settings is logged with wrong settings key
> >
> > Thomas,
> >
> > On 3/23/22 10:13, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > > Hello,
> > >
> > > I got some warnings logged from http2 protocol and the logged values
> > seem to be wrong.
> > > If an unknown http2 settings is received, it logs the key and the value to
> > the logfile:
> > >
> > > /org/apache/coyote/http2/ConnectionSettingsBase.java, line 90:
> > >
> > >  case UNKNOWN:
> > >  // Unrecognised. Ignore it.
> > >  log.warn(sm.getString("connectionSettings.unknown",
> > >  connectionId, setting, Long.toString(value)));
> > >  return;
> > >
> > > The value of the settings-variable was unfortunately converted before
> > > to Integer.MAX_VALUE within the settings.java
> > >
> > > enum Setting {
> > >  HEADER_TABLE_SIZE(1),
> > >  ENABLE_PUSH(2),
> > >  MAX_CONCURRENT_STREAMS(3),
> > >  INITIAL_WINDOW_SIZE(4),
> > >  MAX_FRAME_SIZE(5),
> > >  MAX_HEADER_LIST_SIZE(6),
> > >  UNKNOWN(Integer.MAX_VALUE);
> > >
> > > Thus, the logfile doesn’t contain the received, unknown settings-key but
> > MAX_VALUE instead.
> > >
> > > Is it possible to log the real settings key, which was received by the 
> > > server?
> > > Maybe the logging can be moved to the Setting.java instead or the real
> > > key value would have to be transferred to the function which logs(?)
> >
> > I think the existing log can probably just be fixed, no? Want to take a 
> > stab at
> > writing a PR for this?
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Hello Chris,
>
> I forked tomcat and commited/pushed a change.
> Somehow I got lost with the pull request. I haven’t created one yet because I 
> committed one file which shouldn’t be contained in the commit.
> But somehow the commit was already authored (?)
> Not sure if I messed up something up to now.
>
> Can I create a pull request even if one file (gitignore) was accidentally 
> contained in the commit?
> How can my push already be authored before any pull request?
> https://github.com/HoffmannTom/tomcat/commit/6da6f9444192a1ca1d8d0eda1c6694b7c12451ef
>
> Could you help me out how to continue?
> If my change is a mess, then you can tell me and I skip the pull request.

I had a look a little bit earlier and I also thought this was the way
to improve that logging.

Rémy

> Thanks! Thomas
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)

[Rémy Maucherat]

On Fri, Mar 11, 2022 at 6:58 PM Christopher Schultz
 wrote:
>
> Torsten,
>
> On 3/11/22 06:03, Torsten Krah wrote:
> >> It seems to me you are listing a cipher that might be correct
> >> according to the OpenSSL documentation, but then whether that is
> >> available to your JVM may be different.
> >
> > That is for sure not the problem - just use the "ciphers.sh" from the
> > binary directory of tomcat which will list you all possible ciphers you
> > can use - and those match the ones I want to use.
> >
> >>
> >> Maybe you can run some small java application on the very same JVM to
> >> simply list the supported ciphers? At least that would give you an
> >> authorative list of ciphers you can put into the configuration file.
> >
> > No need for that, tomcat already has that - use ciphers.sh .
> >
> > As Thomas found, it is a known bug / missing feature of tomcat - you
> > can't configure TLS 1.3 ciphers in tomcat yet if you want to use the
> > OpenSSL native implementation and Mark Thomas confirmed that here:
> >
> > https://lists.apache.org/thread/q8lmp40xkn0b4k4o6n05n9fyttlvmd22
> >
> > That was 08/2019 - but it still is unsupported in 03/2022 - maybe I'll
> > do a patch for that one ;).
>
> If you do, please make sure you use appropriate #ifdefs in order to
> allow it to compile against multiple versions of OpenSSL, not just
> whatever version you happen to have installed on your local machine.

I used Panama for prototyping, SSL_CTX_set_ciphersuites works but is
not so trivial to use. If you try using the ciphersuite for more than
1.3, there will be warnings (which I improved), and the default Tomcat
uses also does not make sense for 1.3. I wonder if it should revert to
not setting anything in that case (which would need some more
changes).

Rémy

> -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

[ANN] Apache Tomcat 9.0.60 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.60.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.60 is a bugfix and feature release. The notable
changes compared to 9.0.59 include:

- Fix a potential thread-safety issue that could cause HTTP/1.1 request
   processing to pause, and potentially timeout, waiting for additional
   data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
   non request threads but which introduced a similar problem when user
   code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
   fields, ensure that any custom type conversion is considered when
   identifying the method to call.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Re: Tomcat 8.5.75 Servlet WriteListener and ReadListener setting thread

[Rémy Maucherat]

On Mon, Feb 28, 2022 at 4:39 PM Istvan SZEKELY
 wrote:
>
> I've written a NonBlocking ReadWrite test (testDelayedNBReadWrite, in the 
> attached file). I'm not sure if it is a valid test case (though works on 
> 8.5.73, fails on 8.5.75). If it is valid, i can make a PR if needed.

Thanks for the test, this is what I had in mind. As I kind of expected
when reading about the sequential technique used, the previous fix was
causing a new problem since the thread id was not reset until the full
recycle, making the new check inaccurate as well in another scenario.
https://github.com/apache/tomcat/commit/2739565fa5286623e8bb31823770595de14b6370

The fix will be in the next round of monthly releases (9.0.60).

Thanks !

Rémy


>
> On 2022/02/24 10:42:29 Rémy Maucherat wrote:
> > On Thu, Feb 24, 2022 at 10:31 AM Istvan SZEKELY
> >  wrote:
> > >
> > > Hello!
> > >
> > > I have an application where a ReadListener and a WriteListener (call it
> > > MyWriteListener) set to the ServletInputStream and the ServletOutputStream
> > > objects. Updating the Tomcat container from 8.5.73 to 8.5.75, the follow
> > > error occured. The ServletOutputStream objects's isReady function always
> > > returns false (within MyWriteListener.onWritePossible).
> > >
> > > I think its because of this commit:
> > > https://github.com/apache/tomcat/commit/2bfbbef65d1b1b07da46c8dcd6cee96cb5567998#diff-1ffbc1c154370a6c5385c168a0846a1c385aacbf5f880feb74cb1c27baa76003
> > >
> > > The ReadListener is set first, where dispatch fired
> > > (action(ActionCode.DISPATCH_EXECUTE, null);). There the request threadId
> > > updated (req.setRequestThread();).
> > > Then  when i'm setting the WriteListener (within the same thread), the
> > > DISPACTH_EXECUTE action not fired (due to threadId equals request objects
> > > thread id).  Thus registeredForWrite flag remains is true state, causing
> > > the isReady false behaviour.
> > >
> > > Is this a Tomcat bug, or I should do something differently. I could't set
> > > WriteListener within a different thread, but it feels weird. Should i do
> > > something else?
> >
> > I think I see the problem, but would you have test code or example
> > like this testcase to submit ?
> > https://github.com/apache/tomcat/blob/main/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java#L951
> > It would allow verifying and validating a fix.
> >
> > Rémy
> >
> > > Thank You in Advance,
> > >  Istvan
> >
> > -
> > 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

[ANN] Apache Tomcat 9.0.59 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.59.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.59 is a bugfix and feature release. The notable
changes compared to 9.0.58 include:

- Add support for additional user attributes to TomcatPrincipal and
   GenericPrincipal

- Correct a regression in the fix for 65454 that meant that
   minSpareThreads and maxThreads settings were ignored when the
   Connector used an internal executor

- Improve the detection of the Linux duplicate accept bug and reduce
   (hopefully avoid) instances of false positives.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.75 Servlet WriteListener and ReadListener setting thread

[Rémy Maucherat]

On Thu, Feb 24, 2022 at 10:31 AM Istvan SZEKELY
 wrote:
>
> Hello!
>
> I have an application where a ReadListener and a WriteListener (call it
> MyWriteListener) set to the ServletInputStream and the ServletOutputStream
> objects. Updating the Tomcat container from 8.5.73 to 8.5.75, the follow
> error occured. The ServletOutputStream objects's isReady function always
> returns false (within MyWriteListener.onWritePossible).
>
> I think its because of this commit:
> https://github.com/apache/tomcat/commit/2bfbbef65d1b1b07da46c8dcd6cee96cb5567998#diff-1ffbc1c154370a6c5385c168a0846a1c385aacbf5f880feb74cb1c27baa76003
>
> The ReadListener is set first, where dispatch fired
> (action(ActionCode.DISPATCH_EXECUTE, null);). There the request threadId
> updated (req.setRequestThread();).
> Then  when i'm setting the WriteListener (within the same thread), the
> DISPACTH_EXECUTE action not fired (due to threadId equals request objects
> thread id).  Thus registeredForWrite flag remains is true state, causing
> the isReady false behaviour.
>
> Is this a Tomcat bug, or I should do something differently. I could't set
> WriteListener within a different thread, but it feels weird. Should i do
> something else?

I think I see the problem, but would you have test code or example
like this testcase to submit ?
https://github.com/apache/tomcat/blob/main/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java#L951
It would allow verifying and validating a fix.

Rémy

> Thank You in Advance,
>  Istvan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9 Encrpytion of JDBC

[Rémy Maucherat]

On Thu, Jan 20, 2022 at 6:30 PM Christopher Schultz
 wrote:
>
> Harri,
>
> On 1/20/22 11:37, Harri Pesonen wrote:
> > Vault for Apache Tomcat:
> >
> > https://github.com/web-servers/tomcat-vault
> >
> > It hides the secrets in another encrypted file, and password for that
> > file is then in another file... So it just makes it more difficult to
> > access the secrets, but at least they are not in plain text.
> What this does is satisfy the following "security" requirement:
>
> [ ] Have you ensured that no credentials are stored unencrypted in
> Tomcat's conf/server.xml file?
>
> [X] Check!
>
> Nice job. It doesn't answer the question "do you have plaintext
> credentials in any configuration files" because whatever auditor is
> asking would give you a bad grade.
>
> As soon as that auditor learns about Vault for Apache Tomcat, they will ask:
>
> [ ] Have you ensured that no credentials are stored unencrypted in
> Tomcat's conf/server.xml file?
> [ ] Have you ensured that no credentials are stored unencrypted in Vault
> for Tomcat's vault-config.xml file?
>
> Then we'll get questions about whether there is a Vault for Vault for
> Apache Tomcat.
>
> Someone should patch VfAT so it has a new feature which is the number of
> configuration files it should use for encryption. So you can set it to
> e.g. "4" and then you get these files:
>
> vault-config.xml
> vault-config-1.xml
> vault-config-2.xml
> vault-config-3.xml
>
> And the -3 file contains the plaintext password used to unlock -2 which
> unlocks -1 which unlocks vault-config.xml. Hey, three layers of
> encryption! Super secure!

So I guess this means you're still not interested in that awesome
potential contribution we could make to Tomcat :D

Rémy


Rémy

>
> -chris
>
> > -Original Message-
> > From: Orendt, John 
> > Sent: torstai 20. tammikuuta 2022 18.11
> > To: users@tomcat.apache.org
> > Subject: RE: Tomcat 9 Encrpytion of JDBC
> >
> > [Et saa yleensä sähköpostia osoitteesta 
> > john.p.ore...@medtronic.com.invalid. Lue lisää siitä, miksi tämä on 
> > tärkeää, osoitteesta http://aka.ms/LearnAboutSenderIdentification.]
> >
> > Hi
> >
> > There are at least two types of mutual authentication.
> >
> > 1. Device Client A and Server B
> > 2. Human A  via browser and Server B
> >
> > All the scenarios you mention have been solved. You just need to know how.
> > X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the 
> > solution for both types.
> >
> > Internet Banking does exist.
> >
> > John Orendt
> > john.p.ore...@medtronic.com
> >
> > -Original Message-
> > From: Christopher Schultz 
> > Sent: Tuesday, January 18, 2022 11:32 AM
> > To: users@tomcat.apache.org
> > Subject: Re: Tomcat 9 Encrpytion of JDBC
> >
> > John,
> >
> > On 1/18/22 08:37, Orendt, John wrote:
> >> Secrets are more secure with the use of a Trusted Platform Module
> >> (TPM) and  / or a Hardware Security Module (HSM).
> >>
> >> Secrets need to be protected both at rest and in transit.
> > Sure. Where you put the password for the TPM or HSM? Or do you enter the 
> > password for your HSM/TPM every time you start a process that needs access 
> > to secrets? How do you handle unattended restarts?
> >
> > How do you handle massive deployments? Do you manually-enter a password on 
> > 1000 servers as they all launch together?
> >
> > On all these kinds of deployments, you usually use a key server. But then 
> > how do you authenticate to the key server? With another secret.
> > It's secrets all the way down. At some point, you must trust something, and 
> > that something you trust can't be a human, because that doesn't scale or 
> > isn't practical for some other reason.
> >
> > I'd love to hear a practical solution to the "secret at rest" problem that 
> > actually makes some sense and doesn't just hand-wave the problem off to 
> > another component that is Somebody Else's Problem.
> >
> > -chris
> >
> >> -Original Message-
> >> From: Alan F 
> >> Sent: Friday, January 14, 2022 2:05 PM
> >> To: Tomcat Users List 
> >> Subject: RE: Tomcat 9 Encrpytion of JDBC
> >>
> >> OK thanks Bill!
> >>
> >> -Original Message-
> >> From: Bill Stewart 
> >> Sent: 14 January 2022 19:02
> >> To: Tomcat Users List 
> >> Subject: Re: Tomcat 9 Encrpytion of JDBC
> >>
> >> On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote:
> >>
> >>
> >>> Interested to know your best practices on securing jdbc plain text
> >>> passwords, in my last place they used a mechanism to encrypt all 
> >>> passwords.
> >>> Is this the best method as I read some people don't recommend this.
> >>> Any details or procs on best practice appreciated.
> >>>
> >>
> >> The "best practice," generally speaking, is that doing so is basically 
> >> pointless from a security perspective.
> >>
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> >> efense.com%2Fv3%2F__https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisp
> >> 

[ANN] Apache Tomcat 9.0.58 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.58.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.58 is a bugfix and feature release. The notable
changes compared to 9.0.56 include:

- Add recycling check in the input and output stream isReady to try to
   give a more informative ISE when the facade has been recycled.

- Implement support for HTTP/1.1 upgrade when the request includes a
   body. The maximum permitted size of the body is controlled by
   maxSavePostSize.

- Improve handling of various cases where one request/response
   processing thread attempts to manage the asynchronous IO for a
   different request/response.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat GraalVm native image issue

[Rémy Maucherat]

On Sun, Jan 16, 2022 at 3:39 PM Satyajit Rout  wrote:
>
> Thanks Remy for the response.
>
> I kept the main conf files under the module/stuffed/conf folder and then
> tried to build the native image following the steps given in the doc.
>
> When I run the native image from the stuffed folder it works and I am able
> to access the webapp.
>
> *But when I run the same native image from a different folder or on a
> different server, it asks for the server.xml file and fails to run. I have
> pasted the error logs below.*
>
> *Tomcat version: 10.0.14*
>
> =
> Sun Jan 16 14:31:29 GMT 2022
>
> opc@devbox -15./tomcat-stuffed-1.0
>
> Jan 16, 2022 2:31:37 PM org.apache.catalina.startup.Catalina parseServerxml
> WARNING: Unable to load server configuration from /home/opc/conf/server.xml]

Tomcat is a Servlet container that runs standard EE compliant webapps.
The packaging that you're using is an example that allows compiling
the classes from Tomcat and your webapps into a native image. However,
you are still running the usual Tomcat standalone, as well as your
webapp. As a result, you still need a server.xml, all the other
configuration files and resources that go in conf, and your usual
unchanged webapp.

There are solutions to "replace" the files in conf:
- A custom ConfigurationSource implementation allows embedding files
from conf into Java classes (which can then be compiled into your
native image).
- There's a tool which allows generating Tomcat embedded code from
your server.xml. In addition to providing you with code examples if
you want to learn the embedded API, this can also allow you to replace
server.xml.

However, if you prefer a fully packaged and AOT specific solution, you
should look into the proprietary frameworks that target native images.

Rémy

>
> *java.io.FileNotFoundException: /home/opc/conf/server.xml (No such file or
> directory)*
>
> at
> com.oracle.svm.jnt.JNIJavaCallwrappers.jntInvoke_VA_LIST_FileNotFoundException_constructor
> 970c509c6abfd3f98898b9a7521945418b
>
> 90b270(JNIJavaCallwrappers.java:0)
>
> at java.io.FileInputStream.openo(FileInputstream.java) at
> java.to.FileInputStream.open(FileInputStream.java:219)
>
> at java.to.FileInputStream. java.io.FileInputStream.(FileInputStream.java:112)
>
> at
> sun.net.www.protocol.file.FileURL.Connection.connect(FileURL.Connection.java:86)
> at
> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURL.Connection.java:184)
>
> at org.apache.catalina.startup.catalinaBaseConfigurationsource.getResourcei
> CatalinaBaseConfigurationSource.java:118)
>
> at
> org.apache.tomcat.util.file.configurationSource.getConfResource(ConfigurationSource.java:150)
> at org.apache.tomcat.util.file.configurationSource.getServerxml
> (Configurationsource.java:127)
>
> at org.apache.catalina.startup.CatalinaBaseConfigurationsource.getServerxel
> at org.apache.catalina.startup.Catalina.parseServerxml(Catalina.java:631)
>
> at org.apache.catalina.startup.Catalina.load(Catalina.java:732)
>
> at org.apache.catalina.startup.Tomcat. init(Tomcat.java:459)
> at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1337)
>
> Jan 16, 2022 2:31:37 PM org.apache.catalina.core.Standardservice
> startInternal
> INFO: Starting service [Tomcat]
>
> =
>
> Your assistance would help in this situation.
>
> Thanks,
> Satyajit
>
> On Sun, 16 Jan 2022 at 00:50, Rémy Maucherat  wrote:
>
> > On Sat, Jan 15, 2022 at 6:05 PM Satyajit Rout 
> > wrote:
> > >
> > > I want to serve the static file of a reactjs application through this
> > > tomcat native image and I don't have any jar/war file to place under the
> > > webapps folder.
> > >
> > > But tomcat native image is not running without a server.xml file in the
> > > same path from where the native image is triggered.
> >
> > You have to place a server.xml and all the other usual configuration
> > files in the conf folder, this is really the same thing as the usual
> > Tomcat standalone. It seemed explicit enough when I wrote the sentence
> > in the doc. The idea is to not duplicate the default server.xml (and
> > all the others everywhere for no reason.
> > Would you have understood it better if "The main configuration files
> > are placed in the conf folder" -> "The usual configuration files for
> > Tomcat standalone (server.xml, web.xml, etc) should be placed in the
> > conf folder" ?
> >
> > Rémy
> >
> > >
> > > Thanks,
> > > Satyajit
> > >
> &

Re: Tomcat GraalVm native image issue

[Rémy Maucherat]

On Sat, Jan 15, 2022 at 6:05 PM Satyajit Rout  wrote:
>
> I want to serve the static file of a reactjs application through this
> tomcat native image and I don't have any jar/war file to place under the
> webapps folder.
>
> But tomcat native image is not running without a server.xml file in the
> same path from where the native image is triggered.

You have to place a server.xml and all the other usual configuration
files in the conf folder, this is really the same thing as the usual
Tomcat standalone. It seemed explicit enough when I wrote the sentence
in the doc. The idea is to not duplicate the default server.xml (and
all the others everywhere for no reason.
Would you have understood it better if "The main configuration files
are placed in the conf folder" -> "The usual configuration files for
Tomcat standalone (server.xml, web.xml, etc) should be placed in the
conf folder" ?

Rémy

>
> Thanks,
> Satyajit
>
> On Sat, 15 Jan 2022 at 22:29, Satyajit Rout 
> wrote:
>
> >
> >> Hi Team,
> >>
> >> I am trying to build a native image of tomcat on GraalVM by referring to 
> >> the doc at 
> >> "https://tomcat.apache.org/tomcat-9.0-doc/graal.html#Building_the_native_image;.
> >>
> >> The documentation says, "Inside the tomcat-stuffed folder, the directory 
> >> structure is the same as for regular Tomcat. The main configuration files 
> >> are placed in the conf folder, and if using the default server.xml the 
> >> webapps are placed in the webapps folder."
> >>
> >> But if you clone the repo 
> >> "https://github.com/apache/tomcat/tree/main/modules/stuffed; there is no 
> >> files inside tomcat/module/stuffed/conf folder except .gitignore file.
> >>
> >> After building the native image, while I am trying to run the native image 
> >> on another server it fails as it is *unable to find conf/server.xml on 
> >> that server*. Do we have any workaround to package the conf folder into 
> >> the native image or any other resolution for this issue?
> >>
> >>
> >> Thanks & Regards,
> >>
> >> Satyajit
> >>
> >>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Application name in log record

[Rémy Maucherat]

On Mon, Jan 10, 2022 at 11:34 AM Mark Thomas  wrote:
>
> I went to look at the source code and found something I'd completely
> forgotten about. Tomcat exposes several properties that you can use in
> logging.properties. They are:
>
> classloader.webappName
> classloader.hostName
> classloader.serviceName
>
> There are several ways you could make use of those.

You're the one who added this feature 7 years ago ;)

Rémy

> Mark
>
>
> On 10/01/2022 08:59, Makarov Alexey wrote:
> > Thank you, Mark!
> >
> > Excuse me, I forgot describe deployment. Formatter implemented as
> > library (log-formatter.jar). I specified classpath to this library in
> > setenv.sh:
> >
> > echo "Setting parameters from $CATALINA_BASE/bin/setenv.sh"
> > echo "___"
> >
> > export CLASSPATH="$CATALINA_BASE/lib/log-formatter-1.0.jar:$CLASSPATH"
> >
> > echo "___"
> > echo ""
> >
> > Logging configured globally in ${catalina.base}/conf/logging.properties
> > file:
> >
> > ...
> > org.apache.tomee.jul.formatter.AsyncConsoleHandler.level = FINE
> > org.apache.tomee.jul.formatter.AsyncConsoleHandler.formatter =
> > my.log.formatter.OneLineFormatter
> > org.apache.tomee.jul.formatter.AsyncConsoleHandler.encoding = UTF-8
> >
> > ...
> >
> > Looks like, I cannot access to ServletContext directly... Maybe there
> > any other way, to get servlet context from InitialContext or application
> > name from LogManager property:
> >
> > java.util.logging.LogManager.getLogManager().getProperty(...)
> >
> > Do you know desired property or how to list LogManager properties?
> >
> > 10.01.2022 12:53, Mark Thomas пишет:
> >> Use ServletContext.getContextPath()?
> >>
> >> If you have a more complex deployment you might want to preface it
> >> with ServletContext.getVirtualServerName()
> >>
> >> Mark
> >>
> >> On 10/01/2022 05:00, Makarov Alexey wrote:
> >>> Hello! I want to print application name in my log files. As I know, I
> >>> must implemet custom log formatter. How I can get application name?
> >>> import java.util.logging.Formatter;
> >>> import java.util.logging.LogRecord;
> >>> public class MyCustomLogFormatter extends Formatter {
> >>>  @Override
> >>>  public String format(LogRecord record) {
> >>> String webappName = ...;
> >>> return String.format("%s/n", webappName); // only application
> >>> name for testing
> >>>  }
> >>> }
> >>> I use Tomcat 9.0.
> >>
> >> -
> >> 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
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issues when building native image with GraalVM

[Rémy Maucherat]

On Fri, Jan 7, 2022 at 11:15 PM Mar R  wrote:
>
>  >Tomcat is a Jakarta EE container, [...]
> >If you don't like that, then you have to look at a framework targeted
> >at making native images. My employer happens to make Quarkus.
>
> Thanks for the suggestion, seems like this will close the gap to a full
> native image that's bothering me :D

Ok, have fun !

> >I don't understand what you mean about the problem with
> >ServletContextListener. I don't understand why there would be a
> >problem with that. Please try to debug it further if you can.
>
> I don't have any idea how to debug it further, I brought it to the minimum
> possible. It's a new project with just 1 servlet, 1 jsp and 1 class
> implementing ServletContextListener (InitClass.java). I could only leave
> the InitClass but then the issue wouldn't appear because something has to
> access it in some way after it's initialized. So at least a servlet or a
> jsp has to exist and access it.
> As for being an issue, I could be wrong because I don't understand at all
> how the -generateCode and --useGeneratedCode part of the process works. I
> looked a lot but found zero doc/info about those. The only thing I've
> discovered is that those are related  to Tomcat (probably about embedding
> Tomcat) and not Graal. (found reference of them in the source code.)
> So I could only suppose: -generateCode generates some kind of code/info
> upon using the webapp, which will be used by  -useGenerateCode. Considering
> -useGenerateCode is used alongside the native image agent I suppose the
> previous generated info is needed by the native image agent.
> So, based on these suppositions, I've found it strange that if something
> access a class implementing ServletContextListener after (obviously) it was
> initialized, the webapp workflow goes on like that class didn't even exist.
> To debug this I put a simple System.out.println("") in the
> static block, in the constructor and in the initializer block. Upon the
> start of the webapp all 3 get correctly run, but once soemthing access that
> class only the static block gets executed and the previous instance gets
> lost. So the effects of whatever code was run before is now lost.
> I don't know how to explain this clearly I'm sorry, the fastest and best
> way would be to try directly, I provided all the code, files, commands I
> used.

Using a static initializer is not the best idea, or at least, it may
need some work on your part:
https://www.graalvm.org/reference-manual/native-image/ClassInitialization/

For example, this class is a big problem for Graal:
https://github.com/apache/tomcat/blob/main/java/org/apache/juli/AsyncFileHandler.java
(this is obviously an extreme example)

-generateCode generates Tomcat embedded code equivalent to your
server.xml (and context.xml files). -useGeneratedCode uses it (after
it is compiled). With Graal this reduces reflection use, but otherwise
has no other benefit so using it is optional. When in doubt, reading
the generated code should help clarify what it does.

> >About JMX, Tomcat uses JMX and has it enabled by default. You can
> >disable JMX use in Tomcat with --no-jmx (until recently this was done
> >internally in Tomcat when using AOT).
>
> Thanks I'll try again this way, as soon as I discover where to use it :D

Rémy

> Il giorno mar 4 gen 2022 alle ore 14:22 Rémy Maucherat  ha
> scritto:
>
> > On Fri, Dec 31, 2021 at 2:47 PM Mar R  wrote:
> > >
> > > I forgot something sorry. Maybe I'm missing something important but,
> > about
> > > classloading, on native image shouldn't it NOT exist? As far as I
> > > understood after you have a native image you have (resources a part)
> > > everything you need inside the binary + libraries, in my case .exe and
> > .dll
> > > files.
> > > Unless I missed something and a graal native image has a jvm or sort of
> > > which will actually run, so now i get why java code outside of the binary
> > > will actually be used, BUT then I don't get why it was designed this way,
> > > this isn't AOT anymore
> >
> > Tomcat is a Jakarta EE container, so it does that and runs regular
> > webapps (the main big difference is that the JSPs of the webapp have
> > to be precompiled - luckily this has been a feature for a while).
> > Graal doesn't remove classloading anyway, the webapp initialization is
> > the same, and all components are loaded dynamically from descriptors
> > or annotations.
> > If you don't like that, then you have to look at a framework targeted
> > at making native images. My employer happens to make Quarkus.
> >
> > As for the issues, you should close
> > https://github.com/or

Re: Issues when building native image with GraalVM

[Rémy Maucherat]

On Fri, Dec 31, 2021 at 2:47 PM Mar R  wrote:
>
> I forgot something sorry. Maybe I'm missing something important but, about
> classloading, on native image shouldn't it NOT exist? As far as I
> understood after you have a native image you have (resources a part)
> everything you need inside the binary + libraries, in my case .exe and .dll
> files.
> Unless I missed something and a graal native image has a jvm or sort of
> which will actually run, so now i get why java code outside of the binary
> will actually be used, BUT then I don't get why it was designed this way,
> this isn't AOT anymore

Tomcat is a Jakarta EE container, so it does that and runs regular
webapps (the main big difference is that the JSPs of the webapp have
to be precompiled - luckily this has been a feature for a while).
Graal doesn't remove classloading anyway, the webapp initialization is
the same, and all components are loaded dynamically from descriptors
or annotations.
If you don't like that, then you have to look at a framework targeted
at making native images. My employer happens to make Quarkus.

As for the issues, you should close https://github.com/oracle/graal/issues/4164

I fixed the following issues (will be in the next releases in January):
- Packaging some now missing resource bundles (you can ignore warnings
like this)
- Better escaping for call method rules argument values in generated
code (this causes a problem with your Windows paths with the watched
resources)

I don't understand what you mean about the problem with
ServletContextListener. I don't understand why there would be a
problem with that. Please try to debug it further if you can.

About JMX, Tomcat uses JMX and has it enabled by default. You can
disable JMX use in Tomcat with --no-jmx (until recently this was done
internally in Tomcat when using AOT).

Rémy

>
> Il giorno ven 31 dic 2021 alle ore 14:42 Mar R 
> ha scritto:
>
> > Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat 
> > ha scritto:
> >
> >> On Tue, Dec 28, 2021 at 7:18 PM Mar R  wrote:
> >> >
> >> > Tomcat 10.0.14
> >> > Windows 10 x64 21H1 OS Build 19043.1415
> >> >
> >> > openjdk version "17.0.1" 2021-10-19
> >> > OpenJDK Runtime Environment GraalVM CE 21.3.0 (build
> >> > 17.0.1+12-jvmci-21.3-b05)
> >> > OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build
> >> 17.0.1+12-jvmci-21.3-b05,
> >> > mixed mode, sharing)
> >> >
> >> > NetBeans 12.6, maven webapp project
> >> > Maven 3.8.4
> >> > Ant 1.10.12
> >> >
> >> > Followed guide at https://tomcat.apache.org/tomcat-10.0-doc/graal.html
> >> >
> >> > Sorry in advance if not all issues should be reported here but instead
> >> are
> >> > graalvm native image related, I'm reporting everything here and on their
> >> > github fro completeness.
> >> >
> >> >
> >> https://drive.google.com/file/d/17flFW5nlNCdojlvJxCOy23NJBj03p46u/view?usp=sharing
> >> > In this link you can find a folder with everything I used from tomcat
> >> > stuffed folder downloaded from the github link present in the tomcat AOT
> >> > guide, to all commands I put in a script for easier testing purpose,
> >> source
> >> > webapp, built webapp, screenshots, everything :D
> >> >
> >> > I'll start by saying I'm well aware I could definitely have overlooked
> >> > something, anyway I managed to get to the final native image and it
> >> works,
> >> > BUT:
> >> >
> >> > If you remove .class files from webapps/webappname folder, when you run
> >> the
> >> > binary file, it won't find those files, only jsps. This is strange
> >> because
> >> > those files are actually present in the fat jar, and this actually beats
> >> > the purpose of builidng a native image if you have to ship it with java
> >> > files.
> >> >
> >> > If there is a class extending ServletContextListener (InitClass in this
> >> > webapp), when running command with "--catalina -generateCode" parameter,
> >> > where you have to access all jsps and servlets, the class extending
> >> > ServletContextListener will be initialized/used(?) like 2 times, but the
> >> > second time not completly, resetting everything done in the first
> >> > initialization.
> >> > In this webapp it happens when you access the only servlet present.
> >> > Anyway all code is in the google drive link and in InitClass i put some
> >> > prints so you can 

Re: Issues when building native image with GraalVM

[Rémy Maucherat]

On Tue, Dec 28, 2021 at 7:18 PM Mar R  wrote:
>
> Tomcat 10.0.14
> Windows 10 x64 21H1 OS Build 19043.1415
>
> openjdk version "17.0.1" 2021-10-19
> OpenJDK Runtime Environment GraalVM CE 21.3.0 (build
> 17.0.1+12-jvmci-21.3-b05)
> OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build 17.0.1+12-jvmci-21.3-b05,
> mixed mode, sharing)
>
> NetBeans 12.6, maven webapp project
> Maven 3.8.4
> Ant 1.10.12
>
> Followed guide at https://tomcat.apache.org/tomcat-10.0-doc/graal.html
>
> Sorry in advance if not all issues should be reported here but instead are
> graalvm native image related, I'm reporting everything here and on their
> github fro completeness.
>
> https://drive.google.com/file/d/17flFW5nlNCdojlvJxCOy23NJBj03p46u/view?usp=sharing
> In this link you can find a folder with everything I used from tomcat
> stuffed folder downloaded from the github link present in the tomcat AOT
> guide, to all commands I put in a script for easier testing purpose, source
> webapp, built webapp, screenshots, everything :D
>
> I'll start by saying I'm well aware I could definitely have overlooked
> something, anyway I managed to get to the final native image and it works,
> BUT:
>
> If you remove .class files from webapps/webappname folder, when you run the
> binary file, it won't find those files, only jsps. This is strange because
> those files are actually present in the fat jar, and this actually beats
> the purpose of builidng a native image if you have to ship it with java
> files.
>
> If there is a class extending ServletContextListener (InitClass in this
> webapp), when running command with "--catalina -generateCode" parameter,
> where you have to access all jsps and servlets, the class extending
> ServletContextListener will be initialized/used(?) like 2 times, but the
> second time not completly, resetting everything done in the first
> initialization.
> In this webapp it happens when you access the only servlet present.
> Anyway all code is in the google drive link and in InitClass i put some
> prints so you can see what I mean.
> In another bigger webapp my InitClass initializes a lot of things used by
> the webapp basically screwing it.
> This issues happens only in this phase becasue in the second phase where
> the parameter is "useGeneratedCode" it works normally both with this simple
> test webapp and in my other one
>
> When building with native-image command, if
> "-J--add-exports=java.management/sun.management=ALL-UNNAMED" isn't used as
> additional parameter, errors will pop on run crashing the app. (screenshot
> in the google drive link)

Before looking at it more deeply (later ...), let's take this step by step:
- Even though you are generating a fat JAR and building a native
image, the webapps should stay unchanged. All classes and JARs in
WEB-INF will be needed for annotation scanning and whatever
"classloading". So this is not a bug. Don't worry, regular Java
classes that have not been compiled in a native image are never going
to be magically dynamically loaded and run, since this isn't possible
at all.
- Java 17 with Graal is completely untested (Java 11 is) since it's
very new. Since you seem very adventurous, you can also try to compile
in the Panama support for OpenSSL.
- I haven't tested the JMX support, which is fairly new in Graal.
Adding the module declaration on the command line if needed depending
on the Java version doesn't seem that surprising. If you were running
Java 8 you wouldn't need it. For the longest time, JMX was disabled
with Graal (with no way to enable it). Since it supposedly "works",
the regular Tomcat standalone defaults are used (so you can use the
command line to disable it again; to be honest I would probably do
that ...).
- You can keep your server.xml (more flexible), but once everything
works (if you get there then it's good !) you can indeed generate the
equivalent code for server.xml/context.xml with -generateCode and
avoid some reflection. This is really completely optional. So it seems
there's a problem with ServletContextListener then (this is strange
since it's a web.xml component, for which I never added the actual
code generation - it was tempting but way too complex if the goal was
to support everything). So I'll try to understand what is going on.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

[Rémy Maucherat]

On Sat, Dec 11, 2021 at 11:05 PM Sebastian Hennebrüder
 wrote:
>
> Hi all,
>
> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11. 
> Actually the Java path version is not relevant.
>
> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.
>
> If your server can reach arbitrary servers on the Internet, you can execute 
> random code in the shell.
>
> The attack is not using RMI remote class loading but uses Tomcats BeanFactory 
> to create an ELExpression library. As the BeanFactory has features to 
> manipulate instantiated classes, it can inject a Script. In plain Java 
> application this would still be blocked by RMI class loading but Tomcat 
> circumvents this.
>
> The attack is explained in 2019 by 
> https://www.veracode.com/blog/research/exploiting-jndi-injections-java

Also, another person already thought about digging this up (even
before we were aware of the log4j problem):
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.56 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.56.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.56 is a bugfix and feature release. The notable
changes compared to 9.0.55 include:

- Provide protection against a known OS bug that causes the acceptor to
   report an incoming connection more than once.

- Implement a workaround for a JVM bug that can trigger a file
   descriptor leak when using multi-part upload and the application does
   not explicitly close an input stream for an uploaded file that was
   cached on disk.

- Fix exceptions when the security manager is enabled and the first
   request received after starting is an HTTP request to a TLS enabled
   NIO2 connector.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.55 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.55.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.55 is a bugfix and feature release. The notable
changes compared to 9.0.54 include:

- Experimental OpenSSL support through the Panama API incubating in Java
17, with support for OpenSSL 1.1+.

- Add support for custom caching strategies for web application
resources. This initial implementation allows control over whether or
not a resource is cached.

- Improve robustness of JNDIRealm for exceptions occurring when getting
the connection.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Not able to enable SSL on AJP connector

[Rémy Maucherat]

On Mon, Nov 1, 2021 at 3:32 PM Jasvant Singh
 wrote:
> The SSLHostConfig works fine with HTTP/1.1 but not with AJP/1.3 Connector.

The AJP protocol does not support use of TLS. If you want TLS, you can
use HTTP as the proxy protocol, or set up tunnels that use TLS.

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JNDIRealm thread blocking issue

[Rémy Maucherat]

On Fri, Oct 29, 2021 at 9:28 AM Suvendu Sekhar Mondal  wrote:
>
> Hello Chris,
>
> On Fri, Oct 29, 2021 at 2:46 AM Christopher Schultz
>  wrote:
> >
> > Suvendu,
> >
> > On 10/28/21 12:55, Suvendu Sekhar Mondal wrote:
> > > Hello Everyone,
> > >
> > > I was investigating one thread pool exhaustion issue. Thread dump
> > > analysis showed that all HTTP threads were waiting for a ReentrantLock
> > > object. Object address 0x00066d727f28 were same for all of the
> > > waiting threads:
> > >
> > > "http-nio-18100-exec-86" #32808 daemon prio=5 os_prio=0
> > > tid=0x51835800 nid=0x29bc waiting on condition
> > > [0x7a5be000]
> > > java.lang.Thread.State: WAITING (parking)
> > > at sun.misc.Unsafe.park(Native Method)
> > > - parking to wait for  <0x00066d727f28> (a
> > > java.util.concurrent.locks.ReentrantLock$NonfairSync)
> > > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> > > at 
> > > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> > > at 
> > > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> > > at 
> > > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> > > at 
> > > java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> > > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> > > at org.apache.catalina.realm.JNDIRealm.get(JNDIRealm.java:2385)
> > > at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1274)
> > >
> > > There was no hint in the thread dump about which thread was owning the
> > > lock. Luckily, one heap dump was taken before generating thread dump.
> > > When I queried the heap dump for that ReentrantLock object, I saw that
> > > another thread(http-nio-18100-exec-4) was holding the
> > > lock(exclusiveOwnerThread). There was NO trace of
> > > http-nio-18100-exec-4 thread in any of the thread dumps! So it was a
> > > "lock without an owner" case.
> >
> > I think you are looking at several pieces of evidence that may or may
> > not correlate to each other at all. The fact that the thread wasn't in
> > the thread dump indicates that the thread (or even the whole JVM) had
> > terminated between the time you took the heap-dump and the thread dump.
> > Most likely, the monitor was owned by another thread when you took your
> > thread-dump. Try using other tools which *do* reveal the lock-holders
> > identity.
> >
>
> This issue has happened a few times. "Busy Thread Count" was high
> during the problem period. JVM was up and running when I collected
> heap and thread dumps - pid was not changed in-between. I used jstack,
> visualvm, jcmd - nothing revealed owing thread details. Only heap
> dumps had some information on that object and which thread was holding
> onto it. Here is a snap: https://pasteboard.co/D7dV3jej6zId.jpg
>
> I can simulate similar blocking without Tomcat with dummy code. There
> also nothing reveals the owner's identity except the heap dump. Here
> is sample: https://gist.github.com/suv3ndu/2ec9fe660d2b833996817ed62186eac2
>
> > > After glancing through the Tomcat’s JNDIRealm.get() code and
> > > beyond[1], I can see lock is being acquired on singleConnectionLock.
> > > That lock is getting released either in the close() or release()
> > > method. So, if something bad happens to the thread which is trying to
> > > establish a connection, then lock will be held without a proper owner
> > > and a thread blocking situation will be created. Am I interpreting the
> > > code correctly? Should we not handle any failure inside get()?
> > >
> > > Also, I still have not got the reason why the thread got terminated.
> > > Any suggestions on how I can enable any specific logging?
> > >
> > > My setup is:
> > > Tomcat version: 9.0.39
> > > Connector: NIO
> > > JDK: AdoptOpenJDK: 1.8.192
> > > OS: Windows 2016
> >
> > Looks like you need a whole bunch of upgrades. Search the Tomcat 9.x
> > changelog for "JNDIRealm" and you'll see there have been changes since
> > 9.0.39 that may have already resolved this issue. Are you able to
> > re-test with Tomcat 9.0.54?
> >
>
> It will not be easy for me to upgrade it and test it. Lots of approval
> is required to get that done. :(
>
> >  > [1]
> > https://github.com/apache/tomcat/blob/57a6a40fc9f995e4d449358bbde047aab6d9f39a/java/org/apache/catalina/realm/JNDIRealm.java#L2553
> >
> > Note that you are looking at the current version of JNDIRealm.java. The
> > version you are running is 17 commits behind that.
> >
> > The line of code calling ReentrantLock.lock in your code would be
> > https://github.com/apache/tomcat/blob/57a6a40fc9f995e4d449358bbde047aab6d9f39a/java/org/apache/catalina/realm/JNDIRealm.java#L2385
> > which is "return null" indicating that there is a version mismatch
> > between the code you are running and the code you are reading.
> >
>
> 

[ANN] Apache Tomcat 9.0.54 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.54.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.54 is a bugfix and feature release. The notable
changes compared to 9.0.53 include:

- Further robustness improvements to HTTP/2 flow control window
   management.

- Improvements to the DataSourceUserDatabase.

- Fix an issue that caused some Servlet non-blocking API reads of the
   HTTP request body to incorrectly use blocking IO.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.53 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.53.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.53 is a bugfix and feature release. The notable
changes compared to 9.0.52 include:

- Add a UserDatabase implementation as a superset of the DataSourceRealm
   functionality.

- Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
   Commons Pool to 2.11.1

- Update the packaged version of the Tomcat Native Library to 1.2.31 to
   pick up Windows binaries built with OpenSSL 1.1.1l.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: BasicDataSource restart()

[Rémy Maucherat]

On Fri, Sep 3, 2021 at 2:46 AM Jerry Malcolm  wrote:
>
> I have a requirement to start a new log database on the first of every
> month.  I still need to have access to older monthly log databases.   I
> do not want to create a bunch of hardcoded manually configured
> individual datasources, one for each month.  I have a dynamic datasource
> solution that is completely implemented and working except for one
> little thing.
>
> I access the BasicDataSource implementation class for the datasource.  I
> have an algorithm that substitutes _MM at the appropriate spot in
> the configured URL and then updates the url in the datasource.   All of
> this works great.  I can live with the fact that the datasource can only
> point to one database at a time.  My concern is that once I transition
> to another database, there are existing connections in the pool that are
> already attached to the old database.  I need to clear those out and
> start over.  But I don't have the luxury of bouncing tomcat to clean it up.
>
> The apache commons BasicDataSource has a restart() method.  But
> unfortunately that method is omitted from the Tomcat version. There is a
> close() method on the BasicDataSource.  But I don't see anything that
> will re-open it after closing.  I thought about changing maxActive to 0,
> and waiting for it to drain, then setting it back to the original
> value.  None of these sound like an ideal solution.  Without a restart()
> method, is there any other way to force all existing connections to
> close and start clean?

The code is kept in sync with DBCP (with a bit of lag maybe), so these
lifecycle methods were also added to Tomcat one year ago (9.0.38+ and
8.5.58+).

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.52 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.52.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.52 is a bugfix and feature release. The notable
changes compared to 9.0.50 include:

- Correct a regression in the previous release in the HTTP/2 flow
   control window management

- Correct a regression the could cause some TLS connections to hang when
   using NIO

- Use of GraalVM native images no longer automatically disables JMX
   support.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Possible Http11NioProtocol regression since 9.0.48?

[Rémy Maucherat]

On Tue, Jul 6, 2021 at 10:41 AM Mark Thomas  wrote:
>
> On 05/07/2021 20:19, André van der Lugt wrote:
> >
> > Mark, thank you for your efforts so far.
>
> No problem. Happy to help.
>
> At this point it is hard to tell where the root cause is. It is possible
> that the Tomcat changes introduced a bug in Tomcat. It is also possible
> that the Tomcat changes triggered a set of circumstances that exposed a
> pre-existing bug elsewhere (Java, OS, network).

I can revert the changes again and we can figure out what's wrong in
10.x eventually.

Rémy

>
> As the next step, I'd suggest collecting a network trace from the Tomcat
> VM at the same you collect a trace from the client. The aim of this
> would be to determine if Tomcat / Java / OS/ VM is delaying those final
> packets or if the delay is occurring somewhere in the network. By
> comparing the two traces you should be able to narrow down where the
> delay is happening.
>
> Mark
>
>
> >
> >>
> >> Other questions that come to mind:
> >>
> >> 1. Was the network trace created from a client connected directly to
> >> Tomcat or was there a proxy / firewall / something else between the
> >> client and Tomcat?
> >
> > Tomcat is running on the company network to which I'm connected
> > through company mandated VPN and who knows what else
> > equipment there is between me and Tomcat's VM.
> >
> > Your question made me think: what if I try from a browser installed
> > on another VM on the company network? So I did from two different
> > machines and bingo ... the problem does not manifest itself.
> > Maybe I need to have a word with our IT?
> >
> >>
> >> 2. Where was the trace collected from? On the client? On the server?
> >> Somewhere else?
> >
> > Trace was collected on the client.
> >
> > -
> > 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

[ANN] Apache Tomcat 9.0.50 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.50.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.50 is a bugfix and feature release. The notable
changes compared to 9.0.48 include:

- Re-work the HTTP/2 overhead protection to reduce the likelihood of
   false positives. Note that the default overheadCountFactor has changed
   from 1 to 10 and that the useful range is now 0 to ~20.

- Update to Eclipse JDT compiler 4.20.

- Fix regressions in JSP compilation in the previous release.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.48 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.48.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.48 is a bugfix and feature release. The notable
changes compared to 9.0.46 include:

- Improve robustness of HTTP/2 HPACK decoding

- Improvements to the handling of the Transfer-Encoding header

- Review code used to generate Java source from JSPs and tags and remove
   code found to be unnecessary.

- Backport the updated blocking NIO code and optimizations from Tomcat 10.0.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 9.0.48 available

[Rémy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.48.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.48 is a bugfix and feature release. The notable
changes compared to 9.0.46 include:

- Improve robustness of HTTP/2 HPACK decoding

- Improvements to the handling of the Transfer-Encoding header

- Review code used to generate Java source from JSPs and tags and remove
   code found to be unnecessary.

- Backport the updated blocking NIO code and optimizations from Tomcat 10.0.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

Re: Trouble with HTTP/2 during concurrent bulk data transfer (server -> client)

[Rémy Maucherat]

On Thu, Jun 17, 2021 at 9:27 AM Mark Thomas  wrote:

> On 17/06/2021 07:56, Rémy Maucherat wrote:
>
> > The main benefit is that it removes some blocking IO which is a good
> idea.
> > NIO2 is worth testing with your new test, BTW.
>
> NIO2 works. The issue appears to be limited to the NIO connector.
>

Interesting. At least it's another workaround then. Are you testing NIO on
Java 11+ ?

Rémy


>
> Mark
>
> > Transferring large files with HTTP/2 is a bad idea though, it's always
> > going to be inefficient compared to HTTP/1.1. And if the idea is to
> > multiplex, then it will become terrible, that's a given and it should not
> > be done. HTTP/2 is very good only if you have tons of small entities to
> > transfer (that's what sites have these days, so that's good).
> >
> > Rémy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Trouble with HTTP/2 during concurrent bulk data transfer (server -> client)

[Rémy Maucherat]

On Wed, Jun 16, 2021 at 11:02 PM Mark Thomas  wrote:

> On 16/06/2021 19:42, Deshmukh, Kedar wrote:
> > Thanks Mark for the quick update.
> >
> > Can you please provide how useAsyncIO="false" makes impact in terms of
> performance, scalability (number of connections to the server) and
> reliability ?
>
> Well, if you set useAsyncIO="false" it works. If you set
> useAsyncIO="true" it fails 90% of the time.
>
> I'd suggest that, with that failure rate, discussion of performance and
> scalability are somewhat irrelevant.
>
> With test cases that do not trigger this issue the difference between
> the two is marginal. Remy is more familiar with the details than me but
> from memory useAsyncIO="true" is a little better on older JREs. On
> modern JREs there isn't much in it. It is also likely to depend on
> application usage patterns, OS, etc. In short, you'd need to test the
> difference on your application with your hardware etc. I'd expect the
> difference to be hard to measure.
>

The main benefit is that it removes some blocking IO which is a good idea.
NIO2 is worth testing with your new test, BTW.

Transferring large files with HTTP/2 is a bad idea though, it's always
going to be inefficient compared to HTTP/1.1. And if the idea is to
multiplex, then it will become terrible, that's a given and it should not
be done. HTTP/2 is very good only if you have tons of small entities to
transfer (that's what sites have these days, so that's good).

Rémy


>
> Mark
>
>
> >
> > Regards,
> > Kedar
> >
> >
> > -Original Message-
> > From: Mark Thomas 
> > Sent: Wednesday, June 16, 2021 11:41 PM
> > To: users@tomcat.apache.org
> > Subject: Re: Trouble with HTTP/2 during concurrent bulk data transfer
> (server -> client)
> >
> > On 16/06/2021 18:47, Rémy Maucherat wrote:
> >> On Wed, Jun 16, 2021 at 7:36 PM Mark Thomas  wrote:
> >>
> >>> On 16/06/2021 18:01, Deshmukh, Kedar wrote:
> >>>
> >>>> I have one additional question at this point. How easy is this issue
> >>>> to
> >>> reproduce? Does it happen every time? In 10% of requests? 1% ?
> >>>>
> >>>> [Kedar] It is reproducible 9/10 times in my environment. So 90% time
> >>>> it
> >>> is reproducible when concurrency is 5 or more and file sizes are
> >>> between 1GB-5GB.
> >>>
> >>> Thanks for the confirmation. I have converted your test classes into
> >>> a Tomcat unit test (easy for me to work with) and the issue looks to
> >>> be repeatable on Linux with the latest 10.1.x code.
> >>>
> >>> I'm starting to look at this now. I'll post again when I have more
> >>> information. I'm not expecting this to be quick.
> >
> > Kedar,
> >
> > If you set useAsyncIO="false" on the Connector that should work around
> the problem for now. The Servlet Async API will still be available.
> > Tomcat just uses a different code path to write to the network.
> >
> >> I did not expect it would be so easy to reproduce. Can you commit the
> test ?
> >
> > It is a bit of a hack at the moment. The code isn't particularly clean
> and I have hard-coded some file paths for my system (I have a bunch of 5GB
> Windows MSDN ISOs I am using for the large files. I also don't think we
> want test cases that using multi-GB files running on every test run.
> >
> > If I clean things up a bit, parameterise the hard-coded paths bits and
> disable the test by default it should be in a reasonable state to commit.
> >
> > It looks very much like the vectoredOperation and the associated
> semaphore is where things are going wrong.
> >
> > I'm aiming to work on this some more tomorrow.
> >
> > 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: Trouble with HTTP/2 during concurrent bulk data transfer (server -> client)

[Rémy Maucherat]

On Wed, Jun 16, 2021 at 7:36 PM Mark Thomas  wrote:

> On 16/06/2021 18:01, Deshmukh, Kedar wrote:
>
> > I have one additional question at this point. How easy is this issue to
> reproduce? Does it happen every time? In 10% of requests? 1% ?
> >
> > [Kedar] It is reproducible 9/10 times in my environment. So 90% time it
> is reproducible when concurrency is 5 or more and file sizes are between
> 1GB-5GB.
>
> Thanks for the confirmation. I have converted your test classes into a
> Tomcat unit test (easy for me to work with) and the issue looks to be
> repeatable on Linux with the latest 10.1.x code.
>
> I'm starting to look at this now. I'll post again when I have more
> information. I'm not expecting this to be quick.
>

I did not expect it would be so easy to reproduce. Can you commit the test ?

Rémy

Re: #tomcat on Freenode?

[Rémy Maucherat]

On Thu, May 20, 2021 at 9:57 AM Mark Thomas  wrote:

> On 19/05/2021 20:28, Coty Sutherland wrote:
> > Hi all,
> >
> > I was just notified about some mess going on with Freenode which has
> > seemingly resulted in a mass exodus of users from the freenode servers.
> > There are some updates available at
> > https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409/ which
> > make it seem like we should no longer point users to #tomcat on freenode
> > (we point to it on https://tomcat.apache.org/irc.html).
> >
> > Should we take any action on that, like remove the page or update it to
> > point to https://libera.chat/ after we establish a channel there? I'm
> not
> > sure how much value there is/was in the freenode channel because
> questions
> > are so infrequent, so we may be able to safely drop the reference.
>
> +1 to removing the freenode link
>
> If we replace it, I'd be happy with https://libera.chat/ but like you I
> wonder if we need it at all. We should probably add the Slack channel
> somewhere too.
>

We should probably drop the IRC page and focus on the mailing lists for the
website (they are the only official channel). A wiki page can mention other
things like Slack.

Rémy


>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: TOMCAT 9 Upgrade :--java.lang.NoClassDefFoundError: org/apache/tomcat/util/net/ServerSocketFactory

[Rémy Maucherat]

On Tue, Feb 23, 2021 at 4:47 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Ravi,
>
> On 2/23/21 10:19, Ravi Kumar wrote:
> > Using this Interface , trying to obtain the object of type
> > ServerSocketFactory in my application.
> > Could you please point towards any other viable alternative ?
> >
> > @Override
> > 
> >  public ServerSocketFactory
> > <
> http://java.sun.com/j2se/1%2E5%2E0/docs/api/javax/net/ServerSocketFactory.html
> >
> > getServerSocketFactory(AbstractEndpoint abstractendpoint) {
> >  return new JSSESocketFactory(abstractendpoint);
> >  }
>
> No, that's "how you are doing it". Nobody just wants to get a reference
> to a ServerSocketFactory object because it looks pretty. What are you
> actually trying to accomplish?
>
> (e.g. log the TLS protocol, customize the cipher suites, etc.)
>

I know people who extended this to add features. The problem is that this
had to go following the removal of java.io in Tomcat, and now the SSLEngine
has to be used instead [compatible with NIO and NIO2]. But it's a huge
change.

Rémy


>
> -chris
>
> > On Tue, Feb 23, 2021 at 8:15 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Ravi,
> >>
> >> Please don't email list members directly. I'm happy to offer paid
> >> support if you want to email me directly.
> >>
> >> On 2/23/21 05:11, Ravi Kumar wrote:
> >>> We are upgrading the tomcat web server getting used in our web
> >>> application. Currently we are using tomcat 7 and now migrating to
> TOMCAT
> >>> 9.0.43.
> >>> We have an existing  HTTPS based application created using tomcat 7.
> >>> Now after migration and upgrading to tomcat 9, while starting this same
> >>> https application, we are receiving the error message as mentioned
> below
> >>> *SEVERE: Failed to initialize component [Connector[HTTP/1.1-8443]]
> >>> java.lang.NoClassDefFoundError:
> >>> org/apache/tomcat/util/net/ServerSocketFactory*
> >>> *
> >>> *
> >>>It seems that org.apache.tomcat.util.net
> >>> .*ServerSocketFaactory *class has
> >>> been removed since tomcat 8.5.53 and in Tomcat 9 also.
> >>
> >> Correct.
> >>
> >>> Requesting for the helpful suggestion to make our existing application
> >>> working with Tomcat 9 and to resolve this error.
> >>> Please let me know if more information is required.
> >>
> >> What do you need this class for? Tomcat's socket handling has been
> >> refactored between 7.x and 8.x and that class was no longer necessary.
> >>
> >> If your code uses that class directly, you will have to find another way
> >> to accomplish what you are doing.
> >>
> >> So... what are you trying to do?
> >>
> >> -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
>
>

Re: Upgraded to 8.5.63, ssl stopped working...?

[Rémy Maucherat]

On Fri, Feb 12, 2021 at 8:17 AM Mark Thomas  wrote:

> On February 11, 2021 11:01:27 PM UTC, Jim Weill 
> wrote:
> >Yes, the file is there and readable.  The NTFS permissions have only
> >the
> >built-in SYSTEM, CREATOR OWNER, and domain administrators group as
> >having
> >any kind of access to the folder.  This was working before I started
> >upgrading.  The last modified date is 2017 on that file.
>
> Check the user the Tomcat service is running as. This changed from Local
> System (essentially an admin account) to the less privileged Local Service.
>

I think the problem which messes up everything is a supposed non absolute
URI. I don't remember why this is legitimate, but it probably is, and that
means the error messages are microsoftian. I improved them.

Rémy


> Mark
>
>
> >
> >jim
> >
> >On Thu, Feb 11, 2021 at 2:17 PM Rémy Maucherat  wrote:
> >
> >> On Thu, Feb 11, 2021 at 10:33 PM Jim Weill
> >
> >> wrote:
> >>
> >> > Sorry, I should have posted it yesterday.  This was the only thing
> >I
> >> could
> >> > find that had anything like an error in the stderr log:
> >> >
> >> > 10-Feb-2021 17:34:09.930 SEVERE [main]
> >> > org.apache.catalina.core.StandardService.initInternal Failed to
> >> initialize
> >> > connector [Connector[HTTP/1.1-8443]]
> >> > org.apache.catalina.LifecycleException: Protocol handler
> >initialization
> >> > failed
> >> > at
> >> >
> >org.apache.catalina.connector.Connector.initInternal(Connector.java:1077)
> >> > at
> >org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> >> > at
> >> >
> >> >
> >>
>
> >org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> >> > at
> >org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> >> > at
> >> >
> >> >
> >>
>
> >org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:846)
> >> > at
> >org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> >> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> >> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> >> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> >> > at java.lang.reflect.Method.invoke(Unknown Source)
> >> > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> >> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
> >> > Caused by: java.lang.IllegalArgumentException: Illegal character in
> >> opaque
> >> > part at index 2: D:\_ssh\_.ICSI.Berkeley.EDU.key
> >> > at
> >> > org.apache.tomcat.util.net
> >> >
> >.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> >> > at
> >> > org.apache.tomcat.util.net
> >> > .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> >> > at
> >org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:247)
> >> > at
> >> > org.apache.tomcat.util.net
> >> > .AbstractEndpoint.init(AbstractEndpoint.java:1143)
> >> > at
> >> > org.apache.tomcat.util.net
> >> > .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:222)
> >> > at
> >org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:599)
> >> > at
> >> >
> >> >
> >>
>
> >org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
> >> > at
> >> >
> >org.apache.catalina.connector.Connector.initInternal(Connector.java:1075)
> >> > ... 13 more
> >> > Caused by: java.lang.IllegalArgumentException: Illegal character in
> >> opaque
> >> > part at index 2: D:\_ssh\_.ICSI.Berkeley.EDU.key
> >> > at java.net.URI.create(Unknown Source)
> >> > at java.net.URI.resolve(Unknown Source)
> >> > at
> >> >
> >> >
> >>
>
> >org.apache.tomcat.util.file.ConfigFileLoader.getURI(ConfigFileLoader.java:105)
> >> > at
> >> >
> >> >
> >>
>
> >org.apache.tomcat.util.file.ConfigFileLoader.getInputStream(ConfigFileLoader.java:88)
> >> > 

Re: Upgraded to 8.5.63, ssl stopped working...?

[Rémy Maucherat]

On Thu, Feb 11, 2021 at 10:33 PM Jim Weill 
wrote:

> Sorry, I should have posted it yesterday.  This was the only thing I could
> find that had anything like an error in the stderr log:
>
> 10-Feb-2021 17:34:09.930 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal Failed to initialize
> connector [Connector[HTTP/1.1-8443]]
> org.apache.catalina.LifecycleException: Protocol handler initialization
> failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1077)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
>
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at
>
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:846)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
> Caused by: java.lang.IllegalArgumentException: Illegal character in opaque
> part at index 2: D:\_ssh\_.ICSI.Berkeley.EDU.key
> at
> org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100)
> at
> org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:247)
> at
> org.apache.tomcat.util.net
> .AbstractEndpoint.init(AbstractEndpoint.java:1143)
> at
> org.apache.tomcat.util.net
> .AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:222)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:599)
> at
>
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1075)
> ... 13 more
> Caused by: java.lang.IllegalArgumentException: Illegal character in opaque
> part at index 2: D:\_ssh\_.ICSI.Berkeley.EDU.key
> at java.net.URI.create(Unknown Source)
> at java.net.URI.resolve(Unknown Source)
> at
>
> org.apache.tomcat.util.file.ConfigFileLoader.getURI(ConfigFileLoader.java:105)
> at
>
> org.apache.tomcat.util.file.ConfigFileLoader.getInputStream(ConfigFileLoader.java:88)
> at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:98)
> at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:90)
> at
> org.apache.tomcat.util.net
> .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313)
> at
> org.apache.tomcat.util.net
> .SSLUtilBase.createSSLContext(SSLUtilBase.java:245)
> at
> org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98)
> ... 20 more
> Caused by: java.net.URISyntaxException: Illegal character in opaque part at
> index 2: D:\_ssh\_.ICSI.Berkeley.EDU.key
> at java.net.URI$Parser.fail(Unknown Source)
> at java.net.URI$Parser.checkChars(Unknown Source)
> at java.net.URI$Parser.parse(Unknown Source)
> at java.net.URI.(Unknown Source)
> ... 29 more
> 10-Feb-2021 17:34:09.930 INFO [main]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["ajp-nio-127.0.0.1-8009"]
> 10-Feb-2021 17:34:09.930 INFO [main]
> org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a
> shared
> selector for servlet write/read
> 10-Feb-2021 17:34:09.930 INFO [main]
> org.apache.catalina.startup.Catalina.load Initialization processed in 1522
> ms
>

This happens when D:\_ssh\_.ICSI.Berkeley.EDU.key is not a file (or not
there) and it then tries as a URL. Is your keystore still there after your
update ?
There were recent changes, but there's no difference that I can see with
that location as input.

Rémy


>
> On Thu, Feb 11, 2021 at 12:17 AM Mark Thomas  wrote:
>
> > On 11/02/2021 02:06, Jim Weill wrote:
> > > I had 8.5.41 working and decided to do the upgrade to 8.5.63 today on
> > > Windows Server 2012r2.  I've had success with stopping the service,
> > > renaming the tomcat directory, putting the unzipped files of the new
> > > version in its place, and dropping in the server.xml, and web.xml files
> > to
> > > replace the default files.  As well, I copy over the webapps folder for
> > the
> > > site, then restart the service.  This process has worked many times
> > before.
> > >
> > > When I did this today, the service would not start for some reason.
> So I
> > > renamed the folders back to their original names, and then ran the
> > > uninstall from the add/remove programs.  I ran the install executable
> on
> > > 8.5.63, dropped in the webapps folder, and the server.xml and web.xml
> > files
> > > and 

Re: Are we able to deploy the same WAR to Tomcat 9 and 10?

[Rémy Maucherat]

On Fri, Feb 5, 2021 at 4:03 PM Mark Thomas  wrote:

> On 05/02/2021 14:45, Johan Compagner wrote:
> > Hi,
> >
> > I already now get the first support request that our application doesn't
> > run under Tomcat 10.
> >
> > So just want to get straight how this is going to work in the future.
> >
> > i see there is a migration tool, but that is for now quite useless for us
> > because we also need to support Tomcat 9 or 8..
> >
> > We are a tool/framework vendor we don't control what our users do, they
> can
> > still be on what ever servlet container they are on. (we only require the
> > websocket implementation so that makes certain stuff the minimum)
> >
> > Is there or will there be a way that we can drop in a jar that is just a
> > "redirect/wrapper"?
>
> At the moment, no.
>
> > And then I don't care too much about if it goes from javax.servlet to
> > jakarta.servlet or the other way around.. I just want to support both
> > deployments. That our customers can dump in the generated war by our
> > tooling in any tomcat version (8,9 or 10) and it just works.
>
> There has been talk of integrating the migration tool into Tomcat 10 so
> if you drop in a Java EE 8 app it automagically converts it to Jakarta
> EE 9 before starting it.
>

Yes, I was thinking about having a "ee8appBase" attribute on the host
(defaults to ee8webapps, or something). Then any artefact placed in that
folder gets processed (by the HostConfig) to the regular "appBase" using
the migration tool with a direct API call, equivalent to using the CLI.
Then it gets deployed as before from "appBase".

The lack of interest about this was quite impressive ;) And it's rather
gimmicky of course, it simply adds a possible deployment failure and
inefficiency, when the user should instead process the artifact ahead of
time.


>
> I'm guessing you'd prefer this to having to provide separate Java EE and
> Jakarta EE versions (even if all you had to do to create the Jakarta EE
> version was run it through the migration tool).
>

I'm a bit skeptical that it will be possible to avoid having native Jakarta
versions forever.


> On a related topic, it would be helpful to know if the migration tool
> successfully converts your app.
>

+1

Rémy

>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: SSL trouble in embeddedLand

[Rémy Maucherat]

On Tue, Jan 19, 2021 at 5:02 AM Rob Sargent  wrote:

>
> Stuck in my basement with no real domain I'm having trouble setting up
> SSL/TLS on an embedded tomcat instance. And I'm very lost, having tried
> more dead ends than I can remember.
>
> I used this to generate cert and key
> openssl req -out localhost.crt -key localhost.key \
> -newkey rsa:2048 -nodes -sha256 \
> -subj '/CN=localhost' -extensions EXT -config <( \
> printf "[dn]\nCN=localhost\n[req]\ndistinguished_name =
> dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature,
> nonRepudiation, keyEncipherment,
> dataEncipherment\nextendedKeyUsage=serverAuth")
>
> and try to apply those with
>
> -Djavax.net.ssl.trustStore=/tmp/key/localhost.crt
> -Djavax.net.ssl.trustStorePassword=changeit
> -Djavax.net.ssl.trustStoreType=PKCS12
> -Djavax.net.ssl.keyStore=/tmp/key/localhost.key
> -Djavax.net.ssl.keyStorePassword=changeit
> -Dhttps.protocols=TLSv1.2,TLSv1.3
> -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3
>
> I get "toDerInputStream rejects tag type 45".
>
> That error rears its ugly head in several places such when adding those
> same two localhost files to a pkcs12 rendition of the OS's cacerts file
> using below. The crt goes in quietly. (I'm couldn't convince my self of
> the openssl equivalent of this command)
> root@gitanmax:/tmp/key# keytool -importkeystore -srckeystore
> localhost.key -srckeypass changeit -srcstoretype pkcs12 -destkeystore
> cacerts.pkcs12 -deststoretype pkcs12 -srcalias localhost -destalias
> tomcatlocal
> Importing keystore localhost.key to cacerts.pkcs12...
> Enter destination keystore password: changeit
> Enter source keystore password: changeit
> keytool error: java.io.IOException: toDerInputStream rejects tag type 45
>
> My actual first attempt was to just use keytool to generate a cert
> interactively, filling in my own bogus values but that hit the domain
> name mismatch gotcha.
>
> Then, there's confusion on the java side as well.
>
> My plan was to add a connector for my webapp
>
> embeddedTomcat = new Tomcat();
> logger.debug("handing in CATALINA_HOME as " +
> System.getenv("CATALINA_HOME"));
> embeddedTomcat.setPort(tomcatPort-1);
> embeddedTomcat.enableNaming();
> Connector defaultConnector = embeddedTomcat.getConnector(); // an init,
> really
> defaultConnector.setSecure(true); // force https?
>
> Service service = embeddedTomcat.getService();
> service.addConnector(addTLSConnector(tomcatPort));
>
> logger.info("tomcatd listening on port " + tomcatPort);
> String contextRootPath = System.getenv("CATALINA_HOME");
> logger.debug("contextRootPath is {}", contextRootPath);
> Context contextTomcat = embeddedTomcat.addContext("", new
> File(contextRootPath + "/sgs").getAbsolutePath());
> logger.debug("host: {}, general context basename {}",
> embeddedTomcat.getHost(), contextTomcat.getBaseName());
> //TODO: cut from here ...
> java.time.LocalDateTime bootDT = java.time.LocalDateTime.now();
> Tomcat.addServlet(contextTomcat, "monitor", new HttpServlet() {
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> ServletOutputStream out = resp.getOutputStream();
> out.write("SGS Agent monitor: SGS_OK\n".getBytes());
> out.write(("Up since " + bootDT.toString()).getBytes());
> out.write(("\nTime now " +
> java.time.LocalDateTime.now().toString()).getBytes());
> out.flush();
> out.close();
> }
> });
> contextTomcat.addServletMappingDecoded("/monitor", "monitor");
> // My webapp
> Context sgsContext = embeddedTomcat.addWebapp("/sgs", contextRootPath +
> "/sgs"); // /sgs.war
> embeddedTomcat.start();
> embeddedTomcat.getServer().await();
>
> private Connector addTLSConnector(Connector connector, int tcport) {
> File keyFile = new File (System.getProperty("SGSSRVR_keystoreFile"));
> if (! keyFile.exists()) throw new RuntimeException("where's the
> keystore?");
> connector.setPort(tcport);
> connector.setSecure(true);
> connector.setScheme("https");
> connector.setProperty("protocol", "HTTP/1.1");
> connector.setProperty("sslProtocol", "TLS");
> connector.setProperty("address","127.0.0.1");
> connector.setProperty("clientAuth", "false");
> connector.setProperty("maxThreads", "200");
> connector.setProperty("protocol",
> "org.apache.coyote.http11.Http11NioProtocol");
> connector.setProperty("SSLEnabled", "true");
> return connector;
> }
>
> private Connector addTLSConnector(int tcport) {
> Connector connector = new Connector();
> addTLSConnector(connector, tcport);
> return connector;
> }
>
> That "monitor" works, on a separate port, on either http or https as per
> defaultConnector.setSecure(isHttps);
> but possibly because I've diddle with chrome's security settings.
>
> I have a similar "monitor" as a servlet which I use as my
> is-anybody-home call to start my analyses. And of course can also use
> it via the browser at /seg/webmonitor.
>
> All these behave when SSL is not in play, but I'm forced, very much
> against my will, to use SSL so here 

Re: Examples failing

[Rémy Maucherat]

On Fri, Dec 4, 2020 at 2:05 PM Ibone Gonzalez Mauraza 
wrote:

> Hi,
>
> The examples of async of the newest versions are failing.
>

This is fixed already:
https://github.com/apache/tomcat/commit/0b5d5c91bafd3f61938917490ab531474dbb778a

Rémy


> When I try to run the test, I got the following error:
>
> tomcat_1  | 04-Dec-2020 12:36:55.183 WARNING [http-nio-8080-exec-6]
> org.apache.catalina.connector.Request.startAsync Unable to start async
> because the following classes in the processing chain do not support async
> [org.apache.catalina.filters.HttpHeaderSecurityFilter]
> tomcat_1  | java.lang.IllegalStateException: A filter or servlet of the
> current chain does not support asynchronous operations.
> tomcat_1  | at
> org.apache.catalina.connector.Request.startAsync(Request.java:1696)
> tomcat_1  | at
> org.apache.catalina.connector.Request.startAsync(Request.java:1689)
> tomcat_1  | at
> org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1031)
> tomcat_1  | at async.Async0.service(Async0.java:48)
> tomcat_1  | at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> tomcat_1  | at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> tomcat_1  | at
> org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> tomcat_1  | at
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> tomcat_1  | at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> tomcat_1  | at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
> tomcat_1  | at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
> tomcat_1  | at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
> tomcat_1  | at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
> tomcat_1  | at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
> tomcat_1  | at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
> tomcat_1  | at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
> tomcat_1  | at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> tomcat_1  | at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:616)
> tomcat_1  | at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> tomcat_1  | at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831)
> tomcat_1  | at org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1634)
> tomcat_1  | at org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> tomcat_1  | at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> tomcat_1  | at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> tomcat_1  | at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> tomcat_1  | at java.base/java.lang.Thread.run(Thread.java:834)
>
> Regards,
> Ibone.
>
>

Re: Custom protocol implementation not found

[Rémy Maucherat]

On Wed, Oct 14, 2020 at 11:38 AM Maarten van den Broek <
mbr...@messagedesign.nl> wrote:

> I use tomcat 9.0.33 with windows10 home and amazon corretto jdk1.8.0_212.
>
> Below a snapshot of two different Connector definitions in server.xml
>
>   maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true"
> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
> clientAuth="false" sslEnabledProtocols="TLSv1.2"
> minSpareThreads="5"
> enableLookups="true" disableUploadTimeout="true"
> keystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
> keystorePass="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
> />
>
>   disableUploadTimeout="true" enableLookups="true" maxThreads="150"
> minSpareThreads="5" port="443"
> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
> SSLEnabled="true" scheme="https" secure="true">
>  
>   certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
>
> certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
> certificateKeystoreType="JKS"/>
>  
>  
>
> Using the first Connector everything is working fine. Debugging the
> setKeystorePass method of the class
> nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the
> protocol attribute shows that the encrypted password gets decrypted.
>
> Using the second connector with the SSLHostConfig element instead of the
> deprecated attributes debugging shows that the setKeystorePass method is
> not called and I get errors for the incorrect password of the keystore.
>
> What am I doing wrong in migrating to the configuration with the
> SSLHostConfig element?
>
> Sincerely yours,Maarten van den Broek
>

If you simply want to obfuscate server.xml attributes, you should look into
the digester property sources instead of engaging in this sort of stuff.
One such property source out there:
https://github.com/web-servers/tomcat-vault

Note: This capability is not included directly into Tomcat itself because
it provides no actual extra security.

Rémy

Re: A lot of EOFs when using NIO2 with HTTP2

[Rémy Maucherat]

On Tue, Oct 6, 2020 at 8:31 AM Martin Grigorov  wrote:

> Hi,
>
> I face an issue with the NIO2 protocol.
> When I increase the request rate to more than 500 requests per second it
> starts failing with:
>
> 06-Oct-2020 09:18:19.964 FINE [https-jsse-nio2-8080-exec-6]
> org.apache.coyote.http2.Http2UpgradeHandler.init Connection [1], State
> [NEW]
> 06-Oct-2020 09:18:19.978 FINE [https-jsse-nio2-8080-exec-6]
> org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.failed
> Connection [1], Stream [0], Frame type [null], Error
> java.io.EOFException
> at
> org.apache.tomcat.util.net
> .SecureNio2Channel$2.completed(SecureNio2Channel.java:1005)
>

Also, it is a real EOF as the error says, caused by the client
disconnecting for whatever reason (good or bad).

Rémy