Hi Chris,
Am 06.12.24 um 17:49 schrieb Christopher Schultz:
Rainer,
On 12/5/24 4:57 PM, Rainer Jung wrote:
Am 05.12.24 um 18:14 schrieb Christopher Schultz:
The proposed Apache Tomcat 10.1.34 release is now available for
voting.
All committers and PMC members are kindly requested to provide a vote
if possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes
are binding. We welcome non-committer votes or comments on release
builds.
The notable changes compared to 10.1.33 are:
- Add strong ETag support for the WebDAV and default servlet, which can
be enabled by using the useStrongETags init parameter with a value
set
to true. The ETag generated will be a SHA-1 checksum of the resource
content.
- Add support for RateLimit header fields for HTTP (RFC draft) in the
RateLimitFilter. Based on pull request #775 provided by Chenjp
- Update Tomcat's fork of Commons DBCP to 2.13.0.
For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
Applications that run on Tomcat 9 and earlier will not run on Tomcat
10 without changes. Java EE applications designed for Tomcat 9 and
earlier may be placed in the $CATALINA_BASE/webapps-javaee directory
and Tomcat will automatically convert them to Jakarta EE and copy
them to the webapps directory.
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.34/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1525
The tag is:
https://github.com/apache/tomcat/tree/10.1.34
https://github.com/apache/tomcat/commit/
acf7da1801a4751b282a70ced24b73c1046db831
Please reply with a +1 for release or +0/-0/-1 with an explanation.
At least three test classes fail when testing with Java 11:
org.apache.catalina.valves.TestJDBCAccessLogValve
org.apache.catalina.session.TestPersistentManagerDataSourceStore
org.apache.catalina.servlets.TestWebdavPropertyStore
java.sql.SQLException: org/apache/derby/jdbc/EmbeddedDriver has been
compiled by a more recent version of the Java Runtime (class file
version 61.0), this version of the Java Runtime only recognizes class
file versions up to 55.0
Aw.
It looks like this version bump happened in May, updating to Derby
10.16.1.1. Derby 10.16 only supports Java 17 and later.
Since Derby is only used for testing, I think it's probably to say that
this is okay to not block the release. Had Java 11 worked between May
and now for testing 10.1.x?
It seems there was no derby update, but those classes were adjusted
recently, so likely the tests are new. There are a few other classes
using derby as well. They seem to catch the errors, because their
tests do not escalate to a test failure or error.
IMHO not critical for the release vote, but we should fix it.
We would need to downgrade to Derby 10.15 to support down to Java 9.
Tomcat 9 will have the same issue; it uses the same version of Derby as
Tomcat 10.
It looks like Mark tried to upgrade Derby to 10.17 in May but reverted
in 147b9390a40d5068b073ac2b46e7aebb5b6585fb with the changelog comment:
"
Revert Derby to 10.16.1.1 as that is the latest version of Derby that
runs on Java 17.
"
Since Tomcat 11 has pinned its Derby support on Java 17/Derby 10.16, I
think it's appropriate for Tomcats 10.1 and 9.0 to downgrade to the
latest supported Derby versions on Java 11 (Derby 10.15) and Java 8
(Derby 10.14) respectively.
-chris
The derby version is not new, but these three failing tests are. Rémy
already fixed the failures in 9.0.x and 10.1.x head by checking for the
needed Java version.
The other test classes using derby did not and do not fail even with the
older Java versions. I did not check, whether they check for the Java
version or catch the failures in some other way.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
