Re: [VOTE] Release Apache Tomcat 10.1.9
All, On 5/9/23 12:12 PM, Christopher Schultz wrote: The proposed Apache Tomcat 10.1.9 release is now available for voting. The notable changes compared to 10.1.8 are: - Many improvements to the JSON access log valve. - Deprecate support for the HTTP Connector settings rejectIllegalHeader and allowHostHeaderMismatch and reject HTTP headers without names. - Add a RateLimitFilter which can be used to mitigate DoS and Brute Force attacks. 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.9/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1435 The tag is: https://github.com/apache/tomcat/tree/10.1.9 5d45c1a9359c2298d7140c1ca90cb8c43809a168 The proposed 10.1.9 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 10.1.9 +1 for stable release. Unit test pass on MacOS on Intel. Failing unit tests are expected in this environment. Details: * Environment * Java (build): java version "11.0.7" 2020-04-14 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode) * Java (test): java version "11.0.7" 2020-04-14 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode) * OS: Darwin 21.6.0 x86_64 * cc: Apple clang version 12.0.0 (clang-1200.0.31.1) * make: GNU Make 3.81 * OpenSSL: OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) * APR: 1.7.0 * * Valid SHA-512 signature for apache-tomcat-10.1.9.zip * Valid GPG signature for apache-tomcat-10.1.9.zip * Valid SHA-512 signature for apache-tomcat-10.1.9.tar.gz * Valid GPG signature for apache-tomcat-10.1.9.tar.gz * Valid SHA-512 signature for apache-tomcat-10.1.9.exe * Valid GPG signature for apache-tomcat-10.1.9.exe * Valid SHA512 signature for apache-tomcat-10.1.9-src.zip * Valid GPG signature for apache-tomcat-10.1.9-src.zip * Valid SHA512 signature for apache-tomcat-10.1.9-src.tar.gz * Valid GPG signature for apache-tomcat-10.1.9-src.tar.gz * * Binary Zip and tarball: Same * Source Zip and tarball: Same * * Building dependencies returned: 0 * tcnative builds cleanly * Tomcat builds cleanly * Junit Tests: FAILED * * Tests that failed: * org.apache.catalina.filters.TestRateLimitFilter.NIO.txt * org.apache.catalina.filters.TestRateLimitFilter.NIO2.txt * org.apache.tomcat.util.net.jsse.TestPEMFile.NIO.txt * org.apache.tomcat.util.net.jsse.TestPEMFile.NIO2.txt * org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt * org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt * org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO.txt * org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfigurationParser.NIO2.txt -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JDK 21 EA builds 22 & Sequenced Collections Heads-up
Welcome to the latest OpenJDK Quality Outreach update! The schedule for JDK 21 is now known [1] with Rampdown Phase One (RDP1) phase set for June 8th and General Availability (GA) set for September 19th. As we are getting closer to RDP1, we are gradually getting a better view on the JDK 21 content. At the time of writing, 5 JEPs are already integrated in the JDK 21 mainline - Virtual Threads, Generational ZGC, etc. – see below for more details. This newsletter heads-up is focused on one of those JEPs; i.e., JEP 431 Sequenced Collections, as it might induce some incompatibilities on existing codebases. Please do tell us if your project works or fails on the latest JDK 21 Early-Access builds. We still have some time to fix issues before JDK 21 reaches General Availability. [1] https://openjdk.org/projects/jdk/21/ ## Heads-Up - JDK 21: Potential Sequenced Collections Incompatibilities The Sequenced Collection JEP [2] has been integrated into JDK 21, build 20. This JEP introduces several new interfaces into the collections framework’s interface hierarchy, and these interfaces introduce new default methods. When such changes are made, they can cause conflicts that result in source or binary incompatibilities. Any conflicts that occur will be in code that implements new collections or that subclasses existing collection classes. Code that simply uses collections implementations will be largely unaffected. There are several kinds of conflicts that might arise. The first is a simple method naming conflict, if a method already exists with the same name but with a different return type or access modifier. Another is a clash between different inherited default method implementations arising from covariant overrides. A class might inherit multiple default methods if it implements multiple interfaces from different parts of the collections framework. A third example occurs with type inference. With type inference (e.g., the use of `var`) the compiler will infer a type for that local variable. It’s possible for other code to use explicitly declared types that must match the inferred type. The change to the interface hierarchy might result in a different inferred type, causing an incompatibility. Make sure to check the following article [3] that provides additional details and strategies to mitigate potential incompatibilities. [2] https://openjdk.org/jeps/431 [3] https://inside.java/2023/05/12/quality-heads-up/ Additional Sequenced Collections resources are also listed in the 'Topics of Interest' section below. ## JDK 21 Early-Access builds The latest Early-Access builds 22 are available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [5] and the Javadocs [6] are also available. [4] https://jdk.java.net/21/ [5] https://jdk.java.net/21/release-notes [6] https://download.java.net/java/early_access/jdk21/docs/api/ ### JEPs integrated to JDK 21, so far: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 442: Foreign Function & Memory API (3rd Preview) - 444: Virtual Threads ### JEPs targeted to JDK 21, so far: - 440: Record Patterns - 441: Pattern Matching for switch - 448: Vector API (6th Incubator) JEPs proposed to target JDK 21: - 404: Generational Shenandoah (Experimental) - 443: Unnamed Patterns and Variables (Preview) - 445: Unnamed Classes and Instance Main Methods (Preview) - 449: Deprecate the Windows 32-bit x86 Port for Removal ### Changes in recent builds that may be of interest: Note that this is only a curated list of changes, make sure to check https://github.com/openjdk/jdk/compare/jdk-21+0...jdk-21+22 for additional changes. JDK 21 Build 22: - JDK-8307466: java.time.Instant calculation bug in until and between methods - JDK-8307399: get rid of compatibility ThreadStart/ThreadEnd events for virtual threads - JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions - JDK-8280031: Deprecate GTK2 for removal - JDK-8307629: FunctionDescriptor::toMethodType should allow sequence layouts (mainline) - JDK-8302845: Replace finalizer usage in JNDI DNS provider with Cleaner - JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions - JDK-8306881: Update FreeType to 2.13.0 - JDK-8285932: Implementation of JEP 430 String Templates (Preview) - JDK-8307301: Update HarfBuzz to 7.2.0 - JDK-8159337: Introduce a method in Locale class to return the language tags as per RFC 5646 convention - JDK-8291555: Implement alternative fast-locking scheme - JDK-8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern JDK 21 Build 21: - JDK-8305092: Improve Thread.sleep(millis, nanos) for sub-millisecond granularity - JDK-8303784: no-@Target annotations should be applicable to type parameter declarations - JDK-8303002:
[Bug 66600] NPE in certain scenarios
https://bz.apache.org/bugzilla/show_bug.cgi?id=66600 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- Bugzilla is not a support forum. Please use the users mailing list for support. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66600] New: NPE in certain scenarios
https://bz.apache.org/bugzilla/show_bug.cgi?id=66600 Bug ID: 66600 Summary: NPE in certain scenarios Product: Tomcat 9 Version: 9.0.75 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: boris_pet...@live.com Target Milestone: - I'm not exactly sure when. I think it happens when some requests that take a very long time in the beginning (before some caches are populated). Here is a stacktrace: ERROR o.g.j.server.ServerRuntime$Responder - Error while closing the output stream in order to commit response. java.lang.NullPointerException: Cannot invoke "org.apache.tomcat.util.net.SocketWrapperBase.flush(boolean)" because "this.this$0.socketWrapper" is null at org.apache.coyote.http11.Http11OutputBuffer$SocketOutputBuffer.flush(Http11OutputBuffer.java:566) at org.apache.coyote.http11.filters.ChunkedOutputFilter.flush(ChunkedOutputFilter.java:157) at org.apache.coyote.http11.Http11OutputBuffer.flush(Http11OutputBuffer.java:220) at org.apache.coyote.http11.Http11Processor.flush(Http11Processor.java:1246) at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:398) at org.apache.coyote.Response.action(Response.java:207) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:271) at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:118) at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.flush(ResponseWriter.java:307) at org.glassfish.jersey.message.internal.CommittingOutputStream.flush(CommittingOutputStream.java:263) at org.glassfish.jersey.message.internal.OutboundMessageContext.close(OutboundMessageContext.java:864) at org.glassfish.jersey.server.ContainerResponse.close(ContainerResponse.java:389) at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:721) at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:380) at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:370) at org.glassfish.jersey.server.ServerRuntime$AsyncResponder$3.run(ServerRuntime.java:871) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244) at org.glassfish.jersey.internal.Errors.process(Errors.java:292) at org.glassfish.jersey.internal.Errors.process(Errors.java:274) at org.glassfish.jersey.internal.Errors.process(Errors.java:244) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265) at org.glassfish.jersey.server.ServerRuntime$AsyncResponder.resume(ServerRuntime.java:903) at org.glassfish.jersey.server.ServerRuntime$AsyncResponder.resume(ServerRuntime.java:859) ... Any ideas? Is that a bug in Tomcat or I've done something wrong? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
On Sat, May 13, 2023 at 10:48 AM Mark Thomas wrote: > > On 12/05/2023 22:24, Rémy Maucherat wrote: > > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas wrote: > >> We would normally make Java 21 the minimum Java version. Given that Java > >> 21 is still in EA, I don't plan to do that yet. > > > > Since the update to Java 21 has now been made and seems to make > > everyone happy, I would like to discuss Panama. > > > > - Panama as it is right now removes the need for tomcat-native 2.0. It > > is stable, fast enough, works out of the box, is much much better for > > cloud environments (no funny custom binary to add, only the usual > > Java), and so on. Actually, all of these statements were already true > > with Java 17, although the API was a bit rougher. Unfortunately at the > > moment, it is still preview in Java 21. > > - It is possible to include the support right now, but since the API > > would change in Java 22, then Tomcat 11 (or at least that feature) > > would only target Java 21. Compilation would have to occur on Java 21. > > - Support for Java 21 ends in 2028. This means then there would be a > > needed API update to Java LTS.next, dropping support for Java 21 (for > > that feature), and causing a more complex build (targeting Java 21 > > with a newer Panama API would cause the compiler to scream). > > - Multi release JARs are an option, but this is annoying as it would > > require multiple Java versions to build Tomcat (since it is a preview > > API), then assemble the multi release JAR. Not looking too good ... > > > > Given all this, there are two main options: > > A) (unfortunately) *not* including the Panama support until it is non > > preview. Once this happens, then my proposal would be to update the > > minimum build Java version (not runtime !) for Tomcat 11, add the > > Panama "final API" support, and use the release option to still target > > 21 (except for the Panama feature classes, of course, which would be > > compiled separately). Also as a consequence tomcat-native 2 would have > > to be supported for the entire lifecycle of Tomcat 11. > > B) Add full support using Java 21, drop tomcat-native. Once Java > > LTS.next is released towards the end of 2025 (with non preview Panama, > > hopefully), update to use the new API. Users of OpenSSL will have to > > move to Java LTS.next > > > > Although I would like B), A) seems more reasonable and in line with > > our support practices. > > > > Comments ? > > Is there any chance Panama will come out of preview in Java 21? I doubt it, the jep has been filed as a preview. https://openjdk.org/jeps/442 This is disappointing since the progress since 19 has been small. > OpenSSL supports versions for less time than the typical support period > for a major Tomcat version (10 years). And then you have the Linux > distributions that have specific OpenSSL versions and their support > periods. With Tomcat Native we have been able to manage this reasonably > well without too much maintenance burden for us. > > How would this work with different versions of OpenSSL? Is it possible > to support multiple OpenSSL versions? I did it as an experiment with 1.1 and 3.0, and there's no real problem since OpenSSL is rather conservative with API changes. Technically, there are more changes than normally needed since the functional macros that are introduced for API compatibility in the OpenSSL code do not work for Panama. > Of the two options you present, I agree that option A is more in-line > with how we typically do things (as much as I would like to say goodbye > to native code). +1 Rémy > > 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
