Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14
Le 18/12/2023 à 18:00, Mark Thomas a écrit : Am I understanding this request correctly? Mostly, but for the context, if ever that makes it morally more acceptable, Freexian here is merely a vehicle to found independent contributors to work and maintain old packages, it's nothing like a RedHat sized company trying to maximize its profits and the dividends of its shareholders. That said, I agree with Mark that it isn't reasonable to expect support for an EOLed version. For Debian ELTS I usually advise aligning the Tomcat version with the one in the following Debian release to ease the maintenance. So that would mean pulling the Tomcat 8.5 package from Debian Stretch to Jessie. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14
Le 18/12/2023 à 18:15, Michael Osipov a écrit : SCNR: https://unixsheikh.com/articles/the-delusions-of-debian.html That's a low blow, this post smells more like an old systemd rant mixed with a complete misunderstanding on how Debian works than a well founded criticism. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Which release artifact should we expect to be reproducible?
Le 19/10/2023 à 04:17, Christopher Schultz a écrit : But Mark, if you missed my message from the 13th, you'll see that the problem is I'm running a slightly different version of Java than you are, and the exact spelling of the version string is causing the problem -- mostly in MANIFEST.MF files because the whole JRE's version string is present in there and not just the version number. I think the Created-By field should be removed. I've got a quick look at the 11.0.0-M13 release and the manifests in tomcat-*.jar don't have it. I've found it only in bootstrap.jar and in the external dependencies. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Which release artifact should we expect to be reproducible?
Le 12/10/2023 à 23:27, Christopher Schultz a écrit : I installed the ZIP version of Temurin Java 21 to match your release toolchain and I get every file being different. But the versions are not exactly the same, so that may be the reason: Release Java: 21+25-2513 Local Java: 21+35-LTS I'm also using Cp1252 instead of UTF-8 (ew). I'll try to change that and see if it changes anything. Did you try comparing the files with diffoscope [1]? That would allow you to quickly see what varies and prevents the build from being reproducible. Emmanuel Bourg [1] https://diffoscope.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.14
Le 10/10/2023 à 00:18, Christopher Schultz a écrit : The proposed 10.1.14 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 10.1.14 It looks good on Debian with OpenJDK 17. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11, Java 21 and Windows 32-bit support
On 16/06/2023 21:42, Mark Thomas wrote: There are lots of interesting things about those numbers but in terms of 32-bit Windows support there still looks to be a demand for it all the way up to Tomcat 10. If we were to drop it for one we might as well drop it for all but I think there is enough demand to keep producing the 32-bit binaries for now. We don't know if there is a real demand for 32-bit binaries or if this simply reflects random clicks on the download page. The 32-bit zip is listed before the 64-bit one, this might inflate the numbers. Running Tomcat on Windows with less than 4GB RAM doesn't make much sense nowadays in my opinion. If someone really has a memory constrained server he would run Linux and not Windows. I'm +1 for releasing Tomcat 11 with 64-bit binaries only, but I wouldn't wait until 2025 to drop the 32-bit distribution for the previous releases. If nobody complains about the lack of 32-bit support in Tomcat 11 by the end of 2023, I would suggest dropping the 32-bit binary distribution for Tomcat 10 as well. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.7
Le 26/04/2023 à 18:19, Mark Thomas a écrit : The proposed 1.0.7 release is: [ ] -1: Broken. Do not release because... [X] +1: Acceptable. Go ahead and release. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Verifying reproducible release builds
Hi Christopher, Le 12/01/2023 à 23:24, Christopher Schultz a écrit : I spent some time today verifying that the release artifacts that Mark published the other day for 10.1.5 were indeed reproducible by me. Fortunately, they were, but it was a little bit of a process so I went ahead and documented it. https://cwiki.apache.org/confluence/display/TOMCAT/Verifying+a+Release+Build A couple of suggestions: - I'd use shasum rather than diff to compare the artifacts - if the artifacts are not identical, the diffoscope tool [1] can help identify the differences Emmanuel Bourg [1] https://diffoscope.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.69
Le 09/11/2022 à 20:48, Rémy Maucherat a écrit : The proposed 9.0.69 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.69 Looks good in Debian with OpenJDK 17 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.68
Le 03/10/2022 à 22:05, Mark Thomas a écrit : The proposed 9.0.68 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.68 (stable) Looks good on Debian with OpenJDK 11. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Security manager support
Hi all, The security manager has been deprecated for removal in Java 17 [1], and at some point Tomcat will have to stop supporting it. Do we want to wait until it's no longer available in the JDK to remove it from Tomcat, or should we remove it earlier, maybe in Tomcat 10.1 or 11? I tend to think there are better solutions at the OS level to isolate a Tomcat instance nowadays, and I lean toward dropping it before its removal from the JDK. What do you think? Emmanuel Bourg [1] https://openjdk.org/jeps/411 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Status of 10.0.x
Le 26/09/2022 à 16:50, Mark Thomas a écrit : Now 10.1.x is stable, how to we want to handle 10.0.x? Than plan has always been that we would support 10.0.x until 10.1.x was stable. Assuming the vote passes (we need 1 more +1) then there will be a 10.0.26 release. Do we want that to be the last 10.0.x. release? If, not, how many more 10.0.x releases should there be? From the Debian point of view, since Tomcat 10 hasn't been packaged yet dropping 10.0.x will have no impact, we'll skip directly to 10.1.x in Debian Bookworm. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.67
Le 23/09/2022 à 14:03, Rémy Maucherat a écrit : The proposed 9.0.67 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 9.0.67 (stable) It looks good on Debian. Emmanuel Bourg OpenPGP_signature Description: OpenPGP digital signature
Re: Migrate from Bugzilla to GitHub Issues
On 18/08/2022 10:51, Konstantin Kolinko wrote: Have you considered migrating from Bugzilla to GitHub Issues? I am -1. 1. It is better to stay with a solution owned by ASF as much as possible. Same feeling here, I like how GitHub ties the code hosting and the issue tracker, but I think it's important the ASF keeps the control of its tools. If ever the ASF replaces GitBox with GitLab or Gitea I'd support moving the issue tracker. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Repeatable builds update
Le 05/05/2022 à 21:28, Mark Thomas a écrit : TL;DR we have platform independent repeatable release builds That's really a great achievement, thank you. I hope this will inspire other Apache projects to make their builds reproducible. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reproducible builds update
Le 18/01/2022 à 21:03, Mark Thomas a écrit : I'm wondering about second issue. It would be nice to have a complete fix but if the full docs package isn't reproducible how much of an issue is that? Reproducibility issues with javadoc are quite frequent unfortunately, many Java packages in Debian aren't reproducible due to that. I suggest checking with the latest JDK first and then submit a bug report or a patch to OpenJDK. Fortunately a non-reproducible javadoc isn't really important, what matters the most is to have reproducible executable packages. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OT: Parsing EC private keys in PEM format
Le 26/08/2021 à 12:08, Mark Thomas a écrit : > Hmm. Odd. I wonder why they said that. Do you have a public reference to > that conversation. Obviously, any potential IP issues are a concern. > > Looking at the code, I'm struggling to see where the concern would come > from. > > The original contribution was from Emmanuel. Given his work on JSign I > have no reason to think the contribution wasn't original. Note that Jsign doesn't share the PEM parsing code I contributed to Tomcat, it uses the PEMParser class [1] from BouncyCastle which handles more formats (in a very different way). BouncyCastle being released under the MIT license, maybe their parser could better fit the PostgreSQL needs? Emmanuel Bourg [1] https://github.com/bcgit/bc-java/blob/master/pkix/src/main/java/org/bouncycastle/openssl/PEMParser.java - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 10.1.x, 10.0.x, 9.0.x and 8.5.x
Le 2021-06-10 08:30, Mark Thomas a écrit : Except that it doesn't work. The version of JSign we are using requires Java 8. I'm planning on looking into possible options this morning. One option is to roll-back to the previous Windows only way of doing a release. Let me know if there is any issue with Jsign 2.1, I can release a modified 3.x version compatible with Java 7. Another solution is to use a different JDK for the signing step. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Integrate JSign for cross-platform builds with signed Windows binaries
Le 2021-06-09 21:09, Rémy Maucherat a écrit : Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_FUNCTION_FAILED at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:635) ... 12 more Try `java -jar jsign.jar --help' for more information. The cfg file is: name=DigiCertONE library="/home/remm/.digicertone/smpkcs11.so" slotListIndex=0 The .so is there (otherwise it would complain earlier). Also the smctl tool shows the key. I tried other algorithms but no success so far. You can try adding -Djava.security.debug=sunpkcs11, it should provide more info. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time to create Tomcat 10.1.x and master->main migration
Le 2021-05-18 14:10, Emmanuel Bourg a écrit : Comments? I don't think the 7.0.x branch should be removed, there is no harm keeping it. As for the master->main change I think that's a waste of time for all of us. i don't buy the argument that "master" is offensive, but by moving awa Grr message sent too quickly, sorry. I don't want to reopen the debate, please ignore my comment. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time to create Tomcat 10.1.x and master->main migration
Le 2021-05-18 13:18, Mark Thomas a écrit : All, Things are starting to move forward for Jakarta EE 10 so I think it is time for us to create the 10.1.x branch. At the same time, I'd like to switch our primary development branches from master to main for all our repos. We would, therefore, end up with the following for the Tomcat repo: main - 10.1.x development 10.0.x - 10.0.x development/maintenance 9.0.x - 9.0.x development/maintenance 8.5.x - 8.5.x development/maintenance 7.0.x - 7.0.x development/maintenance There are some git commands each committer will need to run locally for each repo to switch from master to main. I have also been looking into how we can "retire" the 7.0.x branch when the time comes (after end of June). I'd like to suggest the following: - tag the HEAD of the 7.0.x branch as "7.0.x-archive" - delete the 7.0.x branch That way it won't appear in the list of branches but it is trivial to recreate if we need it. I'd like to get the master->main rename completed and the 10.1.x development branch created towards the end of this week (unless there are objections or things we need to discuss further). Comments? I don't think the 7.0.x branch should be removed, there is no harm keeping it. As for the master->main change I think that's a waste of time for all of us. i don't buy the argument that "master" is offensive, but by moving awa - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release Managers wanted
Le 2021-05-13 00:10, Mark Thomas a écrit : So, who'd like to volunteer? I can take care of the migration tool if you want. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reproducible builds
Le 19/03/2021 à 16:39, Mark Thomas a écrit : > Over the last few days I have been looking at making the Tomcat builds > (more) reproducible. I have currently reached the stage where sequential > builds on my local machine produce identical output. That's a great idea. > There are several caveats > > 1. Some of the embedded JARs can vary between runs due to a Bnd issue. > That has been reported to the Bnd project and should be fixed shortly. In Debian the Tomcat package is mostly reproducible, the only difference is in the OSGi metadata and the Require-Capability field [1]. Is this the Bnd issue you are referring to ? > 2. The current Windows exe signing process isn't repeatable. There are a > few suggestions workarounds at https://reproducible-builds.org/ and I > need to discuss these with the provider of the code signing service the > ASF uses (DigiCert). The signature is reproducible but not the timestamp. We'd need something like a detached signature shipped with the source package, and a build that either append the signature or get a new one from DigiCert. > I have a series of commits where each commit addresses a specific issue. I got a quick look, I guess you replaced the tasks with to make the timestamp of the zip entries reproducible? I'm not sure this is sufficient, there is no guarantee the order of the entries will be the same (this is usually dependent on the filesystem used, I don't think Ant sorts the entries). In Debian there is a tool (strip-nondeterminism) post-processing the jar files and fixing the possible variations (entries order, timestamps), we'll probably need something similar. Emmanuel Bourg [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tomcat9.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.44
Le 04/03/2021 à 23:22, Mark Thomas a écrit : > The proposed 9.0.44 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.44 +1, looks good in Debian Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Integrating migration tool into Tomcat 10
Le 2021-02-10 16:36, Rémy Maucherat a écrit : After reading everything, I'd say it's worth adding a second integrated option, and think I'm now swaying towards the runtime option. The main problem would be the detection of legacy webapps. We could simply mandate using an explicit new attribute on the Context element (and done !) so nobody pays any needless costs. The runtime option still incurs a cost for the legacy applications because the classes and the resources have to be filtered every time the application is started. Ideally the application should be converted only once. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Integrating migration tool into Tomcat 10
Le 2021-02-09 22:12, Mark Thomas a écrit : Thoughts? I think this feature is really desirable. For the Debian packaging this would mean a faster transition to Tomcat 10. There are two issues: 1. How to identify a legacy application? 2. How to convert the application once identified? For the identification, either: a. separate the Java EE and Jakarta EE webapps in different directories. It's simple but it's an additional decision point for the user and there will be mistakes. b. keep the webapps in the same directory and scan the content. This degrades the performances for those having switched to Jakarta EE, so this should be optional, and probably disabled by default. c. keep the webapps in the same directory, load them as usual and trigger the conversion mechanism only if a class loading error related to the javax namespace occurs. Regarding the conversion, we can: a. Convert at runtime with class loading tricks, which is quite elegant but the price is paid every time the application is started. b. Convert at deployment time before loading the application, this means more file juggling but only the first start is impacted. The convenience of the automatic migration comes obviously at a price but I think it's important we ensure it doesn't impact those ready to jump to the new Jakarta EE world. For this reason I'm leaning toward the solution 1c + 2b (convert on errors, and convert the webapp before reloading). The start sequence would look like this: 1. foo.war is copied to the webapps directory by the user 2. The foo application is loaded 3. A NoClassDefFoundError regarding the javax.servlet.Servlet class is thrown, the migration mechanism is triggered 4. The migration tool is executed on foo.war. The original file is renamed foo.war.legacy and the migrated file remains as foo.war 5. The application is reloaded And on subsequent starts, the migrated application is loaded directly, with no performance impact. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Ignoring test failures
Hi all, I'd like to add a mechanism to the Tomcat build to ignore the test failures, something similar to the Maven testFailureIgnore property. In Debian Tomcat is built in an offline container and the tribes tests fail due to the lack of multicast. So build.xml has been patched to remove the tasks, but it would be easier to set a build property instead. Do you think we could add something like this: Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.43
Le 28/01/2021 à 21:48, Mark Thomas a écrit : > The proposed 9.0.43 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.43 It looks good in Debian (OpenJDK 11.0.10, OpenSSL 1.1.1i). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Objection to the deprecation of the tomcat-native/APR connector
Le 11/12/2020 à 17:56, Michael Osipov a écrit : > Well, isn't that really a OS vendor problem not ours? We can provide > grace periods, but that's pretty much it. They need to solve that, not > us on a volunteer basis. Note that (most) Debian Developers are volunteers too. > FreeBSD's port of libtcnative is uptodate. I provide patches on regular > basis. Vendors like Debian or Red Hat lag years behind. I don't know the state in Red Hat, but in Debian tomcat-native is up-to-date [1]. For the stable release there are backports with more recent versions available. Emmanuel Bourg [1] https://tracker.debian.org/tomcat-native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat migration tool for Jakarta EE
Le 10/12/2020 à 12:39, Mark Thomas a écrit : > The proposed 0.1.0 release is: > > [ ] -1: Broken. Do not release because... > [X] +1: Acceptable. Go ahead and release. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 58588] Remove extras/juli from Tomcat 9 build and deliveries as Log4J 1.x has reached EOL.
The spam comments have been removed but the offending URL and attachment are still there. I'm not sure to know how to remove them without sending another mail notification with yet another occurrence of the URL. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 9.0.x updated: Fix IDE warning
Le 07/12/2020 à 19:00, ma...@apache.org a écrit :
> commit dcf2044bd4f653154cb60218a3f3667673f746bf
> Author: Mark Thomas
> AuthorDate: Wed Dec 2 14:21:04 2020 +
>
> Fix IDE warning
> ---
> java/javax/servlet/http/Cookie.java | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/java/javax/servlet/http/Cookie.java
> b/java/javax/servlet/http/Cookie.java
> index e50bebe..bc2dd83 100644
> --- a/java/javax/servlet/http/Cookie.java
> +++ b/java/javax/servlet/http/Cookie.java
> @@ -74,7 +74,7 @@ public class Cookie implements Cloneable, Serializable {
> } else {
> strictServletCompliance = AccessController.doPrivileged(
> (PrivilegedAction) () ->
> Boolean.valueOf(System.getProperty(
> -
> "org.apache.catalina.STRICT_SERVLET_COMPLIANCE")));
> +
> "org.apache.catalina.STRICT_SERVLET_COMPLIANCE"))).booleanValue();
> propStrictNaming = AccessController.doPrivileged(
> (PrivilegedAction) () -> System.getProperty(
>
> "org.apache.tomcat.util.http.ServerCookie.STRICT_NAMING"));
My IDE (IntelliJ 2020.3) gives the opposite warning and suggests using
auto-boxing instead of explicit boxing/unboxing. Should I avoid using
auto-boxing in Tomcat?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.0.0
Le 03/12/2020 à 15:16, Rémy Maucherat a écrit : > Hopefully no surprises ! I think Mark deserves a big round of applause for > all the extra polishing that was done. +1 ! > Personally, I want to see the feedback on the Jakarta migration, and if > people are happy with something like the tool or if they really want > deploy/classload time scary magic. Should Tomcat 10 get such a feature I think I'd push to make it the supported version of Tomcat in Debian 11 (to be released next year). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.0.0
Le 03/12/2020 à 11:43, Mark Thomas a écrit : > The proposed 10.0.0 release is: > [ ] Broken - do not release > [X] Beta - go ahead and release as 10.0.0 (beta) > [ ] Stable - go ahead and release as 10.0.0 (stable) +1, ok in Debian Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.41
Le 03/12/2020 à 14:11, Mark Thomas a écrit : > The proposed 9.0.41 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.41 > +1, all good in Debian. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Objection to the deprecation of the tomcat-native/APR connector
Le 06/12/2020 à 11:03, Mark Thomas a écrit : > 3. Once downstream distributions have access to 1.1.1 move Tomcat Native > 1.2.x to 1.3.x and remove all the OpenSSL <1.1.1 code. We can make 1.3.x > recommended for Tomcat 8.5.x and 9.0.x (or even required if necessary / > appropriate). The current state of OpenSSL in Debian is: - OpenSSL 1.0.1t in Debian 8 (no longer supported) - OpenSSL 1.1.0l in Debian 9 (EOL in June 2022) - OpenSSL 1.1.1d in Debian 10 And in Ubuntu: - OpenSSL 1.0.2g in Ubuntu 16.04 LTS (EOL in April 2021) - OpenSSL 1.1.1 in Ubuntu 18.04 LTS - OpenSSL 1.1.1f in Ubuntu 20.04 LTS Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 01/02: Replace Collections.sort() with List.sort()
Le 04/12/2020 à 02:07, Igal Sapir a écrit : >> Shall we backport these commits to 9.x and 8.5? >> It will make it easier to backport future changes in these classes. > > +1 > > No need to diverge the branches unnecessarily. I've backported the changes to Tomcat 9 and 8.5 (minus the incompatible changes for the targeted JDK). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 01/02: Replace Collections.sort() with List.sort()
Le 04/12/2020 à 13:31, Rémy Maucherat a écrit : > I mean you can add lambda expressions in Tomcat 9, but not Tomcat 8.5, > right ? Since Tomcat 8.5 is supposed to be Java 7 friendly ( > http://tomcat.apache.org/whichversion.html ). Tomcat 7 would be Java 6 > (ouch). Oh ok, I thought you were referring to the Java 7 syntax changes. I'll leave out the lambdas for Tomcat 8.5 of course. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 01/02: Replace Collections.sort() with List.sort()
Le 04/12/2020 à 12:13, Rémy Maucherat a écrit : > +1 to backport to 9.0, but not to Tomcat 8.5 since it would need to be Java > 7 compatible [some of the changes might be fine, but for others it's not > possible]. Did you mean Tomcat 7? Because Tomcat 8.5 already depends on Java 7. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 02/05: Collapse identical catch blocks
Le 04/12/2020 à 09:03, Mark Thomas a écrit : >> java/org/apache/el/parser/AstValue.java| 6 ++ > > This is generated code. The change will be undone the next time the > source is regenerated. My preference is to leave generated code as-is > but I don't think this needs to be reverted. Thank you for the information, I didn't know. >> .../dbcp/dbcp2/PoolableCallableStatement.java | 4 +--- >> .../dbcp2/datasources/InstanceKeyDataSource.java | 10 ++--- > > This code is forked from Commons DBCP2. Any changes increases the risk > of future merges having conflicts that require manual resolution. Better > to apply the clean-up upstream and then pick it up in the next merge. This is a mistake, I tried to avoid touching DBCP but these changes went through. I'll apply the changes in Commons. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat Native Build Instructions
Le 03/12/2020 à 23:00, Igal Sapir a écrit : > It seems that the package is named "libapr1-dev" and I'm not sure if that > was a recent change or not. > > I want to update the docs but not sure if that would break non-Ubuntu > Debian-based builds. > > Any thoughts? libapr1.0-dev was in Debian Sid between 2004 and 2006, it has only been part of Debian 3.1 Sarge until its EOL in 2008. (the Ubuntu release at this time was 6.06 Dapper Drake, EOL in 2011) libapr1-dev has been used to build tomcat-native in Debian (and Ubuntu) since its first upload in 2008 [1]. Emmanuel Bourg [1] https://salsa.debian.org/java-team/tomcat-native/-/commit/201da1d9 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 01/02: Replace Collections.sort() with List.sort()
Hi Christopher, Le 03/12/2020 à 21:49, Christopher Schultz a écrit : > I'm curious as to why this change is warranted. I'm not suggesting it's > not... just wondering what the benefit is? Avoiding a pass-through > method call? It's the shorter idiom to sort lists with Java 8+, it just improves the readability. I don't think the method call avoided has any impact, the actual sorting dominates the time spent anyway. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.37
Le 30/06/2020 à 22:41, Mark Thomas a écrit : > The proposed 9.0.37 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.37 +1, tested in Debian Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: Changing the name of the default branch in our git repos
Le 16/06/2020 à 10:02, Mark Thomas a écrit : > Thoughts? I'd prefer the status-quo and keep "master", I've always understood this as the 'master record' (I know it might be historically wrong) and I haven't seen evidences it has ever offended or deterred anyone from contributing. If there is a consensus to change I suggest waiting to see what GitHub plans to do. The "master" name is a de-facto standard for Git repositories, and I think we should remain consistent with the new name that will be popularized by GitHub. That said, I have a preference for "main". Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE][RESULT] Release Apache Tomcat migration tool for Jakarta EE 0.0.2
The following votes were cast: Binding: +1: remm, mgrigorov, markt, ebourg No other votes were cast. The vote therefore passes. Thank you to everyone who contributed to this release. signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat migration tool for Jakarta EE 0.0.2
Le 04/06/2020 à 15:08, Emmanuel Bourg a écrit : > The proposed 0.0.2 release is: > [ ] Broken - do not release > [X] Beta - go ahead and release as 0.0.2 > +1 Emmanuel Bourg signature.asc Description: OpenPGP digital signature
[VOTE] Release Apache Tomcat migration tool for Jakarta EE 0.0.2
I'd like to call for a vote to release the version 0.0.2 of the Jakarta EE migration tool. This will be a "tag only" release with no distribution of the binaries (neither from Apache nor from Maven Central). The notable changes compared to 0.0.1 are: - An Ant task has been added - Inplace file migration is now supported - EC signatures are now removed from the migrated jar files - Better log formatting when running from the command line - New '-verbose' option for the command line Tag: https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git;a=commit;h=45d354c1835a1583baf0be02ae77e70fd290f2da Source: https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git The proposed 0.0.2 release is: [ ] Broken - do not release [ ] Beta - go ahead and release as 0.0.2 signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat 9.0.36
Le 03/06/2020 à 20:06, Mark Thomas a écrit : > The proposed 9.0.36 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.36 Tests are ok on Debian with OpenJDK 11.0.7, Tomcat Native 1.2.24 and OpenSSL 1.1.1g. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta EE migration tool improvements
Le 07/04/2020 à 13:50, Rémy Maucherat a écrit : > I would want to keep the basic tool available. Of course, this is in addition to the command line tool. > Ideally it is nice to avoid having too many options. I hardly imagine more than 10 options for this kind of tool. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta EE migration tool improvements
Le 07/04/2020 à 12:41, Mark Thomas a écrit : >> - Use a CLI parsing library (picocli, jcommander or commons-cli) to ease >> the addition of command line options. It may also bring help/manpage >> generation, tab completion, colored messages. > Are we at the point where we need one? The lack of proper command line parsing will quickly become a deterrent to the addition of new features. I hesitated to add the -verbose option due to this. We'll probably need a -force flag to confirm inplace migration, a -quiet flag wouldn't be unusual. The main method will quickly turn into spaghetti code without a library. > I'd opt for Commons CLI if I had to choose but I'm not really familiar > with any of the options to judge relative pros/cons. Having maintained Commons CLI some time ago I know it well, it's quite compact but it shows its age now compared to more recent alternatives. JCommander is annotation based and more concise. Picocli is the most advanced I think, it supports help usage and manpage generation, tab completion and ANSI coloring. But it's a 350K dependency, so harder to sell I guess. >> - Support in-place migration of directories. I've implemented it for >> single files but it looks a bit dangerous for whole directories. I think >> it'd be safer to ask the user to confirm first. > > I'd be happy to allow this for a build system without confirmation. I'm > not sure I'd want to allow it at all outside of that (including single > files). The opportunity for shooting yourself in the foot if the > migration fails is significant. I'd rather the tool forced a safe > approach of writing the migrated content to a new location. What about safe by default, and a command line option to allow it? >> - In memory buffering. The converters read and write directly to the >> disk, writing first to memory and then to the disk speeds up the >> migration (on my system it halved the migration time of the Tomcat >> source tree). > > I'm wondering about buffer size vs performance benefit. Is there a point > where a larger buffer doesn't help much more? I'm thinking about memory > constrained systems and whether there is a sensible fixed buffer size we > can use, or whether the buffer size should be configurable and if so, > with what default? I'm thinking about a mixed approach, with buffering for small files (let's say under 1MB) and direct write for the others, so the heap usage remains moderate. Emmmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated (397ff8a -> c4e5c18)
Le 07/04/2020 à 12:24, Mark Thomas a écrit : > +1 to all of the above. Thank you for the review. >> new 3618367 Renamed NoOpConverter to PassThroughConverter > > What problem does this commit address and/or what new feature does it > add? It looks more like a personal preference for a different name to me. I've found "NoOp" to be confusing, at first glance based on the name I thought it was an empty implementation of the Converter interface, and I was wrong since it actually copies the source unmodified. I think the term "pass-through" better describes the behavior of the converter. > I think there is less likelihood of conflict if there is a technical > justification for a change, and, if the justification is not / might not > be obvious then mention it in the commit message. Ok, I tend to write concise commit messages but I'll try to elaborate in this kind of situation. > This tests creates a file but doesn't remove it afterwards. Tests that > create files should remove those files on completion. It might be worth > considering creating such files in a temporary location rather than in > the source tree. I agree this can be improved. > Generally, the code was clean (no IDE warnings) and the aim is to keep > it this way as it enables errors to be spotted more easily. This is no > longer the case after the above changes. The unused charset parameter is > flagged as a warning. Sorry, for some reason my IDE was misconfigured and no longer highlighted unused code. I'll fix that. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Jakarta EE migration tool improvements
Hi, So I've started working on the Jakarta EE migration tool. I've some enhancements in mind but I'd like to ensure there is a consensus before proceeding. Here are my suggestions: - Turn the tool into a plugin for the main build systems (Maven, Gradle, Ant) to easily post process the jar/war files generated by a project. I've some experience on this side with my jsign project (https://github.com/ebourg/jsign) and I suggest adopting a similar multi module structure with separate artifacts. - Use a CLI parsing library (picocli, jcommander or commons-cli) to ease the addition of command line options. It may also bring help/manpage generation, tab completion, colored messages. - Parallel processing of directories, and maybe of archives too but that's trickier. - Support in-place migration of directories. I've implemented it for single files but it looks a bit dangerous for whole directories. I think it'd be safer to ask the user to confirm first. - In memory buffering. The converters read and write directly to the disk, writing first to memory and then to the disk speeds up the migration (on my system it halved the migration time of the Tomcat source tree). What do you think? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Jakarta EE migration tool release
Hi all, I'd like to start packaging the Jakarta EE migration tool for Debian since it's now a prerequisite to build Tomcat 10. For that I'd need a recent tag, do you think we could tag the current code as 0.0.2? Do we need a formal vote at this stage? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] 01/03: Replaced NonClosing{In, Out}putStream with the equivalent classes from Commons IO
Le 07/04/2020 à 09:41, Rémy Maucherat a écrit : > Reimplemeting ... It was already done, and this was a better trivial > solution. This is a veto (unlike Mark I will not withdraw it), so please > revert this commit. Remy, this is honestly more a rant on an insignificant detail than a reasonably justified veto. It doesn't affect the correctness, the performance or the maintainability of the tool. I'm tempted to translate this as "Don't touch my project" and an incitation to go work on something else. The dependency graph of this tool is very likely to grow as its features expand (think about adding a CLI parser, providing the tool as a Maven/Gradle plugin or an Ant task), and I wouldn't be surprised to see Commons IO brought to the classpath sooner or later anyway (or the overhead diluted). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated (5c96c0b -> 61ba095)
Le 07/04/2020 à 10:12, Mark Thomas a écrit : > The dependencies are only embedded to create a single JAR to make it > easier for users to use on the command line. If the code was re-used I'd > expect the "standard" JAR to be used and leave the decision on how to > handle the dependencies up to the integrator. Ok, I assumed the shaded jar was the main artifact. As long as it isn't published to Maven Central I'm fine with removing the relocation. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated (5c96c0b -> 61ba095)
Le 06/04/2020 à 18:33, Mark Thomas a écrit : > OK. But that is still 7.2k of classes rather than 2.4k of classes for > zero benefit. > > I'll withdraw my -1 because we are approaching the point where the > differences aren't worth the time spent discussing them but I still > don't like this change. I've removed the duplicated Apache license in the shaded jar, so the difference is now near zero. I agree this change is trivial and doesn't bring significant changes. Apache Commons was created to share and reuse common code used at the ASF, I always feel a bit sad when the code produced there isn't reused. > And the relocation of the dependencies? At the moment, I only see a > downside (harder debugging). What is the benefit? Relocating embedded dependencies is a best practice to prevent classpath conflicts. If the tools ends up being integrated in a bigger software it could clash with another version of BCEL on the classpath. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated (5c96c0b -> 61ba095)
Le 06/04/2020 à 17:50, Mark Thomas a écrit :
>> from 5c96c0b Ignore the IntelliJ project files
>> new 29ea189 Replaced NonClosing{In,Out}putStream with the equivalent
>> classes from Commons IO
>
> -1. It adds 220k of bloat for no benefit.
No the dependencies are shaded with the minimizeJar option enabled, only
the classes used are kept in the final jar.
>> new 528ccfa Made the internal classes package private
>
> I am close to -1 on this change.
>
> I would rather these were left public at this stage in the development
> of this tool to make it as easy as possible for folks to tinker with
> this code, re-using the bits that work for them. Longer term I had the
> possibility in mind that users might need to register custom Converters
> so making that package private seems very out of place.
>
> I get that we can always relax visibility rules later but this change
> looks premature to me.
Ok sounds fair, I've reverted it.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] 01/03: Replaced NonClosing{In, Out}putStream with the equivalent classes from Commons IO
Le 06/04/2020 à 15:38, Rémy Maucherat a écrit :
> commit 29ea1891489060f3b3e40259098def5ae47645ef
> Author: Emmanuel Bourg mailto:ebo...@apache.org>>
> AuthorDate: Mon Apr 6 15:24:35 2020 +0200
>
> Replaced NonClosing{In,Out}putStream with the equivalent classes
> from Commons IO
>
>
> Ah, the beauty of having Maven. Actual benefit: zero. Trouble with
> updating dependencies: one. Possible incompatibilities: one.
> So I think it's a total of -2 for the commit.
Sorry but I'm not sure to understand your objection. Commons IO is dead
stable, these classes have been around for over 10 years and haven't
changed much since. There is really no point reimplementing them.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.0.0-M4
Le 03/04/2020 à 13:28, Mark Thomas a écrit : > The proposed 10.0.0-M4 release is: > [ ] Broken - do not release > [X] Alpha - go ahead and release as 10.0.0-M4 Good in Debian with OpenJDK 11. Just got taglibs related test failures because the jars haven't been migrated yet. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.34
Le 03/04/2020 à 14:49, Mark Thomas a écrit : > The proposed 9.0.34 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.34 All good in Debian. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
Le 24/02/2020 à 17:33, Christopher Schultz a écrit : > Any ideas? I guess you are cherry picking the merge commit, instead of the actual commit(s) from the PR branch. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Tomcat 7.0.x EOL as 31 March 2021
Debian 8 is the last release to ship Tomcat 7 and the extended support will end in June 2020. Ubuntu 16.04 LTS also has Tomcat 7 and support will stop in April 2021. The proposed date looks good to me. +1 Emmanuel Bourg Le 21/02/2020 à 10:52, Mark Thomas a écrit : > All, > > This has been mentioned in various threads and I don't recall any > objections. I think it is time for a vote so we can formally announce this. > > Announce the EOL date for 7.0.x as 31 March 2021 > > [ ] Yes > [ ] No, because... > > Thanks, > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Le 11/10/2019 à 16:20, Rémy Maucherat a écrit : > Should private branches be allowed in the official Tomcat git repository ? > [X] Yes > [ ] No +1 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.27
Le 07/10/2019 à 13:51, Mark Thomas a écrit : > The proposed 9.0.27 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.27 Tested on Debian with OpenJDK 11.0.5+6, OpenSSL 1.1.1d and Tomcat Native 1.2.23. No failure on the 3 test suites. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)
>> Yes, basically I think we should remove both CGI and SSI, *but* actually >> keep them in a separate JAR. For CGI this is harder as it is directly in >> the servlets package, so it would have to be moved to servlets.cgi for >> Tomcat 10. +1, these things could be modularized and shared between Tomcat versions. Or even with other webapp containers if they don't really need to leverage Tomcat internal code. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.26
Le 16/09/2019 à 18:15, Mark Thomas a écrit : > The proposed 9.0.26 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.26 Tested on Debian with OpenJDK 11.0.5+6, OpenSSL 1.1.1d and Tomcat Native 1.2.23. No failure on the 3 test suites. Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: CI is back
Le 19/07/2019 à 13:20, Rémy Maucherat a écrit : > But we want to build an installer for Windows using it. Does that > actually work with your Linux package ? Yes it does. At work I build all my NSIS Windows installers from a CI server running on Debian. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: CI is back
Le 16/07/2019 à 10:39, Mark Thomas a écrit : > On July 15, 2019 11:08:22 PM UTC, "Rémy Maucherat" wrote: > > That is by design. NSIS 3.x wasn't compatible with the version of WINE > available on the CI server. That might have changed with the OS upgrade. > > From memory (I only have my phone and a poor internet connection at present) > the properties are overridden in the buildbot config file we can edit. Is WINE really necessary? NSIS is also available on Linux, if the CI server uses Debian or Ubuntu a package is even available [1]. Emmanuel Bourg [1] https://tracker.debian.org/pkg/nsis - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat-Native - Time to move to git?
Le 17/06/2019 à 18:56, Mark Thomas a écrit : > The complication is the svn:external that picks up the > org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git, > this no longer works. Has it been considered to move the org.apache.tomcat.jni package from tomcat to tomcat-native? Since these Java classes are the counterpart of the native code, always evolving in sync, it would be sensible to have them in the same project. > I looked at a workaround using the "GitHub makes itself look like svn" > but that timed out for the Tomcat repo. I suspect due to size. > > I then looked at Git based solutions. sub-modules and sub-trees look to > be the two options. Of the two, sub-trees looks better: > - it is more suited to "read-only" importing > - it doesn't require any additional commands to populate the imported > code What is the workflow to use git subtrees? I googled quickly yesterday and it didn't seem that simple, but maybe I'm missing something. My understanding is that the subtree has to be explicitly configured with non trivial commands after a 'git clone'. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: javax.tools based JSP compiler
Le 13/05/2019 à 12:17, Mark Thomas a écrit : > If I am understanding this all correctly, the proposed way forward is to > (eventually) replace the Ant compiler with the JSR199 based Javac > compiler? If so, then +1 from me. I mostly aim at providing an easy way to use the new language features in JSPs, removing the legacy Ant compiler is a bonus. This perspective raises a couple of questions: - When the Ant compiler could be deprecated/removed? Should we deprecate in Tomcat 9.0.x and remove in 10, or deprecate in Tomcat 10 and remove in 11? - What should be done with the JspServlets configured to use Ant once the compiler is deprecated/removed? Throw an error or redirect to the new javac compiler? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: javax.tools based JSP compiler
Le 11/05/2019 à 00:46, Emmanuel Bourg a écrit : > - I'm not sure about the performance, ECJ was known to be faster than > javac in the past but I don't know if it's still true today. I ran a quick test on an old Core 2 Duo with a SSD, compiling Tomcat and another Ant based project of mine. The Eclipse compiler is still faster than javac, by ~40%. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: javax.tools based JSP compiler
Le 09/05/2019 à 00:34, Mark Thomas a écrit : > +1 > > Need to remove the @author tags and add some info on how to configure > jasper to use them. Ok will do. > A few daft questions: > > 1. If we used the JSR199Complier by default would that allow us to > remove the Eclipse compiler as a dependency? The JSR199 compiler has some drawbacks : - It requires a full JDK (the Eclipse compiler just needs a JRE). This will be less of an issue in the future since there is no JRE anymore after Java 8. - It doesn't reuse an existing classloader, it builds its classpath from a list of files. I haven't checked if it works with non-expanded war files, but I guess it doesn't. And it's probably slower (but that may be negligible compared to the compilation time). - I'm not sure about the performance, ECJ was known to be faster than javac in the past but I don't know if it's still true today. So no I don't think it can replace the Eclipse compiler yet. > 2. Why would anyone use the JavacCompiler in preference to JSR199Complier? The JSR199 compiler will indeed render the Ant based one obsolete. It'll make javac directly usable without the Ant dependency. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Applet in the documentation
Hi, We have a clock applet in the documentation illustrating the use of the tag. Applet support has been removed from all browsers now, it's unlikely to be useful anymore. Any objection to drop this example from the documentation? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: javax.tools based JSP compiler
Hi all, I've rebased the javax.tools JSP compiler on top of the current master branch : https://github.com/ebourg/tomcat/tree/jasper-javax-tools-support Please let me know how you feel about this stuff and if it's worth merging. Emmanuel Bourg Le 09/04/2018 à 17:28, Emmanuel Bourg a écrit : > > I've just completed an initial implementation: > > https://github.com/ebourg/tomcat/commit/1272a1b > > I tested with Java 8 and 10 on Windows and it worked fine with the JSP > examples shipped with Tomcat. It allowed me to use the new 'var' syntax > with Java 10. > > Unlike ECJ the javax.tools API cannot take an existing ClassLoader but > expects a list of files. So it is probably slower, and I guess it > doesn't support non unpacked war files. The javax.tools API also > requires the JDK (the JRE has the API but not the underlying > implementation). > > So this compiler is quite equivalent to the Ant based compiler, but at > least it doesn't require an additional jar. > > Emmanuel Bourg > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
Le 07/05/2019 à 09:05, Rémy Maucherat a écrit : > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the > APIs in Tomcat 9 can remain javax.* and users with "old" applications will > still have an up to date fully compatible container for them. +1 > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which would > provide a container for users who want to move to the new "incompatible" > Jakarta specifications. +1 for deferring the package changes to Tomcat 10. The actual impact isn't clear though, the specifications may evolve in a way that maintains a form of backward compatibility as outlined by Mark Struberg (for example jakarta.* classes the extending javax.* ones). It's a bit early to know how this could be handled in Tomcat 10. Once we know how the specs will evolve, I suggest releasing a prototype as soon as possible so everyone can start experimenting with the new namespace. The return of Jakarta Tomcat ;) I wonder if the specifications could be slightly refactored in the process to erase some mistakes, for example renaming ServletRequest.getContentLengthLong() to getContentLength(). The package change could be a great opportunity to tidy up the APIs. > This way, there's an appropriate container for everyone. Mark Struberg > proposed more elaborate strategies using classloader tricks on the ASF > members list, but I'm not sure this is even needed for Tomcat. Would such a classloader work with a native application using GraalVM ? If not I guess we'll rather see build time tools doing the bytecode processing than runtime tools. In this case the actual conversion would indeed be out of scope for Tomcat. > Comments ? Not really happy to waste so much time for a silly trademark policy... Let's hope Oracle's lawyers don't impose the same mess to OpenJDK someday. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, Checkstyle and Gump
Le 20/03/2019 à 23:51, Mark Thomas a écrit : > Any suggestions? Maybe disable Checkstyke for Tomcat 7? It isn't that important for old code in maintenance mode. Backported code is unlikely to have a wildly different formatting style anyway. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.39
Le 14/03/2019 à 14:43, Mark Thomas a écrit : > The proposed 8.5.39 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.39 +1, tested on Debian 10 with OpenJDK 11.0.3+1 and OpenSSL 1.1.1b Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.17
Le 13/03/2019 à 19:23, Mark Thomas a écrit : > The proposed 9.0.17 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.17 > +1, tested on Debian 10 with OpenJDK 11.0.3+1 and OpenSSL 1.1.1b Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: New git based merging workflow?
Le 28/02/2019 à 16:19, Rémy Maucherat a écrit : > Nice try ! :D :P We could also just have a pom.xml file to be used as a mere project descriptor for the IDE, and retain the main build with Ant. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New git based merging workflow?
Le 28/02/2019 à 15:25, Mark Thomas a écrit : > The main reason I don't do that is that I want to have each branch setup > correctly (Java version, dependencies, etc.) in an IDE. Eclipse, at > least, doesn't cope well with that. That sounds like a good reason to use Maven. IntelliJ detects the changes to the pom and then adapts the dependencies and the language level. I don't think this is possible with an Ant based project. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New git based merging workflow?
Le 28/02/2019 à 11:47, Rainer Jung a écrit : > Thanks a bunch. Looks like what I was searching for, will try it. > > Rainer You could play with a single repository too: # Initial setup cd ~/repos git clone g...@github.com:apache/tomcat.git # Commit... cd ~/repos/tomcat # edit files git commit -a -m "Some message" git push # ...and backport git checkout 8.5.x git cherry-pick git push origin 8.5.x git checkout master Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Migrate to git
Le 21/02/2019 à 17:13, Mark Thomas a écrit : > [X] +1 Go ahead with the migration > [ ] -1 Postpone the migration because... Thank you Mark. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Git migration: new branch/tag naming scheme
Le 16/02/2019 à 16:09, Michael Osipov a écrit : > The given approach, for whatsoever reason, performs an uppercase and > replaces dots with underscores. This reduces readability, but also > requires people (esp. package maintainers) to perform sed(1) magic to > convert back and forth. I agree this is cumbersome, we are doing this kind of manipulation in Debian too to compare the version packaged with the latest upstream release. If I remember well this convention is inherited from the CVS era, dots were not allowed in tag names and thus commonly replaced by underscores or dashes. > Approch 1: It will reuse the branch name of the current major version, > excluding master. Thus, we will have the following prefixes: tomcat90-, > tomcat85-, and tomcat70-. Since JDBC Pool remains in place and if it is > released separately the prefix would be jdbc-pool-. The version itself > would remain as-is and simply appended, e.g., 8.5.40, 9.0.25, etc. -0 > Approach 2: A simpler, less redundant approach would be naming the > branches master, 7.0.x, 8.5.x, etc. and get rid of the "tomcat" prefix > at all. The tags would simply be the versions as-is: 8.5.40, 9.0.25, > etc. The Git autocompletion will work here too. +1 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Test Case Ciphers (was: Release Apache Tomcat 8.5.38)
Le 05/02/2019 à 19:02, Igal Sapir a écrit : > Do you get any "missing ciphers" errors or not even that? I always get > some test cases fail due to mismatching ciphers, which I accept as false > positives, so I wonder about that. Yes that's normal, some ciphers are disabled in Debian (IDEA and ARIA). There is a patch adjusting the tests accordingly: https://salsa.debian.org/java-team/tomcat8/blob/master/debian/patches/0021-dont-test-unsupported-ciphers.patch Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.38
Le 05/02/2019 à 13:22, Mark Thomas a écrit : > The proposed 8.5.38 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.38 Tested on Debian with OpenJDK 11.0.2, OpenSSL 1.1.1a and Tomcat Native 1.2.21. No failure on the 3 test suites. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.16
Le 04/02/2019 à 18:00, Mark Thomas a écrit : > The proposed 9.0.16 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 9.0.16 Tested on Debian with OpenJDK 11.0.2, OpenSSL 1.1.1a and Tomcat Native 1.2.21. No failure on the 3 test suites. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New design for the Tomcat website
Le 03/01/2019 à 02:59, Igal Sapir a écrit : > I am working on a new design for the Tomcat website and wanted some > preliminary feedback. > > You can see the first mockup at > http://people.apache.org/~isapir/mockups/tomcat-site-1/ > > Please let me know your thoughts. I miss the left menu, I know it isn't the current trend but it allows quick access to the main resources of the site (and since the last redesign it folds into a hamburger button when there isn't enough space). Also the font is bigger and reduces the number of lines visible. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.37
Le 12/12/2018 à 14:22, Mark Thomas a écrit : > The proposed Apache Tomcat 8.5.37 release is now available for voting. > > The major changes compared to the 8.5.35 release are: > > - Implement the requirements of section 8.2.2 2.c of the Servlet > specification and prevent a web application from deploying if it has > fragments with duplicate names and is configured to use relative > ordering of fragments. > > - The default Servlet no longer overrides a previously set content-type. > > - Update the packaged version of the Tomcat Native Library to 1.2.19 to > pick up the latest Windows binaries built with APR 1.6.5 and OpenSSL > 1.1.1a. > > Along with lots of other bug fixes and improvements. I've tested on Debian Sid with OpenJDK 11.0.1+13 and OpenSSL 1.1.1a, and I've noticed two test failures in TestClientCertTls13 with the three connectors. Is this expected? Testcase: testClientCertPost took 0.77 sec Caused an ERROR Received fatal alert: protocol_version javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:782) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:748) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:722) at org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:61) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Testcase: testClientCertGet took 0.038 sec Caused an ERROR Received fatal alert: protocol_version javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163) at org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:689) at org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:663) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:657) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:651) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:636) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:630) at org.apache.tomcat.util.net.TestClientCertTls13.testClientCertGet(TestClientCertTls13.java:45) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: [VOTE] Release Apache Tomcat 9.0.14
+1, tested on Debian 10 with OpenJDK 11.0.1 and OpenSSL 1.1.1a Emmanuel Bourg Le 06/12/2018 à 22:37, Mark Thomas a écrit : > The proposed Apache Tomcat 9.0.14 release is now available for voting. > > The major changes compared to the 9.0.13 release are: > > - Significant expansion of localisation support with the addition of > Brazilian Portuguese, Korean and Chinese (simplified) as well as > the expansion of coverage for existing languages > > - Refactor back ground processing and various independent thread pools > to use a common executor > > - Update the packaged version of the Tomcat Native Library to 1.2.19 to > pick up the latest Windows binaries built with APR 1.6.5 and OpenSSL > 1.1.1a. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.14/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1199/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_14/ > > The proposed 9.0.14 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 9.0.14 > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: L10n / I18n
Le 08/11/2018 à 15:47, Mark Thomas a écrit : > is that a reason to drop attempts to provide i10n or > is it an indication we aren't doing nearly enough? We can always do more, but considering our limited resources I think it's wise to focus first on the most important areas (ie. messages displayed in web pages vs internal log messages). > Seriously, we (well, those in the community that speak French > fluently - not me) could look to improve those. FTR I did start working on the French translation for jasper this summer but I got dragged to other duties. When looking around the other resource bundles I really wondered if it made sense to translate very technical messages though. > But that brings us back to your original question of whether the > translations are worth it. If (and it is a fairly big if) the > translations were mostly complete and mostly of good quality, would that > change your view? I'm thinking try and improve the translations as a > first step and, if things don't improve, then decide what to do next. If the translations were nearly complete and of good quality I would definitely not suggest dropping them. Yet, I think I'd still configure Tomcat to run in English instead of French because I'm used to the English terminology. > Removing the translations (apart from the UI) feels to be too big a step > to me. That said, I can see how they would be a hindrance rather than a > help to some. Perhaps separating the l10n JARs into user facing and > external would give more options. Admins could remove the translated JAR > for the internal messages and get those messages in English if they > prefer. Or we could ship less or even no translations for internal > messages by default and provide them as a separate download. I don't think rearranging the JARs is necessary, it isn't difficult to run Tomcat with a different locale. I'm more concerned about the maintenance burden and the actual value vs the time invested. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: L10n / I18n
Le 07/11/2018 à 23:36, Mark Thomas a écrit : > WDYT? What about simplifying the issue by dropping the translations of the internal messages and retaining only the user facing messages (things like HTTP error messages that can appear in a normal request) ? I think it's worth considering because: - The target audience of Tomcat is mainly developers and administrators which are used to read English text. - The coverage of the translations is rather low. - Maintaining the translations, the quality and the consistency is difficult and time consuming. - Sometimes the translation of the technical terms are a bit unusual and not as clear as the English counterpart. For example in French it isn't obvious that "gestionnaire de protocole" relates to ProtocolHandler which is an internal Tomcat concept. Other translations are even funny like "enrobeur de conteneur" for "wrapper container" (a pastry concept applied to a freight container?). This issue is so common with the French translation that many messages carry the English terms in parentheses to clarify the meaning. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Release script for Tomcat 8.5.x
Le 07/11/2018 à 10:28, Konstantin Kolinko a écrit : > If I cannot do something with a batch script, I write a shell (bash) > script and run it with git-bash from Git for Windows. There is also that thing named Ant that was designed to replace batch and shell scripts to build Java projects on any platform ;) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.35
Le 03/11/2018 à 18:55, Mark Thomas a écrit : > The proposed 8.5.35 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 8.5.35 +1 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.35
Le 06/11/2018 à 12:44, Mark Thomas a écrit : > Should be fixed now. > There were some robustness fixes in 9.0.x that had not been back-ported. > I've just done that. I confirm it works, thank you. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.35
I got two issues when building Tomcat 8.5.35 with OpenJDK 11 and OpenSSL 1.1.1 in Debian. 1. testClientCertPost and testClientCertGet in TestClientCertTls13 failed with the three NIO/NIO2/APR connectors: javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:782) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:748) at org.apache.catalina.startup.TomcatBaseTest.postUrl(TomcatBaseTest.java:722) at org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:75) 2. testAbortedUploadLimitedNoSwallow and testAbortedPOST413NoSwallow failed with NIO only: Testcase: testAbortedUploadLimitedNoSwallow took 0.106 sec FAILED Limited upload with swallow disabled does not generate client exception junit.framework.AssertionFailedError: Limited upload with swallow disabled does not generate client exception at org.apache.catalina.core.TestSwallowAbortedUploads.testAbortedUploadLimitedNoSwallow(TestSwallowAbortedUploads.java:130) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Testcase: testAbortedPOST413NoSwallow took 0.036 sec FAILED Limited upload with swallow disabled does not generate client exception junit.framework.AssertionFailedError: Limited upload with swallow disabled does not generate client exception at org.apache.catalina.core.TestSwallowAbortedUploads.testAbortedPOST413NoSwallow(TestSwallowAbortedUploads.java:176) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Emmanuel Bourg Le 03/11/2018 à 18:55, Mark Thomas a écrit : > The proposed Apache Tomcat 8.5.35 release is now available for voting. > > The major changes compared to the 8.5.34 release are: > > - support for TLSv1.3 when used with a JRE or OpenSSl version that > supports it > > - multiple improvements to the RewriteValve > > - correct several regressions in the JSP compiler > > > Along with lots of other bug fixes and improvements. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.35/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1197/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_35/ > > The proposed 8.5.35 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 8.5.35 > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.34
Le 05/09/2018 à 00:52, Mark Thomas a écrit : > [X] Stable - go ahead and release as 8.5.34 +1, tested NIO/NIO2/APR on Debian with OpenJDK 10 and OpenSSL 1.1.1 Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: tomcat-native trunk
Le 03/09/2018 à 11:41, Mark Thomas a écrit : > No strong views on which build system to use but I will say that Gradle > might be worth a look. With my Debian maintainer hat on I have to say that Gradle is a real hindrance and I hope the Tomcat components will stay out of it. Gradle itself is a behemoth that is very difficult to maintain, as a build system it has little respect for backward compatibility, and its imperative nature quickly turns build files into a non standard, project specific, mess. Gradle is barely an improvement over Ant IMHO, but at least Ant is stable and really cares about backward compatibility. Beyond Ant I think a declarative build system like Maven is a saner choice. The tomcat-native fork maintained by netty [1] is built with Maven, maybe we could get some inspiration from it. Emmanuel Bourg [1] https://github.com/netty/netty-tcnative - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: ant problems
Le 09/08/2018 à 11:18, jean-frederic clere a écrit : > I have problems while building trunk: > /home/jfclere/TMP/tomcat/build.xml:693: javac doesn't support the > "release" attribute > > Is that expected I have tried java11 and java8 (openjdk)? No that's not expected, Java 9+ supports the new --release parameter, but Ant simply ignores it if you use an older version. What's your version of Ant? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Timestamps in the manifests
Hi all, We have 4 timestamps in the manifest of our jar files: DSTAMP: 20180806 TSTAMP: 1443 TODAY: August 6 2018 Bnd-LastModified: 1533578685288 Are they really necessary? This doesn't help making the generated files reproducible [1]. Any objection to remove the DSTAMP, TSTAMP and TODAY attributes? Emmanuel Bourg [1] https://reproducible-builds.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Message files encoding
Le 01/08/2018 à 16:34, Mark Thomas a écrit :
> I think there is a little more work to be done. Currently the files are
> corrupted when I look at them in an IDE. I've tried playing with
> svn:mimetype without much luck.
With IntelliJ the encoding is automatically detected as UTF-8, but I had
to restart the IDE otherwise it kept seeing them as ISO-8859-1 files and
started corrupting them. Invalidating the caches may also help ("File ->
Invalidate Caches / Restart" in IntelliJ). If it doesn't work there is a
per-project encoding for properties files that can be configured from
File -> Settings -> Editor -> File Encodings -> Properties Files.
Ironically I just noticed the 'Transparent native-to-ascii conversion'
checkbox there.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
