Am 07.02.25 um 22:36 schrieb Rainer Jung:
Am 07.02.25 um 22:21 schrieb Rainer Jung:
Am 07.02.25 um 21:50 schrieb Rainer Jung:
Hi Chris,
Am 07.02.25 um 20:44 schrieb Christopher Schultz:
Rainer,
On 2/7/25 2:38 PM, Rainer Jung wrote:
Am 04.02.25 um 23:10 schrieb Christopher Schultz:
The proposed Apache Tomcat 10.1.35 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.34 are:
- Allow readOnly attribute configuration on the Resources element and
allow configuration of the readOnly attribute value of the main
resources. The attribute value will also be used by the default
and
WebDAV Servlets.
- Correct a regression in the fix for bug 69382 that broke JSP
include actions if both the page attribute and the body contained
parameters. Pull request #803 provided by Chenjp.
- Expand the options for handling encoded '/' and '\' characters in
URLs both in the Connector and when using a RequestDispatcher.
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.35/
The Maven staging repo is:
https://repository.apache.org/content/repositories/
orgapachetomcat-1530
The tag is:
https://github.com/apache/tomcat/tree/10.1.35
https://github.com/apache/tomcat/
commit/9636e5188311f30c1e46c94191d2145998778bf4
Please reply with a +1 for release or +0/-0/-1 with an explanation.
+1
Reproducibility of the build checked (except for Windows installer
and signing) on Linux Mint 22.1. OK after setting LANG.
I'd still like to look-in on this. For the installer, are you
willing to install Wine?
I could but I'm not so eager putting wine on my laptop.
Interestingly I use NSIS to build windows installers completely on
Linux. That is one of the nice features of NSIS. Currently the only
reason I see, why wine is really used, is the tempinstaller.exe which
is created and then executed to create the uninstaller. When I use
NSIS, it can create the uninstaller directly, but I have not yet
investigated why we need this indirection.
It seems it has to do with how we do code signing, but I haven't fully
understood the details. When building an installer myself, I use
!finalize 'mysignscript myinstaller.exe'
!uninstfinalize 'mysignscript myuninstaller.exe'
inside the nsi script file.
I do not know, whether this would be feasible with how we use jsign
and the cloud signing service, but it should be doable. I haven't
understood though, how the detached signatures are used. I don't seem
to use detached signatures when doing my installer.
Without code signing (do.codesigning=false), the following changes at
least run on Linux without wine and produce an installer. But I still
have to check, whether the intsaller actually works:
--- build.xml 2025-02-04 18:40:20.000000000 +0100
+++ build.xml 2025-02-07 22:12:14.418108524 +0100
...
Sorry, one more:
--- res/install-win/tomcat.nsi 2024-10-07 15:58:21.790187079 +0200
+++ res/install-win/tomcat.nsi 2025-02-07 21:55:58.716342021 +0100
@@ -18,7 +18,7 @@
Unicode true
!ifdef UNINSTALLONLY
- OutFile "tempinstaller.exe"
+ OutFile "Uninstall.exe"
!else
OutFile tomcat-installer.exe
!endif
The installer looks good function wise and it installs a file
Uninstall.exe, But Uninstall.exe created that way and bundled in the
installer does not actually work as an uninstaller. It actually seems to
run only very shortly not showing a GUI or any noticable effect.
BUT: IMHO without using the official signing service, the installer
will never be reproduced by me. So even if I make some sort of code-
signing work, building the installer would just show, that the file is
produced. Plus, if I am willing to try it on Windows, whether it looks
OK.
The other wine calls used to execure makensis.exe can be replaced by
directly calling makensis on Linux using -X flags instead of /X flags.
> Also, which artifacts are not byte-for-byte identical when >
performing the build verification -- when LANG=de? All of them, or only
some of them?
Just the fulldocs tarball. The HTML pages contains german text
instead of the english one. We tried fixing it using java means
(sysprops, flags) to no avail.
Tested on platforms
- RHEL 6, 7, 8 and 9, SLES 11, 12 and 15, Solaris 11 Sparc
using
- current patch versions of JDK 11, 17 and not yet done 21, 23 and
24+25 (current EAs)
from
- Eclipse Adoptium, Azul Zulu, Amazon Coretto, Oracle, RedHat and
OpenJDK (for the EA)
where available.
Also tested with
- tcnative 1.3.1, tcnative 2.0.8 and panama
based on
- OpenSSL 3.0.15, 3.1.7, 3.2.3, 3.3.2 and 3.4.0.
All fine, except for the usual sporadic crashes with tcnative
during shutdown. Also manually changed the max memory size for the
unit tests from 256m to 512m (already fixed in git).
Thanks for RM!
;)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
