Jon,

On 12/6/24 12:45 PM, Mcalexander, Jon J. wrote:
This won’t result in losing Java 11 compatability will it? We have lots of 
teams using Java 11 with Tomcat 9x and 10.1x

You'll be fine unless you:

1. Get the Tomcat source
2. Perform a unit-test build
3. Take the automatically-downloaded derby.jar and put it into your application

I think there is a fairly low likelihood of you doing all that :)

-chris

From: Rainer Jung <rainer.j...@kippdata.de>
Sent: Friday, December 6, 2024 11:01 AM
To: dev@tomcat.apache.org
Subject: Re: [VOTE] Release Apache Tomcat 10.1.34

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


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://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$<https://urldefense.com/v3/__https:/nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$>



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://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.34/__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXA1eSrjE$<https://urldefense.com/v3/__https:/dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.34/__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXA1eSrjE$>



The Maven staging repo is:

https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapachetomcat-1525__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXPCqj3XD$<https://urldefense.com/v3/__https:/repository.apache.org/content/repositories/orgapachetomcat-1525__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXPCqj3XD$>



The tag is:

https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/10.1.34__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXJp9CmIn$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/tree/10.1.34__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXJp9CmIn$>

https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXPam2zub$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/commit/__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXPam2zub$>

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<mailto:dev-unsubscr...@tomcat.apache.org>

For additional commands, e-mail: 
dev-h...@tomcat.apache.org<mailto:dev-h...@tomcat.apache.org>





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

Reply via email to