Re: JDK 19 first Release Candidates!

[Martin Grigorov]

Hi David,

Apache Tomcat's build and tests pass successfully with JDK 19 b36 and 20
b11 on both Ubuntu x86_64 and openEuler OS ARM64.

Regards,
Martin

On Mon, Aug 22, 2022 at 4:23 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> I hope you had a chance to take some time off. On our side, and despite
> the summer vacation, everything is on track for the Java 19 GA release
> on September 20th with JDK 19 now in the Release Candidate Phase [1]. If
> you haven't done so yet, it is time to start testing your project(s)
> using JDK 20 Early-Access builds. Speaking of Early-Access builds, there
> is now a new set of EA builds, i.e., the jextract EA builds. jextract is
> a tool developed under the Project Panama umbrella whose goal is to
> mechanically generates Java bindings from native library headers. If you
> are using the Foreign Function & Memory API (Preview Feature in JDK 19),
> make sure to check jextract too (see the jextract section below).
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006861.html
>
>
> ## Heads-up - New system properties for `System.out` and `System.err` in
> JDK 19
>
> Two new system properties, `stdout.encoding` and `stderr.encoding`, have
> been introduced. The value of these system properties is the encoding
> used by the standard output (`System.out`) and standard error
> (`System.err`) streams. The default values of these system properties
> depend on the platform. The values take on the value of the
> `native.encoding` property when the platform does not provide streams
> for the console. The properties can be overridden on the launcher's
> command line option, with `-D`, to set them to UTF-8 where required. For
> more details see https://bugs.openjdk.org/browse/JDK-8283620
>
>
> ## Heads-up - SSLSocketImpl finalizer implementation removed in JDK 19
>
> The finalizer implementation in SSLSocket has been removed, with the
> underlying native resource releases now done by the Socket
> implementation. With this update, the TLS close_notify messages will no
> longer be emitted if SSLSocket is not explicitly closed. Not closing
> Sockets properly is an error condition that should be avoided.
> Applications should always close sockets and not rely on garbage
> collection. For more details see
> https://bugs.openjdk.org/browse/JDK-8212136
>
>
> ## Heads-up - New providerPath jarsigner option in JDK 19
>
> A new `-providerPath` option has been added to the jarsigner. This
> option is used to specify the class path of an alternate keystore
> implementation, it can be used together with the -providerClass option.
> For more details see https://bugs.openjdk.org/browse/JDK-8281175
>
>
> ## JDK 19 Release Candidate builds
>
> JDK 19 first Release Candidates (builds 36) are now available [2], and
> are provided under the GNU General Public License v2, with the Classpath
> Exception. The Release Notes are available here [3].
>
> [2] https://jdk.java.net/19/
> [3] https://jdk.java.net/19/release-notes
>
>
> ## JDK 20 Early-Access builds
>
> JDK 20 Early-Access builds 11 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [5].
>
> [4] https://jdk.java.net/20/
> [5] https://jdk.java.net/20/release-notes
>
> ### Recent changes that maybe of interest:
>
> - JDK-8282730: LdapLoginModule throw NPE from logout method after login
> failure
> - JDK-8290706: Remove the support for inline contiguous allocations
> - JDK-8289551: Conversions between bit representations of half precision
> values and floats
> - JDK-8290485: [vector] REVERSE_BYTES for byte type should not emit any
> instructions
> - JDK-8289137: Automatically adapt Young/OldPLABSize and when setting
> only MinTLABSize
> - JDK-8290034: Auto vectorize reverse bit operations.
> - JDK-8290868: NMT: MallocSiteTable statistics improvements
> - JDK-8291822: ARM32: Build errors with GCC 11 in
> frame::saved_oop_result [Reported by JaCoCo]
> - JDK-8289249: Add methods to Elements for record constructors
> - JDK-8283232: x86: Improve vector broadcast operations
> - JDK-8288327: Executable.hasRealParameterData should not be volatile
> - JDK-8291360: Create entry points to expose low-level class file
> information
> - JDK-8290840: Refactor the "os" class
> - JDK-8292327: InflaterInputStream.read throws EOFException
> - JDK-8155246: Throw error if default java.security file is missing
> - JDK-8289332: Auto-generate ids for user-defined headings
> - JDK-8292153: x86: Represent Registers as values
>
>
> ## Jextract Early-Access Builds
>
> Early Access Builds 19-jextract+2-3 (2022/7/19) are now available [6].
> These open-source builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception.
>
> These builds are from the OpenJDK jextract project [7] which is part of
> Code Tools [8]. jextract is a tool developed under the Panama umbrealla
> whose goal is to mechanically generate 

Re: JDK 19: Rampdown Phase 2 + JavaOne

[Martin Grigorov]

Hi David,

Apache Tomcat build and tests pass successfully with JDK 19-ea+32-2220
and 20-ea+7-379 on Ubuntu 20.04 x86_64 and openEuler 20.03 aarch64 !

Regards,
Martin

On Mon, Jul 25, 2022 at 6:06 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> JDK 19 is now in Rampdown Phase Two [1]. The overall feature set is
> frozen. Per the JDK Release Process [2] we now turn our focus to P1 and
> P2 bugs, which can be fixed with approval [3]. Late enhancements are
> still possible, with approval, but the bar is now extraordinarily high [4].
>
> Given the current state of affairs, it is a good time to start testing
> your project(s) on JDK 20 Early-Access builds. To conclude, please make
> sure to check the heads-up below, including the one covering JavaOne!
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-July/006803.html
> [2] https://openjdk.org/jeps/3
> [3] https://openjdk.org/jeps/3#Fix-Request-Process
> [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process
>
>
> ## Heads-up - JavaOne is back!
>
> After a long hiatus, JavaOne is back! From October 17-20 in Las Vegas,
> JavaOne will be jam-packed with hundreds of valuable and actionable
> sessions directly from the experts: learning sessions, tutorials,
> hands-on labs, lightning talks, panels, an unconference, BoF's, etc. The
> full JavaOne content catalog will be released soon. In the meantime,
> make sure to check https://inside.java/javaone/ for more updates.
>
> And if you are planning to attend JavaOne, please ping me. I'd like to
> meet you in person to chat over OpenJDK and the Quality Outreach
> program. And the drinks will be on me!
>
>
> ## Heads-up - JavaFX Media enhancements survey
>
> The JavaFX team is conducting a short survey [5] to gather input on
> potential JavaFX Media enhancements.
> The process is quite simple as the feedback will be collected via the
> openjfx-dev [6] mailing list. So if you are using JavaFX, make sure to
> raise your voice.
>
> [5] https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034949.html
> [6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev
>
>
> ## JDK 19
>
> JDK 19 Early-Access builds 32 are now available [7], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [8].
>
> [7] https://jdk.java.net/19/
> [8] https://jdk.java.net/19/release-notes
>
> ### JEPs integrated to JDK 19:
> - JEP 405: Record Patterns (Preview)
> - JEP 422: Linux/RISC-V Port
> - JEP 424: Foreign Function & Memory API (Preview)
> - JEP 425: Virtual Threads (Preview)
> - JEP 426: Vector API (4th Incubator)
> - JEP 427: Pattern Matching for switch (3rd Preview)
> - JEP 428: Structured Concurrency (Incubator)
>
> ### Recent changes that maybe of interest:
> - JDK-8289127: Apache Lucene triggers: DEBUG MESSAGE: duplicated
> predicate failed which is impossible
> - JDK-8290596: Update java.net.InetAddress to Detect Ambiguous IPv4
> Address Literals
> - JDK-8290615: Remove the Alternate ThreadLocal Implementation of the
> Subject::current and Subject::callAs APIs
> - JDK-8290417: CDS cannot archive lamda proxy with useImplMethodHandle
> - JDK-8287809: Revisit implementation of memory session
> - JDK-8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and
> can_support_virtual_threads
> - JDK-8288589: Files.readString ignores encoding errors for UTF-16
> - JDK-8288425: Footprint regression due MH creation when initializing
> StringConcatFactory
>
>
> ## JDK 20
>
> JDK 20 Early-Access builds 7 are now available [9], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
>
> [9] https://jdk.java.net/20/
>
> ### Recent changes that maybe of interest:
> - JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines
> [Logged by Apache PDFBox]
> - JDK-8284997: arm32 build crashes since JDK-8283326 [Logged by JaCoCo]
> - JDK-8286101: Support formatting in @value tag
> - JDK-8289260: BigDecimal movePointLeft() and movePointRight() do not
> follow their API spec
> - JDK-8287835: Add support for additional float/double to integral
> conversion for x86
> - JDK-8283091: Support type conversion between different data sizes in SLP
> - JDK-8288573: Make Executable.getParameterCount() actually abstract
> - JDK-8266670: Better modeling of access flags in core reflection
> - JDK-8290601: Update java.net.InetAddress to Detect Ambiguous IPv4
> Address Literals
> - JDK-8290334: Update FreeType to 2.12.1
> - JDK-8286030: Avoid JVM crash when containers share the same /tmp dir
> - JDK-8289743: AArch64: Clean up patching logic
> - JDK-8288107: Auto-vectorization for integer min/max
> - JDK-8274235: -Xshare:dump should not call vm_direct_exit
>
>
> ## Topics of Interest:
>
> * What is OpenJDK? - Inside Java Newscast
> https://inside.java/2022/06/30/insidejava-newscast-028/
>
> * “Towards Generational ZGC!” - Inside Java Podcast
> https://inside.java/2022/06/29/podcast-024/
>
> * HotSpot Deep 

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Martin Grigorov]

Hi David,

Apache Tomcat's build and tests pass successfully with JDK 19-ea+26-2060
and 20-ea+1-3 on Linux x86_64 and aarch64!

Regards,
Martin

On Tue, Jun 14, 2022 at 11:00 AM Martin Grigorov 
wrote:

> Hello Tomcat devs,
>
> The following test fails with JDK 19 b26:
>
>  [concat] Testsuites with failed tests:
>[concat] TEST-javax.el.TestImportHandlerStandardPackages.APR.txt
>[concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO.txt
>[concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO2.txt
>
>
> Testsuite: javax.el.TestImportHandlerStandardPackages
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.35 sec
>
> Testcase: testClassListsAreComplete took 0.326 sec
> FAILED
> java.lang.MatchException
> junit.framework.AssertionFailedError: java.lang.MatchException
> at
> javax.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$13(TestImportHandlerStandardPackages.java:87)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/jdk.internal.module.SystemModuleFinders$ModuleContentSpliterator.tryAdvance(SystemModuleFinders.java:573)
> at
> java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:332)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
> at
> javax.el.TestImportHandlerStandardPackages.checkPackageClassList(TestImportHandlerStandardPackages.java:87)
> at
> javax.el.TestImportHandlerStandardPackages.testClassListsAreComplete(TestImportHandlerStandardPackages.java:49)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>
>
> On Mon, Jun 13, 2022 at 4:46 PM David Delabassee <
> david.delabas...@oracle.com> wrote:
>
>> Greetings!
>>
>> JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that
>> the main-line has been forked into a dedicated JDK 19 stabilization
>> repository. At this point, the overall JDK 19 feature set is frozen and
>> no additional JEPs will be targeted to JDK 19. The stabilization
>> repository is open for select bug fixes and, with approval, late
>> low-risk enhancements per the JDK Release Process [2]. Any change pushed
>> to the main line is now bound for JDK 20, unless it is explicitly
>> back-ported to JDK 19.
>>
>> The next few weeks should be leveraged to try to identify and resolve as
>> many issues as possible, i.e. before JDK 19 enters the Release
>> Candidates phase. Moreover, we encourage you to test your project with
>> the `enable-preview` flag as described in this Quality Outreach Heads-up
>> [3], and even if you don't intend to use Virtual Threads in the near
>> future.
>>
>> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html
>> [2] https://openjdk.ja

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Martin Grigorov]

On Tue, Jun 14, 2022 at 10:08 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Martin,
>
> On 6/14/22 14:42, Martin Grigorov wrote:
> > On Tue, Jun 14, 2022 at 3:07 PM Mark Thomas  wrote:
> >
> >>
> >>
> >> On 14/06/2022 09:00, Martin Grigorov wrote:
> >>> Hello Tomcat devs,
> >>>
> >>> The following test fails with JDK 19 b26:
> >>>
> >>>[concat] Testsuites with failed tests:
> >>>  [concat] TEST-javax.el.TestImportHandlerStandardPackages.APR.txt
> >>>  [concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO.txt
> >>>  [concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO2.txt
> >>
> >> Should be fixed now. Just needed to add the new class to the
> optimization.
> >>
> >
> > Any plans to backport it to
> >
> https://github.com/apache/tomcat/blob/9.0.x/java/javax/el/ImportHandler.java
> > ?
> > I am using 9.x for the testing here
>
> I think it was done. Seem commit messages with "Update optimisation for
> new java.lang class added in Java 19" in the subject.
>

Oh! Thanks!
I forgot that the commits to other branches but main are filtered by GMail.
The dev@ list is too loaded :-/



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

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Martin Grigorov]

On Tue, Jun 14, 2022 at 3:07 PM Mark Thomas  wrote:

>
>
> On 14/06/2022 09:00, Martin Grigorov wrote:
> > Hello Tomcat devs,
> >
> > The following test fails with JDK 19 b26:
> >
> >   [concat] Testsuites with failed tests:
> > [concat] TEST-javax.el.TestImportHandlerStandardPackages.APR.txt
> > [concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO.txt
> > [concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO2.txt
>
> Should be fixed now. Just needed to add the new class to the optimization.
>

Any plans to backport it to
https://github.com/apache/tomcat/blob/9.0.x/java/javax/el/ImportHandler.java
?
I am using 9.x for the testing here



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

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Martin Grigorov]

Hello Tomcat devs,

The following test fails with JDK 19 b26:

 [concat] Testsuites with failed tests:
   [concat] TEST-javax.el.TestImportHandlerStandardPackages.APR.txt
   [concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO.txt
   [concat] TEST-javax.el.TestImportHandlerStandardPackages.NIO2.txt


Testsuite: javax.el.TestImportHandlerStandardPackages
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.35 sec

Testcase: testClassListsAreComplete took 0.326 sec
FAILED
java.lang.MatchException
junit.framework.AssertionFailedError: java.lang.MatchException
at
javax.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$13(TestImportHandlerStandardPackages.java:87)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/jdk.internal.module.SystemModuleFinders$ModuleContentSpliterator.tryAdvance(SystemModuleFinders.java:573)
at
java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:332)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
at
javax.el.TestImportHandlerStandardPackages.checkPackageClassList(TestImportHandlerStandardPackages.java:87)
at
javax.el.TestImportHandlerStandardPackages.testClassListsAreComplete(TestImportHandlerStandardPackages.java:49)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)


On Mon, Jun 13, 2022 at 4:46 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 19 stabilization
> repository. At this point, the overall JDK 19 feature set is frozen and
> no additional JEPs will be targeted to JDK 19. The stabilization
> repository is open for select bug fixes and, with approval, late
> low-risk enhancements per the JDK Release Process [2]. Any change pushed
> to the main line is now bound for JDK 20, unless it is explicitly
> back-ported to JDK 19.
>
> The next few weeks should be leveraged to try to identify and resolve as
> many issues as possible, i.e. before JDK 19 enters the Release
> Candidates phase. Moreover, we encourage you to test your project with
> the `enable-preview` flag as described in this Quality Outreach Heads-up
> [3], and even if you don't intend to use Virtual Threads in the near
> future.
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html
> [2] https://openjdk.java.net/jeps/3
> [3] https://inside.java/2022/05/16/quality-heads-up/
>
>
> ## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition
>
> The OpenJDK infrastructure is moving from the old openjdk.java.net
> subdomain to the openjdk.org top-level domain. This will affect all
> active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the
> old hostnames (*.openjdk.java.net) will now act as aliases for the new
> names. No actions are required as this transition should be transparent
> and is mostly done. It should be mentioned that https://jdk.java.net/ is
> not changing.
>
> More infirmation can be found in the original proposal
> 

Re: JDK 19 - Virtual Threads Testing!

[Martin Grigorov]

On Tue, May 17, 2022 at 4:23 PM Rémy Maucherat  wrote:

> On Tue, May 17, 2022 at 12:27 PM Mark Thomas  wrote:
> >
> > On 16/05/2022 14:14, Martin Grigorov wrote:
> > > Hello Tomcat devs,
> > >
> > > Some tests fail with JDK 19-ea+22-1598:
> >
> > 
> >
> > >[concat] Testsuites with failed tests:
> > > [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO.txt
> > > [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO2.txt
> >
> > 
> >
> > > Here are the error types:
> > >
> > >
> > > 1. Testsuite: jakarta.el.TestImportHandlerStandardPackages
> > > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.463
> sec
> > >
> > > Testcase: testClassListsAreComplete took 0.444 sec
> > >  FAILED
> > > java.lang.Thread.Builder.OfPlatform
> > > junit.framework.AssertionFailedError:
> java.lang.Thread.Builder.OfPlatform
> > >  at
> > >
> jakarta.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$12(TestImportHandlerStandardPackages.java:77)
> > >  at
> > >
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> > >  at
> > >
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> > >  at
> > >
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> >
> > I've fixed this one. Looking at the others.
>
> Ok, so since we're now adding support for Java 19 and the current
> trunk has the Panama preview API, I'll add a new "openssl-foreign"
> module that targets it.
>

According to
https://github.com/openjdk/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7
the FF & Memory API is added in b23.
Above we were using b22.

https://jdk.java.net/19/ has been just updated to b23.

Do you want me to update JDK 19 at Buildbot (& Jenkins) to b23 ?



>
> 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
>
>

Re: JDK 19 - Virtual Threads Testing!

[Martin Grigorov]

Hi David,

The issues in Apache Tomcat have been fixed and now everything is OK with
JDK 19-ea+22-1598!

Regards,
Martin

On Mon, May 16, 2022 at 4:14 PM Martin Grigorov 
wrote:

> Hello Tomcat devs,
>
> Some tests fail with JDK 19-ea+22-1598:
>
>   [concat] Testsuites with failed tests:
>[concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO.txt
>[concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1023.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1023.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1024.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1024.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1025.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1025.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite511.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite511.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite512.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite512.NIO2.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite513.NIO.txt
>[concat]
> TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite513.NIO2.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt
>
>
> Here are the error types:
>
>
> 1. Testsuite: jakarta.el.TestImportHandlerStandardPackages
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.463 sec
>
> Testcase: testClassListsAreComplete took 0.444 sec
> FAILED
> java.lang.Thread.Builder.OfPlatform
> junit.framework.AssertionFailedError: java.lang.Thread.Builder.OfPlatform
> at
> jakarta.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$12(TestImportHandlerStandardPackages.java:77)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>
>
> 2. TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO.txt
>
> 5-EndOfStream
>  expected:<-Header-[content-[length]-[0]]> but
> was:<-Header-[content-[type]-[text/plain;charset=UTF-8]]>
> at
> jakarta.servlet.http.HttpServletDoHeadBaseTest.testDoHeadHttp2(HttpServletDoHeadBaseTest.java:160)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>
> Testcase: testDoHead[467: true 8,192 true 1,023 FULL 0 true] took 2.129 sec
> FAILED
> expected:<4> but was:<5>
> junit.framework.AssertionFailedError: expected:<4> but was:<5>
> at
> jakarta.servlet.http.HttpServletDoHeadBaseTest.testDoHead(HttpServletDoHeadBaseTest.java:94)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>
> Testcase: testDoHeadHttp2[467: true 8,192 true 1,023 FULL 0 true] took
> 1.07 sec
> FAILED
> 3-HeadersStart
> 3-Header-[:status]-[200]
> 3-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
> 3-HeadersEnd
> 5-HeadersStart
> 5-Header-[:status]-[200]
> 5-Header-[content-type]-[text/plain;charset=UTF-8]
> 5-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
> 5-HeadersEnd
> 5-EndOfStream
>  expected:<-Header-[[date]-[Wed, 11 Nov 2015 19:18:42 GMT]]> but
> was:<-Header-[[content-type]-[text/plain;charset=UTF-8]]>
> junit.framework.AssertionFailedError: 3-HeadersStart
> 3-Header-[:status]-[200]
> 3-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
> 3-HeadersEnd
> 5-HeadersStart
> 5-Header-[:status]-[200]
> 5-Header-[content-type]-[text/plain;charset=UTF-8]
> 5-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
> 5-HeadersEnd
> 5-EndOfStream
>  expected:<-Header-[[date]-[Wed, 11 Nov 2015 19:18:42 GMT]]> but
> was:<-Header-[[co

Re: JDK 19 - Virtual Threads Testing!

[Martin Grigorov]

Hi Mark,

I confirm that all tests pass now!
Thank you!

Martin

On Wed, May 18, 2022 at 1:40 PM Mark Thomas  wrote:

> On 18/05/2022 10:25, Mark Thomas wrote:
> > Hi all,
> >
> > So of the three issues Martin identified, I've fixed 1 & 3 which were
> > the simple ones.
> >
> > For 1, the import handler needed updating to add the new classes added
> > to java.lang in Java 19.
> >
> > For 3, the memory leak protection code that stops executor threads
> > needed to be updated for some changes to Thread internals.
> >
> > The tricky one is 2.
> >
> > Prior to Java 19, the character -> byte encoders used an 8k buffer for
> > character data. This aligned with Tomcat's internals. This meant that
> > the new HEAD handling in the Servlet API had the same buffering
> > behaviour as Tomact's internals so GET and HEAD behaved the same way.
> >
> > In Java 19, the character -> byte encoders start with a 512 byte buffer
> > that may grow up to 8192 bytes. This means the buffering for HEAD
> > handling is different to the buffering for GET handling which in turn
> > means GET and HEAD see different headers (even accounting for allowed
> > differences).
> >
> > The issue is when responses are committed (and headers are fixed). The
> > HEAD tests examine the behaviour at the buffer boundaries including
> > reset behaviour. GET and HEAD effectively having different buffer sizes
> > triggers different behaviour for some of these resets which is why some
> > fail.
> >
> > I'm currently thinking about ways to tackle this but I don't yet have a
> > solution I'm completely happy with. Suggestions welcome.
>
> I found a solution. Since the issue was only with the legacy handling
> mode for HEAD requests, adjusting the response buffer size to compensate
> for the smaller char -> byte buffer addresses the issue.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: JDK 19 - Virtual Threads Testing!

[Martin Grigorov]

Hello Tomcat devs,

Some tests fail with JDK 19-ea+22-1598:

  [concat] Testsuites with failed tests:
   [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO.txt
   [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1023.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1023.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1024.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1024.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1025.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite1025.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite511.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite511.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite512.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite512.NIO2.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite513.NIO.txt
   [concat]
TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite513.NIO2.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt


Here are the error types:


1. Testsuite: jakarta.el.TestImportHandlerStandardPackages
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.463 sec

Testcase: testClassListsAreComplete took 0.444 sec
FAILED
java.lang.Thread.Builder.OfPlatform
junit.framework.AssertionFailedError: java.lang.Thread.Builder.OfPlatform
at
jakarta.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$12(TestImportHandlerStandardPackages.java:77)
at
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)


2. TEST-jakarta.servlet.http.TestHttpServletDoHeadValidWrite0.NIO.txt

5-EndOfStream
 expected:<-Header-[content-[length]-[0]]> but
was:<-Header-[content-[type]-[text/plain;charset=UTF-8]]>
at
jakarta.servlet.http.HttpServletDoHeadBaseTest.testDoHeadHttp2(HttpServletDoHeadBaseTest.java:160)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)

Testcase: testDoHead[467: true 8,192 true 1,023 FULL 0 true] took 2.129 sec
FAILED
expected:<4> but was:<5>
junit.framework.AssertionFailedError: expected:<4> but was:<5>
at
jakarta.servlet.http.HttpServletDoHeadBaseTest.testDoHead(HttpServletDoHeadBaseTest.java:94)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)

Testcase: testDoHeadHttp2[467: true 8,192 true 1,023 FULL 0 true] took 1.07
sec
FAILED
3-HeadersStart
3-Header-[:status]-[200]
3-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
3-HeadersEnd
5-HeadersStart
5-Header-[:status]-[200]
5-Header-[content-type]-[text/plain;charset=UTF-8]
5-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
5-HeadersEnd
5-EndOfStream
 expected:<-Header-[[date]-[Wed, 11 Nov 2015 19:18:42 GMT]]> but
was:<-Header-[[content-type]-[text/plain;charset=UTF-8]]>
junit.framework.AssertionFailedError: 3-HeadersStart
3-Header-[:status]-[200]
3-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
3-HeadersEnd
5-HeadersStart
5-Header-[:status]-[200]
5-Header-[content-type]-[text/plain;charset=UTF-8]
5-Header-[date]-[Wed, 11 Nov 2015 19:18:42 GMT]
5-HeadersEnd
5-EndOfStream
 expected:<-Header-[[date]-[Wed, 11 Nov 2015 19:18:42 GMT]]> but
was:<-Header-[[content-type]-[text/plain;charset=UTF-8]]>
at
jakarta.servlet.http.HttpServletDoHeadBaseTest.testDoHeadHttp2(HttpServletDoHeadBaseTest.java:160)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)



3. Testcase: testTimerThreadLeak took 2.609 sec
FAILED
null
junit.framework.AssertionFailedError
at
org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.testTimerThreadLeak(TestWebappClassLoaderExecutorMemoryLeak.java:63)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)


Regards,
Martin


On Mon, May 16, 2022 at 10:54 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Welcome to a new OpenJDK Quality Outreach update!
>
> This time, we have one update 

Re: New JDK 19 EA builds and JCE Survey!

[Martin Grigorov]

Hi David,

Apache Tomcat's build and tests pass successfully with JDK 19-ea+18-1211 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Wed, Apr 20, 2022 at 5:18 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase
> One’ set for June 9th and ‘General Availability’ set for September 20th.
> The next several weeks will be interesting to watch as the scope of JDK
> 19 is revealed.
>
> You also play an important roll during these phases, which is your
> opportunity to share feedback . When developers such as yourself tell us
> of issues faced in the latest OpenJDK early-access (EA) builds, we then
> have a chance to fix them before that feature release reaches general
> availability (GA).
>
> We also enjoy when people tell us that all their tests are green! It
> gives us confidence ;-) So regardless of the tests color (red or green),
> please do not hesitate to send me a short mail as both types of feedback
> are useful.
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html
>
>
> ## Heads-Up: Java Cryptographic Extension Survey
>
> The Java Cryptographic Extension (JCE) has been in Java SE for a long
> time and has made incremental changes over the years. The OpenJDK
> Security Team is conducting a survey [2] to know more about how projects
> are using JCE and what changes, features, and API enhancements would be
> useful going forward.
>
> The survey is clossing on April 29 so if you have written or maintain
> code that uses the JCE API, please make sure to fill this short survey
> [2] as soon as possible.
>
> [2] https://www.questionpro.com/t/AUzP7ZrFWv
>
>
> ## Heads-Up: New macOS Rendering Pipeline on macOS
>
> JEP 382 [3] introduced in JDK 17 support for the new macOS Metal
> graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is
> switching the default to be the new macOS Metal rendering pipeline
> instead of the old Apple OpenGL API. For more details please see
> JDK-8284378 [4].
>
> Java applications running on macOS (10.14 or later) will not need to
> take any action, as they will automatically benefit from faster graphics
> with lower power consumption, and the use of a more modern stable
> graphics API which will be able to work better on current and future
> Apple systems.
>
> [3] https://openjdk.java.net/jeps/382
> [4] https://bugs.openjdk.java.net/browse/JDK-8284378
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 18 are now available [5], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [6].
>
> [5] https://jdk.java.net/19/
> [6] https://jdk.java.net/19/release-notes
>
> ### JEPs targeted to JDK 19, so far:
> - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422
>
> ### Recent changes that maybe of interest:
>
> Build 18:
> - JDK-8284378: Make Metal the default Java 2D rendering pipeline for macOS
> - JDK-8265315: Update CLDR to version 41
> - JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over projections
> [Reported by JaCoCo]
> - JDK-8284361: Updating ASM to 9.3 for JDK 19
> - JDK-8284330: jcmd may not be able to find processes in the container
> - JDK-8284579: Improve VarHandle checks for interpreter
>
> Build 17:
> - JDK-8282819: Deprecate Locale class constructors
> - JDK-8254935: Deprecate the PSSParameterSpec(int) constructor
> - JDK-8283060: RawNativeLibraries should allow multiple clients to
> load/unload the same library
>
> Build 16:
> - JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default
> - JDK-8264160: Regex \b is not consistent with \w without
> UNICODE_CHARACTER_CLASS
> - JDK-8163327: Remove 3DES from the default enabled cipher suites list
> - JDK-8267319: Use larger default key sizes and algorithms based on CNSA
> - JDK-8283350: (tz) Update Timezone Data to 2022a
>
>
> ## Project Loom Updates
>
> The first Loom related JEP is now in Candidate phase, i.e. JEP: 425:
> Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose
> to target' any particular feature release.
>
> [7] https://openjdk.java.net/jeps/425
>
> In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4)
> are now available [8] with related Javadoc [9].
>
> These builds are based on JDK 19 and are provided under the GNU General
> Public License, version 2, with the Classpath Exception and are produced
> for the purpose of gathering feedback. Use for any other purpose is at
> your own risk. Proper feedback should be sent to the `loom-dev` mailing
> list [10].
>
> [8] https://jdk.java.net/loom/
> [9] https://download.java.net/java/early_access/loom/docs/api/
> [10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
>
>
> ## Topics of Interest:
>
> * New candidate JEP: 426: Vector API (4th Incubator)
> https://openjdk.java.net/jeps/426
>
> * Virtual Thread Deep Dive - Inside Java Newscast #23
> 

Re: JDK 18 Release Candidate builds & JDK 19 Early-Access builds

[Martin Grigorov]

Hi David,

Apache Tomcat's build and tests are green with JDK 18+36-2087 and
19-ea+11-661 on Linux x86_64 and aarch64!

Regards,
Martin

On Mon, Feb 28, 2022 at 10:28 PM David Delabassee <
david.delabas...@oracle.com> wrote:

> Mark, All,
>
> The Release Candidates of JDK 18 have been released [1]. At this stage,
> only P1 issues will be evaluated [2]. And with the JDK 18 General
> Availability sets for March 22nd, it is now time to shift the focus to
> JDK 19. I'd like to thank those of you who have already provided
> feedback on the early Early Builds of JDK 19. Feedback is always
> extremely useful, even more, when it comes early in the development cycle.
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html
> [2] https://openjdk.java.net/jeps/3
>
>
> ## JDK 18 Release Candidate
>
> The Release Candidate builds of JDK 18 are now available [3], and are
> provided under the GNU General Public License v2, with the Classpath
> Exception. The Release Notes are available here [4].
>
> [3] https://jdk.java.net/18/
> [4] https://jdk.java.net/18/release-notes
>
>
> ## JDK 19 Early-Access builds
>
> JDK 19 Early-Access builds 11 are now available [5], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [6].
>
> [5] https://jdk.java.net/19/
> [6] https://jdk.java.net/19/release-notes
>
> Recent changes that maybe of interest:
>
> * JDK-8278067: Make HttpURLConnection default keep alive timeout
> configurable
> * JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if
> caller is null
> * JDK-8282279: Interpret case-insensitive string locale independently
> * JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats
> * JDK-5041655: (ch) FileLock: negative param and overflow issues
> * JDK-8255266: Update Public Suffix List to 3c213aa
> * JDK-8280958: G1/Parallel: Unify marking code structure
> * JDK-8072070: Improve interpreter stack banging
> * JDK-8277175: Add a parallel multiply method to BigInteger
> * JDK-8278947: Support for array constants in constant table
> * JDK-8281462: Annotation toString output for enum not reusable for
> source input
> * JDK-8281175: Add a -providerPath option to jarsigner
> * JDK-8277795: ldap connection timeout not honoured under contention
> * JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos
> * JDK-8280744: Allow SuppressWarnings to be used in all declaration
> contexts
> * JDK-8272984: javadoc support for reproducible builds
> * JDK-8272317: jstatd has dependency on Security Manager which needs to
> be removed
>
>
> ## New Project Loom Early-Access builds
>
> Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available
> [7] with the related Javadoc [8].
>
> These EA builds are based on JDK 19 (jdk-19+9). In those builds, the
> APIs for Structured Concurrency and Scope Locals have been moved into
> the `jdk.incubator.concurrent` incubator module. Note that the module
> name may change later. To use those APIs, simply use `--add-modules
> jdk.incubator.concurrent` at compile and runtime.
>
> Those EA builds are provided under the GNU General Public License,
> version 2, with the Classpath Exception and are produced for the purpose
> of gathering feedback. Use for any other purpose is at your own risk.
> Proper feedback should be sent to the `loom-dev` mailing list [9].
>
> [7] https://jdk.java.net/loom/
> [8] https://download.java.net/java/early_access/loom/docs/api/
> [9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
>
>
> ## Topics of Interest
>
> * JDK 18 - Card Table Card Size Shenanigans
> https://tschatzl.github.io/2022/02/15/card-table-card-size.html
> * Compiled & Tested Code In Javadoc - Inside Java Newscast #20
> https://inside.java/2022/02/10/insidejava-newscast-020/
> * New candidate JEP: 423: Region Pinning for G1
> https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html
> * Refactoring Java 8 code with Java 17 new features - JEP Café #9
> https://inside.java/2022/02/01/jepcafe9/
>
>
>
> As always, let us know if you find any issues while testing your
> projects on the latest JDK Early Access builds. Thanks for your support!
>
> --David
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds

[Martin Grigorov]

Hi David,

Apache Tomcat's build and tests pass successfully with JDK 18-ea+33-2077
and 19-ea+7-366 on both Linux x86_64 and aarch64!

Regards,
Martin

On Mon, Jan 31, 2022 at 11:33 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Greetings!
>
> First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy
> and prosperous new year!
>
> In 2022, two Java releases will be made available:
> - JDK 18 (March 2022)
> - JDK 19 (September 2022)
>
> JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be
> better prepared for the future, it makes sense to begin testing your
> project(s) using early access (EA) builds of JDK 19[3]. Your feedback
> allows us to evaluate and address issues you find while testing EA builds.
>
> This time, we have two heads-up to share:
>
> ## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal
>
> Finalization is an outdated and brittle resource cleaning mechanism
> present in the platform since, well, forever. Its use has been
> discouraged for quite some time in favor of better alternatives (i.e.,
> 'try with resources' and Cleaners). JEP 421 is another step towards the
> removal of finalizers as it offers tools to investigate if a codebase is
> still using finalization. To learn more, you should read JEP 421[4]. You
> should also listen to the latest episode of the Inside Java Podcast[5]
> dedicated to this topic. We encourage you to check if your project is
> still using finalizers. If so, you should start to think about removing
> them and rely instead on either 'try with resources' or Cleaners.
>
> ## Heads-Up: JVM does not flag constant class entries ending in '/'
>
> Prior to JDK 19, the JVM is loading classes (1) whose class file major
> version is <49, i.e., before JDK 1.5, and (2) the class's name ends with
> a '/'. This violates section 4.2.1 of the JVM specification [6] and is
> addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a
> ClassFormatError exception as it already does with newer classes (JDK
> 1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect
> the compatibility risk to be very low.
>
> For more details, see JDK-8278448[7].
>
> [1] https://jdk.java.net/18/
> [2]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html
> [3] https://jdk.java.net/19/
> [4] https://openjdk.java.net/jeps/421
> [5] https://inside.java/podcast/21
> [6]
> https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1
> [7] https://bugs.openjdk.java.net/browse/JDK-8278448
>
>
> ## JDK 18
>
> JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a
> few weeks back when it entered RDP1.
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> JDK 18 Early-Access builds 33 are now available[8], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Also available are the Release Notes[9].
>
> [8] https://jdk.java.net/18/
> [9] https://jdk.java.net/18/release-notes
>
> ### Changes in JDK 18 since Rampdown Phase One that are of interest:
>
> - JDK-8278373: Correcting References to Overloaded Methods in Javadoc
> Documentation
> - JDK-8279065: Deserialization filter and filter factory property error
> reporting under specified
> - JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs
> - JDK-8275610: C2: Object field load floats above its null check
> resulting in a segfault [Reported by Apache POI]
>
>
> ## JDK 19
>
> JDK 19 Early-Access builds 7 are now available[10], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Also available are the Release Notes[11].
>
> [10] https://jdk.java.net/19/
> [11] https://jdk.java.net/19/release-notes
>
> ### Changes in recent JDK 19 EA builds that maybe of interest:
>
> - JDK-8279258: Auto-vectorization enhancement for two-dimensional array
> operations
> - JDK-8273914: Indy string concat changes order of operations
> - JDK-8268081: Upgrade Unicode Data Files to 14.0.0
> - JDK-8278087: Deserialization filter and filter factory property error
> reporting under specified
> - JDK-8276766: Enable jar and jmod to produce deterministic timestamped
> content
> - JDK-8274679: Remove unnecessary conversion to String in security code
> in java.base
> - JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16
> - JDK-8279064: New options for ktab to provide non-default salt
> - JDK-8280055: JFR: Improve ObjectContext implementation
> - JDK-8268831: Improve javadoc tool handling of streams
>
>
> ## Topics of Interest:
>
> - 

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Martin Grigorov]

Hi David,

Apache Tomcat build and tests pass successfully with JDK 18-ea+27-1924 on
both Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Dec 10, 2021 at 9:58 AM David Delabassee <
david.delabas...@oracle.com> wrote:

> Mark,
>
> Thank you for being part of the OpenJDK Quality Outreach Program. As
> year-end 2021 approaches, I'd like to share some updates on JDK 18,
> which is scheduled for General Availability on March 22, 2022.
>
> JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that
> the main-line has been forked into a dedicated JDK 18 stabilization
> repository. At this point, the overall JDK 18 feature set is now frozen
> and no additional JEPs will be targeted to JDK 18. Only low-risk
> enhancements that add small bits of missing functionality or improve
> usability might still be considered. The next few weeks should be
> leveraged to try to identify and resolve as many issues as possible
> (i.e. before JDK 18 enters the Release Candidates phase).
>
> And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for
> issues that were reported by you! So thank you for your help
> contributing to the overall quality of OpenJDK!
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html
>
>
> ## JEP 400 - UTF-8 by Default
>
> All JEPs are now integrated, but we would like to draw your attention to
> JEP 400 especially if you are deploying on Windows as it might induce
> some incompatible behavior on that platform.
>
> JEP 400 [2] is changing the default charset to UTF-8. This aligns with
> the existing `newBufferedReader`/`Writer` methods of the
> `java.nio.file.Files` class where UTF-8 is the default when no explicit
> charset is set. By making UTF-8 the default charset, the JDK I/O APIs
> will now always work in the same, predictable manner, with no need to
> pay attention to the host and or user’s environment!
>
> Further, we encourage you to test your project(s) with the latest JDK 18
> Early Access builds. We don't expect issues on macOS and Linux as their
> default encoding is already UTF-8. On Windows, especially for East Asian
> locales such as Chinese/Japanese/Korean, some incompatible behavior
> could be anticipated. If that’s the case, please consider a mitigation
> strategy [3].
>
> [2] https://openjdk.java.net/jeps/400
> [3] https://inside.java/2021/10/04/the-default-charset-jep400/
>
>
> ## JDK 18
>
> JDK 18 Early-Access builds 27 are now available [4], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Make sure to check the Release Notes [5]. As usual, we encourage you to
> test your project(s) using those EA builds and provide us feedback.
>
> [4] https://jdk.java.net/18/
> [5] https://jdk.java.net/18/release-notes
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal
>
> ### Changes in recent builds that maybe of interest:
>
>  Build 27:
>
> - JDK-8266435: WBMPImageReader.read() should not truncate the input
> stream [Reported by PDFBox]
> - JDK-8278078: Cannot reference super before supertype constructor has
> been called
> - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
> - JDK-8277965: Enclosing instance optimization affects serialization
> - JDK-8275821: Optimize random number generators developed in
> JDK-8248862 using Math.unsignedMultiplyHigh()
> - JDK-8225181: KeyStore should have a getAttributes method
> - JDK-8275082: Update XML Security for Java to 2.3.0
> - JDK-8278270: ServerSocket is not thread safe
> - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets
>
>  Build 26:
>
> - JDK-8277451: j.l.r.Field::set on static field with invalid argument
> type should throw IAE [Reported by Hibernate & ByteBuddy]
> - JDK-8258117: jar tool sets the time stamp of module-info.class entries
> to the current time [Reported by Apache Maven]
> - JDK-8268743: Require a better way for copying data between
> MemorySegments and on-heap arrays [Reported by Apache Lucene]
> - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
> [Reported by Apache Ant]
> - JDK-8277861: Terminally deprecate Thread.stop
> - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw
> ClassNotFoundException
> - JDK-8271623: Omit enclosing instance fields from inner classes that
> don't use it
> - JDK-8231107: Allow store password to be null when saving a PKCS12
> KeyStore
> - JDK-8193682: Infinite loop in ZipOutputStream.close()
> - JDK-8277459: Add `jwebserver` tool [see Topics of Interest]
>
>  Build 25:
>
> - JDK-8259643: ZGC can return 

Re: [VOTE] Release Apache Tomcat 9.0.56

[Martin Grigorov]

On Fri, Dec 3, 2021 at 10:50 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.56 release is now available for voting.
>
> The notable changes compared to 9.0.56 are:
>
> - Provide protection against a known OS bug that causes the acceptor to
>report an incoming connection more than once.
>
> - Implement a workaround for a JVM bug that can trigger a file
>descriptor leak when using multi-part upload and the application does
>not explicitly close an input stream for an uploaded file that was
>cached on disk.
>
> - Fix exceptions when the security manager is enabled and the first
>request received after starting is an HTTP request to a TLS enabled
>NIO2 connector.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.56/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1344
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.56
> af2a7a4fb2db07390362af12d0020d550abd8785
>
> The proposed 9.0.56 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.56 (stable)
>

Regards,
Martin


>
> Rémy
>
> -
> 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.14

[Martin Grigorov]

On Fri, Dec 3, 2021 at 12:22 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.14 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.13 are:
>
> - Provide protection against a known OS bug that causes the acceptor to
>report an incoming connection more than once.
>
> - Implement a workaround for a JVM bug that can trigger a file
>descriptor leak when using multi-part upload and the application does
>not explicitly close an input stream for an uploaded file that was
>cached on disk.
>
> - Fix exceptions when the security manager is enabled and the first
>request received after starting is an HTTP request to a TLS enabled
>NIO2 connector.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.14/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1345
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.14
> 3bb5b5fcf02e25ae627e480937e755e0a99c82d7
>
> The proposed 10.0.14 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.14 (stable)
>

Regards,
Martin


>
> -
> 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.0-M8

[Martin Grigorov]

On Thu, Dec 2, 2021 at 4:44 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M8 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M7 are:
>
> - Limit cookie support to RFC 6265 to align with recent updates to the
>Servlet specification
>
> - Update the WebSocket API packaging to remove the copy of the client
>API from the server API and replace it with a dependency on the client
>API. This aligns Tomcat with changes in the WebSocket 2.1
>specification.
>
> - Provide protection against a known OS bug that causes the acceptor to
>report an incoming connection more than once.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M8/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1343
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M8
> cd53876fefaa370c31466b0f615e9ad026541a27
>
>
> The proposed 10.1.0-M8 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M8 (alpha)
>

Regards,
Martin


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

Re: OpenSSL module build releases

[Martin Grigorov]

On Tue, Nov 23, 2021 at 11:18 AM Rémy Maucherat  wrote:

> On Tue, Nov 23, 2021 at 9:33 AM Martin Grigorov 
> wrote:
> >
> > Hi Remy,
> >
> > On Tue, Nov 23, 2021 at 9:49 AM Rémy Maucherat  wrote:
> >
> > > On Mon, Nov 22, 2021 at 10:55 PM Christopher Schultz
> > >  wrote:
> > > >
> > > > Rémy,
> > > >
> > > > On 11/22/21 02:00, Rémy Maucherat wrote:
> > > > > I am done with the initial version of the OpenSSL with Panama
> module.
> > > >
> > > > Fantastic.
> > > >
> > > > > It could be time for more testing and build releases (obviously
> > > > > targeting only Java 17). It should also be easy to add new
> features as
> > > > > needed since the full OpenSSL API is available and there's no hard
> to
> > > > > update subcomponent to release first. I only focused on replicating
> > > > > the functionality that was in tomcat-native.
> > > > >
> > > > > What would be the best way to proceed ?
> > > >
> > > > What does it take to run Tomcat's unit-test suite with Panama
> enabled,
> > > > instead of e.g. tcnative?
> > >
> > > This needs some modifications to the tests, just as there's code to
> > > run JSSE (or tomcat-native).
> > >  parameterSets.add(new Object[] {
> > > "JSSE", Boolean.FALSE,
> > > "org.apache.tomcat.util.net.jsse.JSSEImplementation"});
> > > would be:
> > > "OpenSSL-Panama", Boolean.FALSE,
> > > "org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation"});
> > > I did that in all relevant tests for testing (and removed the two
> > > others to get faster runs). This now needs extra code to make it run
> > > only on Java 17.
> >
> >
> > > build.xml needs some changes too (and they need to be optional, as the
> > > arguments only work on Java 17):
> > >
> > > diff --git a/build.xml b/build.xml
> > > index fbba5d7..4046afe 100644
> > > --- a/build.xml
> > > +++ b/build.xml
> > > @@ -238,6 +238,7 @@
> > >  
> > >  
> > >  
> > > +
> > >  
> > >  
> > >
> > > @@ -1938,6 +1938,9 @@
> > > > > value="--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"/>
> > > value="--add-opens=java.base/java.util=ALL-UNNAMED"/>
> > > > > value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
> > > +  
> > > +  
> > > +  
> > >
> > >
> > >
> > > I'm not sure how to make the tests fail nice if OpenSSL isn't there.
> > > The first step is to release a build (like for the migration tool)
> > > since otherwise this cannot really be done properly.
> > >
> >
> > I could test it on Linux ARM64!
>
> Ok !
>
> > But to make it easier for me and anyone else: can we control the JVM args
> > in build.xml and the JVM properties in the tests via build.properties ?
> > I.e. if I set some new property in build.properties then all of the above
> > to be done for me wthout manually patching around.
>
> I cannot do anything to make the testsuite "ready to run" without a
> build out first. The current mechanism for selecting
> sslImplementationName does not use system properties, so I have to
> change all the tests.
>

Yes, the respective tests have to be updated.
I could do it too in the coming weeks.


>
> Rémy
>
> > Martin
> >
> >
> > >
> > > > It might help to post an "invitation to try something out" and see if
> > > > anyone gets failures you didn't get during your work.
> > > >
> > > > > I also updated the panama-foreign version of it since it is now
> > > > > stable-with-workaround, at:
> > > > > https://github.com/rmaucher/openssl-panama-foreign . It will
> > > > > eventually require whichever Java first gets the non incubator
> version
> > > > > of the API (it could be 19 or 20).
> > > >
> > > > I may have asked this already: would this be expected to work with
> > > > LibreSSL? I think they have a goal of binary-compatibility with
> OpenSSL.
> > >

Re: OpenSSL module build releases

[Martin Grigorov]

Hi Remy,

On Tue, Nov 23, 2021 at 9:49 AM Rémy Maucherat  wrote:

> On Mon, Nov 22, 2021 at 10:55 PM Christopher Schultz
>  wrote:
> >
> > Rémy,
> >
> > On 11/22/21 02:00, Rémy Maucherat wrote:
> > > I am done with the initial version of the OpenSSL with Panama module.
> >
> > Fantastic.
> >
> > > It could be time for more testing and build releases (obviously
> > > targeting only Java 17). It should also be easy to add new features as
> > > needed since the full OpenSSL API is available and there's no hard to
> > > update subcomponent to release first. I only focused on replicating
> > > the functionality that was in tomcat-native.
> > >
> > > What would be the best way to proceed ?
> >
> > What does it take to run Tomcat's unit-test suite with Panama enabled,
> > instead of e.g. tcnative?
>
> This needs some modifications to the tests, just as there's code to
> run JSSE (or tomcat-native).
>  parameterSets.add(new Object[] {
> "JSSE", Boolean.FALSE,
> "org.apache.tomcat.util.net.jsse.JSSEImplementation"});
> would be:
> "OpenSSL-Panama", Boolean.FALSE,
> "org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation"});
> I did that in all relevant tests for testing (and removed the two
> others to get faster runs). This now needs extra code to make it run
> only on Java 17.


> build.xml needs some changes too (and they need to be optional, as the
> arguments only work on Java 17):
>
> diff --git a/build.xml b/build.xml
> index fbba5d7..4046afe 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -238,6 +238,7 @@
>  
>  
>  
> +
>  
>  
>
> @@ -1938,6 +1938,9 @@
> value="--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"/>
>
> value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
> +  
> +  
> +  
>
>
>
> I'm not sure how to make the tests fail nice if OpenSSL isn't there.
> The first step is to release a build (like for the migration tool)
> since otherwise this cannot really be done properly.
>

I could test it on Linux ARM64!
But to make it easier for me and anyone else: can we control the JVM args
in build.xml and the JVM properties in the tests via build.properties ?
I.e. if I set some new property in build.properties then all of the above
to be done for me wthout manually patching around.

Martin


>
> > It might help to post an "invitation to try something out" and see if
> > anyone gets failures you didn't get during your work.
> >
> > > I also updated the panama-foreign version of it since it is now
> > > stable-with-workaround, at:
> > > https://github.com/rmaucher/openssl-panama-foreign . It will
> > > eventually require whichever Java first gets the non incubator version
> > > of the API (it could be 19 or 20).
> >
> > I may have asked this already: would this be expected to work with
> > LibreSSL? I think they have a goal of binary-compatibility with OpenSSL.
> >
> > Similarly, Stefan @ httpd has produced an experimental mod_tls for httpd
> > which uses RustTLS as its underlying crypto library instead of OpenSSL.
> > It might be interesting to see how difficult it would be to use RustTLS
> > instead of OpenSSL, though that may require some significant changes to
> > Tomcat's code to deal with any "philosophical" differences between the
> > OpenSSL API and RustTLS.
>
> This supports the OpenSSL 1.1+ API. It doesn't support older versions
> (it may require adding back some annoying code, or worse), and this
> will work on newer versions as long as all the APIs in use stay there.
> No idea about clones, but the libraries have to be really compatible
> with OpenSSL 1.1, or I would have to stop using jextract (not a great
> plan).
>
> > I fully expect a presentation at the next ApacheCon about all the work
> > you are doing. :)
>
> Maybe, but there's still a long way to go ;)
>
> Rémy
>
> >
> > -chris
> >
> > -
> > 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: JDK 18 Early-Access builds 23 are available

[Martin Grigorov]

Hi David,

Apache Tomcat's build and tests pass on JDK 18 b23 on both Linux x86_64 and
aarch64!

Regards,
Martin

P.S. It seems your email client does not properly set Reply-to header. I
almost sent the email without you in To/CC.

On Tue, Nov 16, 2021 at 1:08 PM  wrote:

> Hi Mark,
>
> I’m happy to announce that moving forward Oracle’s Java DevRel Team will
> manage the Quality Outreach Program. I would like to thank Rory for all
> the efforts he's put into this program and wish him all the joy and
> happiness that retirement can bring! We have big shoes to fill but we’re
> excited to continue building off the amazing structure Rory has put in
> place.
>
>
> The JDK 18 schedule is now known [1] with a feature freeze date
> (Rampdown Phase One) less than 4 weeks away! This time, we have 2
> important heads-ups, one related to JEP 411 (Deprecate the Security
> Manager for Removal), and one related to JEP 416 (Reimplement Core
> Reflection with Method Handles). We're asking your help to test and
> confirm that your project works seamlessly now that those 2 JEPs are
> integrated in the JDK 18 Early-Access builds.
>
> [1] https://openjdk.java.net/projects/jdk/18/
>
>
> # JEP 411 - Deprecate the Security Manager for Removal
>
> Starting JDK 18 b21 [2], the default value of the
> 'java.security.manager' system property is set to "disallow". This means
> that any application or library that enables the Security Manager by
> calling `System.setSecurityManager` will now have to specify
> `-Djava.security.manager=allow` on the command-line in order for that
> code to continue working as expected. This change was originally
> targeted for JDK 17, but after some discussion/feedback from the
> community, the change was delayed until JDK 18 [3].
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8270380
> [3] https://openjdk.java.net/jeps/411#Description
>
>
> # JEP 416 - Reimplement Core Reflection with Method Handles
>
> JEP 416 [4] reimplements `java.lang.reflect.Method`,
> `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top of
> `java.lang.invoke` method handles. Making method handles the underlying
> mechanism for reflection will reduce the maintenance and development
> cost of both the `java.lang.reflect` and `java.lang.invoke` APIs. This
> is solely an implementation change but we encourage you to test your
> project to identify any behavior or performance regressions.
>
> [4] https://openjdk.java.net/jeps/416
>
>
> OpenJDK 18 Early-Access builds 23 are now available [5], and are
> provided under the GNU General Public License v2, with the Classpath
> Exception. The Release Notes are available [6].
>
> [5] https://jdk.java.net/18/
> [6] https://jdk.java.net/18/release-notes
>
>
> # JEPs integrated to JDK 18, so far:
>
> - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400
> - JEP 408: Simple Web Server https://openjdk.java.net/jeps/408
> - JEP 413: Code Snippets in Java API Documentation
> https://openjdk.java.net/jeps/413
> - JEP 416: Reimplement Core Reflection with Method Handles
> https://openjdk.java.net/jeps/416
> - JEP 418: Internet-Address Resolution SPI
> https://openjdk.java.net/jeps/418
>
>
> # JEPs targeted to JDK 18, so far:
>
> - JEP 417: Vector API (Third Incubator) https://openjdk.java.net/jeps/417
>
>
> # JEPs proposed to target JDK 18, so far:
>
> - JEP 419: Foreign Function & Memory API (Second Incubator)
> https://openjdk.java.net/jeps/419
> - JEP 420: Pattern Matching for switch (Second Preview)
> https://openjdk.java.net/jeps/420
>
>
> # Changes in recent builds that maybe of interest:
>
> ## Build 23:
>
> - JDK-8275509: ModuleDescriptor.hashCode isn't reproducible across builds
> - JDK-8276220: Reduce excessive allocations in DateTimeFormatter
> - JDK-8276298: G1: Remove unused G1SegmentedArrayBufferList::add
> - JDK-8273922: (fs) UserDefinedFileAttributeView doesn't handle file
> names that are just under the MAX_PATH limit (win)
>
> ## Build 22:
>
> - JDK-8271820: Implementation of JEP 416: Reimplement Core Reflection
> with Method Handle
> - JDK-8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
> implementations
> - JDK-8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and
> getExtendedKeyUsage do not throw CertificateParsingException if
> extension is unparseable
>
> ## Build 21:
>
> - JDK-8270380: Change the default value of the java.security.manager
> system property to disallow
> - JDK-8275319: java.net.NetworkInterface throws java.lang.Error instead
> of SocketException
> - JDK-8270490: Charset.forName() taking fallback default value
> - JDK-8269336: Malformed jdk.serialFilter incorrectly handled
>
>
> # Project Loom update
>
> New Project Loom 18-loom+4-273 (2021/11/10) Early-Access builds are
> available [7] with related Javadocs [8].
>
> [7] https://jdk.java.net/loom/
> [8] https://download.java.net/java/early_access/loom/docs/api/
>
> These EA builds are provided under the GNU General Public License,
> version 2, with the Classpath 

Re: [VOTE] Release Apache Tomcat 9.0.55

[Martin Grigorov]

On Wed, Nov 10, 2021 at 10:55 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.55 release is now available for voting.
>
> The notable changes compared to 9.0.55 are:
>
> - Experimental OpenSSL support through the Panama API incubating in Java
>17, with support for OpenSSL 1.1+
>The module is available here:
>https://github.com/apache/tomcat/tree/10.1.0-M7/modules/openssl-java17
>Note: The 10.1.0-M7 tag corresponds to the 9.0.55 tag epoch.
>
> - Add support for custom caching strategies for web application
>resources. This initial implementation allows control over whether or
>not a resource is cached.
>
> - Improve robustness of JNDIRealm for exceptions occurring when getting
>the connection.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.55/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1340
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.55
> 662cc9171c22ac790532d38a2b59990faaa7b971
>
> The proposed 9.0.55 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.55 (stable)
>

Regards,
Martin


>
> Rémy
>
> -
> 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.13

[Martin Grigorov]

On Wed, Nov 10, 2021 at 12:51 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.13 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.12 are:
>
> - Experimental OpenSSL support through the Panama API incubating in Java
>17, with support for OpenSSL 1.1+
>
> - Add support for custom caching strategies for web application
>resources. This initial implementation allows control over whether or
>not a resource is cached.
>
> - Improve robustness of JNDIRealm for exceptions occurring when getting
>the connection.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.13/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1339
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.13
> 40dbce6eb012429a6ba62a9bb65fd11ee5c6c898
>
> The proposed 10.0.13 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.13 (stable)
>

Regards,
Martin


>
> -
> 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.0-M7

[Martin Grigorov]

On Mon, Nov 8, 2021 at 11:59 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M7 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M6 are:
>
>
> - Servlet API updates for Servlet 6 including refactoring
>HttpServlet.doHead(), support for generic attributes on Cookies, more
>consistent URI handling including an option to reject 'suspicious'
>URIs
>
> - EL API updates for EL 5.0 including changes to ELResolver.getType()
>
> - Experimental OpenSSL support through the Panama API incubating in Java
>17, with support for OpenSSL 1.1+
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M7/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1338
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M7
> 0f3f1e439a040068b741d7766722e4420ad6
>
>
> The proposed 10.1.0-M7 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M7 (alpha)
>

Regards,
Martin


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

Re: Thank you! JDK 18 Early Access build 20 is now available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass with JDK 18-ea+20-1248 on Linux x86_64
and aarch64!

Regards,
Martin

On Tue, Oct 26, 2021 at 3:57 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Thank you.*
>
> I'm retiring at the end of November 2021, it's time to spend more time
> with the family.
>
> We started the Quality Outreach back in October 2014.  We now have 170+
> projects participating.
> Thank you for taking the time to provide Testing feedback , excellent
> bugs and support throughout
> the last seven years.
>
> It's been a pleasure working with you. I am delighted to say that the
> program will continue
> with the support of the Java DevRel Team, with David Delabassee as your
> contact. David has
> been assisting with on-boarding new projects for the last couple of years.
>
> All the best, Rory
>
>
> *OpenJDK 18Early Access build 20is now available
> at**https://jdk.java.net/18/ **
> *
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>   * Release Notes are available athttps://jdk.java.net/18/release-notes
> 
>   * Features:
>   o JEPs integrated to JDK 18, so far:
>   + JEP 400: UTF-8 by Default 
>   + JEP 408: Simple Web Server 
>   + JEP 413: Code Snippets in Java API Documentation
> 
>   o JEPs targeted to JDK 18, so far
>   + JEP 417: Vector API (Third Incubator)
> 
>   o JEPs proposed to target JDK 18:
>   + JEP 416: Reimplement Core Reflection with Method Handles
> 
>
>   * Significant changes since the last availability email:
>   o Build 20:
>   + JDK-8275252: Migrate cacerts from JKS to password-less PKCS12
>   + JDK-8275149: (ch) ReadableByteChannel returned by
> Channels.newChannel(InputStream) throws ReadOnlyBufferException
>   + JDK-8266936: Add a finalization JFR event
>   + JDK-8264849: Add KW and KWP support to PKCS11 provider
>   o Build 19:
>   + JDK-8274840: Update OS detection code to recognize Windows 11
>   + JDK-8274407: (tz) Update Timezone Data to 2021c
>   + JDK-8273102: Delete deprecated for removal the empty
> finalize() in java.desktop module
>   o Build 18:
>   + JDK-8274656: Remove default_checksum and safe_checksum_type
> from krb5.conf
>   + JDK-8274471: Add support for RSASSA-PSS in OCSP Response
>   + JDK-8274227: Remove "impl.prefix" jdk system property usage
> from InetAddress
>   + JDK-8274002: [win11 and winserver2022] JDK executable
> installer from network drive starts with huge delay
>   + JDK-8273670: Remove weak etypes from default krb5 etype list
>   o Build 17:
>   + JDK-8273401: Disable JarIndex Support In URLClassPath
>   + JDK-8231640: (prop) Canonical property storage
>   + Build 16:
>   + JDK-8269039: Disable SHA-1 Signed JARs
>
> *Topics of Interest:*_
> _
>
> _JDK 17:_**
> **
>
>   * *Inside Java Podcast “Java 17 is Here!”*
>   o *Part 1: https://inside.java/2021/09/14/podcast-019/
> *
>   o *Part 2: https://inside.java/2021/09/27/podcast-020/
> *
>   * *G1 GC & Parallel GC Improvements in JDK 17*
>   o *https://inside.java/2021/09/17/jdk-17-gc-updates/
> *
>   * ZGC - What's new in JDK 17**
>   o *https://inside.java/2021/10/05/zgc-in-jdk17/
> *
>   * JDK 17 Security Enhancements**
>   o *https://inside.java/2021/09/15/jdk-17-security-enhancements/
> *
>   * The Vector API in JDK 17 (video)**
>   o *https://inside.java/2021/09/23/devlive-vector-api/
> *
>   * Faster Charset Encoding**
>   o *https://inside.java/2021/10/17/faster-charset-encoding/
> *
>
> _JDK 18:_
>
>   * JEP 400 and the Default Charset
>   o https://inside.java/2021/10/04/the-default-charset-jep400/
> 
>   * JDK 18 augmented `javac -Xlint:serial` checks
>   o https://inside.java/2021/10/20/augmented-serial-checks
> 
>
> _Project Panama - Foreign Function & Memory API:_
>
>   * Finalizing the Foreign APIs
>   o 

Re: 2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

On Thu, Oct 21, 2021, 19:30 Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Martin,
>
> On 10/21/21 06:09, Martin Grigorov wrote:
> > On Thu, Oct 21, 2021 at 12:29 PM Mark Thomas  wrote:
> >
> >> On 21/10/2021 10:19, Mark Thomas wrote:
> >>> On 21/10/2021 08:40, Martin Grigorov wrote:
> >>>
> >>> 
> >>>
> >>>>> Fails also at TravisCI:
> >>>>> https://app.travis-ci.com/github/apache/tomcat/jobs/543217112
> >>>>>
> >>>>
> >>>> diff --git
> >>>>
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >>>>
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >>>> index 710e0c7..37c13ef 100644
> >>>> ---
> >>>>
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >>>> +++
> >>>>
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >>>> @@ -185,7 +185,7 @@ public class TestCoyoteAdapterCanonicalization
> >>>> extends
> >>>> TomcatBaseTest {
> >>>>"Host: localhost" + CRLF +
> >>>>CRLF
> >>>>});
> >>>> -client.setResponseBodyEncoding(StandardCharsets.UTF_8);
> >>>> +//client.setResponseBodyEncoding(StandardCharsets.UTF_8);
> >>>>
> >>>> This fixes the problem here.
> >>>
> >>> That suggests the server isn't sending the correct bytes. I think the
> >>> above change is addressing a symptom rather than the root cause.
> >>>
> >>> We need to dig into this some more.
> >>
> >> Fixed it. It was the source file encoding.
> >>
> >
> > It works now but I don't quite understand the issue yet.
> > Both Intellij IDEA and vim say that
> TestCoyoteAdapterCanonicalization.java
> > file is/was UTF-8.
> > Which source file exactly is ISO_8859_1 ?
>
> The Java /compiler/ says "source files are ISO-8859-1". We specify it
> explicitly in build.xml in the  invocation.
>

Ant!
Got it!
Thanks!


> So you can't put high-ASCII or things like € in there safely.
>
> Sure, you can change the compiler encoding if you want, but since it's
> been this way for a long time, it's easier to change the single character.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: 2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

On Thu, Oct 21, 2021 at 12:29 PM Mark Thomas  wrote:

> On 21/10/2021 10:19, Mark Thomas wrote:
> > On 21/10/2021 08:40, Martin Grigorov wrote:
> >
> > 
> >
> >>> Fails also at TravisCI:
> >>> https://app.travis-ci.com/github/apache/tomcat/jobs/543217112
> >>>
> >>
> >> diff --git
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >> index 710e0c7..37c13ef 100644
> >> ---
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >> +++
> >>
> test/org/apache/catalina/connector/TestCoyoteAdapterCanonicalization.java
> >> @@ -185,7 +185,7 @@ public class TestCoyoteAdapterCanonicalization
> >> extends
> >> TomcatBaseTest {
> >>   "Host: localhost" + CRLF +
> >>   CRLF
> >>   });
> >> -client.setResponseBodyEncoding(StandardCharsets.UTF_8);
> >> +//client.setResponseBodyEncoding(StandardCharsets.UTF_8);
> >>
> >> This fixes the problem here.
> >
> > That suggests the server isn't sending the correct bytes. I think the
> > above change is addressing a symptom rather than the root cause.
> >
> > We need to dig into this some more.
>
> Fixed it. It was the source file encoding.
>

It works now but I don't quite understand the issue yet.
Both Intellij IDEA and vim say that TestCoyoteAdapterCanonicalization.java
file is/was UTF-8.
Which source file exactly is ISO_8859_1 ?


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

Re: 2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

On Thu, Oct 21, 2021 at 10:29 AM Martin Grigorov 
wrote:

>
>
> On Thu, Oct 21, 2021 at 10:13 AM Martin Grigorov 
> wrote:
>
>>
>>
>> On Thu, Oct 21, 2021 at 9:56 AM Martin Grigorov 
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 20, 2021 at 3:39 PM Mark Thomas  wrote:
>>>
>>>> I'm not seeing those failures with OpenJDK 17.0.1
>>>>
>>>
>>> I see the test is added 8 days ago, so most probably it is not related
>>> to the JDK version at all.
>>>
>>>
>>>>
>>>> The response line and body look to be correct to me.
>>>>
>>>> The failure appears to be with the request body. Is it possible you
>>>> aren't using UTF-8 for the *.java file? You could try using
>>>>
>>>
>>> I just clone the Git repo. It should use the encoding of the file.
>>>
>>>
>>>> "/foo\u20acbar" as the expected canonicalized URI.
>>>>
>>>
>>> I will test it now!
>>> First, I will replace assertTrue with assertEquals at
>>> https://github.com/apache/tomcat/commit/fee1f457f287a56d3d490a5ab5b3f643d280ecf5#diff-fae30dfd485f718b7b7d76763204c70a1d7257d319018763b98366d3f446decbR200
>>>
>>
>> HTTP/1.1 200
>> /foo€bar expected: but was:¬]bar>
>> junit.framework.AssertionFailedError: HTTP/1.1 200
>> /foo€bar expected: but was:¬]bar>
>> at
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>> at
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
>> at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
>> Source)
>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>> Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]]
>> took 0.011 sec
>> FAILED
>> HTTP/1.1 200
>> /foo€bar expected: but was:¬]bar>
>> junit.framework.AssertionFailedError: HTTP/1.1 200
>> /foo€bar expected: but was:¬]bar>
>> at
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>> at
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
>> at jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
>> Source)
>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>>
>>>
>>>
>>>>
>>>> Mark
>>>>
>>>>
>>>> On 20/10/2021 12:53, Martin Grigorov wrote:
>>>> > Hi,
>>>> >
>>>> > Today I've tested JDK 17.0.1 and noticed these failures:
>>>> >
>>>> > Testcase: testCanonicalizationSpecification[49:
>>>> > requestURI[/foo%E2%82%ACbar]] took 0.055 sec
>>>> >  FAILED
>>>> > HTTP/1.1 200
>>>> > /foo€bar
>>>> > junit.framework.AssertionFailedError: HTTP/1.1 200
>>>> > /foo€bar
>>>> >  at
>>>> >
>>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>>>> >  at
>>>> >
>>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
>>>> >  at
>>>> jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
>>>> > Source)
>>>> >  at
>>>> >
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> >
>>>> > Testcase: testCanonicalizationTomcat[49:
>>>> requestURI[/foo%E2%82%ACbar]] took
>>>> > 0.087 sec
>>>> >  FAILED
>>>> > HTTP/1.1 200
>>>> > /foo€bar
>>>> > junit.framework.AssertionFailedError: HTTP/1.1 200
>>>> > /foo€bar
>>>> >  at
>>>> >
>>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>

Re: 2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

On Thu, Oct 21, 2021 at 10:13 AM Martin Grigorov 
wrote:

>
>
> On Thu, Oct 21, 2021 at 9:56 AM Martin Grigorov 
> wrote:
>
>>
>>
>> On Wed, Oct 20, 2021 at 3:39 PM Mark Thomas  wrote:
>>
>>> I'm not seeing those failures with OpenJDK 17.0.1
>>>
>>
>> I see the test is added 8 days ago, so most probably it is not related to
>> the JDK version at all.
>>
>>
>>>
>>> The response line and body look to be correct to me.
>>>
>>> The failure appears to be with the request body. Is it possible you
>>> aren't using UTF-8 for the *.java file? You could try using
>>>
>>
>> I just clone the Git repo. It should use the encoding of the file.
>>
>>
>>> "/foo\u20acbar" as the expected canonicalized URI.
>>>
>>
>> I will test it now!
>> First, I will replace assertTrue with assertEquals at
>> https://github.com/apache/tomcat/commit/fee1f457f287a56d3d490a5ab5b3f643d280ecf5#diff-fae30dfd485f718b7b7d76763204c70a1d7257d319018763b98366d3f446decbR200
>>
>
> HTTP/1.1 200
> /foo€bar expected: but was:¬]bar>
> junit.framework.AssertionFailedError: HTTP/1.1 200
> /foo€bar expected: but was:¬]bar>
> at
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
> at
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
> at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]]
> took 0.011 sec
> FAILED
> HTTP/1.1 200
> /foo€bar expected: but was:¬]bar>
> junit.framework.AssertionFailedError: HTTP/1.1 200
> /foo€bar expected: but was:¬]bar>
> at
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
> at
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
> at jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>
>>
>>
>>>
>>> Mark
>>>
>>>
>>> On 20/10/2021 12:53, Martin Grigorov wrote:
>>> > Hi,
>>> >
>>> > Today I've tested JDK 17.0.1 and noticed these failures:
>>> >
>>> > Testcase: testCanonicalizationSpecification[49:
>>> > requestURI[/foo%E2%82%ACbar]] took 0.055 sec
>>> >  FAILED
>>> > HTTP/1.1 200
>>> > /foo€bar
>>> > junit.framework.AssertionFailedError: HTTP/1.1 200
>>> > /foo€bar
>>> >  at
>>> >
>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>>> >  at
>>> >
>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
>>> >  at
>>> jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
>>> > Source)
>>> >  at
>>> >
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> >
>>> > Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]]
>>> took
>>> > 0.087 sec
>>> >  FAILED
>>> > HTTP/1.1 200
>>> > /foo€bar
>>> > junit.framework.AssertionFailedError: HTTP/1.1 200
>>> > /foo€bar
>>> >  at
>>> >
>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>>> >  at
>>> >
>>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
>>> >  at
>>> jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
>>> > Source)
>>> >  at
>>> >
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> >
>>> > They fail consitently on both x86_64 and aarch64.
>>>
>>
Fails also at TravisCI:
https://app.travis-ci.com/github/apache/tomcat/jobs/543217112


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

Re: 2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

On Thu, Oct 21, 2021 at 9:56 AM Martin Grigorov 
wrote:

>
>
> On Wed, Oct 20, 2021 at 3:39 PM Mark Thomas  wrote:
>
>> I'm not seeing those failures with OpenJDK 17.0.1
>>
>
> I see the test is added 8 days ago, so most probably it is not related to
> the JDK version at all.
>
>
>>
>> The response line and body look to be correct to me.
>>
>> The failure appears to be with the request body. Is it possible you
>> aren't using UTF-8 for the *.java file? You could try using
>>
>
> I just clone the Git repo. It should use the encoding of the file.
>
>
>> "/foo\u20acbar" as the expected canonicalized URI.
>>
>
> I will test it now!
> First, I will replace assertTrue with assertEquals at
> https://github.com/apache/tomcat/commit/fee1f457f287a56d3d490a5ab5b3f643d280ecf5#diff-fae30dfd485f718b7b7d76763204c70a1d7257d319018763b98366d3f446decbR200
>

HTTP/1.1 200
/foo€bar expected: but was:¬]bar>
junit.framework.AssertionFailedError: HTTP/1.1 200
/foo€bar expected: but was:¬]bar>
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]] took
0.011 sec
FAILED
HTTP/1.1 200
/foo€bar expected: but was:¬]bar>
junit.framework.AssertionFailedError: HTTP/1.1 200
/foo€bar expected: but was:¬]bar>
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
at jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


>
>
>>
>> Mark
>>
>>
>> On 20/10/2021 12:53, Martin Grigorov wrote:
>> > Hi,
>> >
>> > Today I've tested JDK 17.0.1 and noticed these failures:
>> >
>> > Testcase: testCanonicalizationSpecification[49:
>> > requestURI[/foo%E2%82%ACbar]] took 0.055 sec
>> >  FAILED
>> > HTTP/1.1 200
>> > /foo€bar
>> > junit.framework.AssertionFailedError: HTTP/1.1 200
>> > /foo€bar
>> >  at
>> >
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>> >  at
>> >
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
>> >  at
>> jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
>> > Source)
>> >  at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >
>> > Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]]
>> took
>> > 0.087 sec
>> >  FAILED
>> > HTTP/1.1 200
>> > /foo€bar
>> > junit.framework.AssertionFailedError: HTTP/1.1 200
>> > /foo€bar
>> >  at
>> >
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
>> >  at
>> >
>> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
>> >  at
>> jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
>> > Source)
>> >  at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >
>> > They fail consitently on both x86_64 and aarch64.
>> >
>> > Regards,
>> > Martin
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

Re: 2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

On Wed, Oct 20, 2021 at 3:39 PM Mark Thomas  wrote:

> I'm not seeing those failures with OpenJDK 17.0.1
>

I see the test is added 8 days ago, so most probably it is not related to
the JDK version at all.


>
> The response line and body look to be correct to me.
>
> The failure appears to be with the request body. Is it possible you
> aren't using UTF-8 for the *.java file? You could try using
>

I just clone the Git repo. It should use the encoding of the file.


> "/foo\u20acbar" as the expected canonicalized URI.
>

I will test it now!
First, I will replace assertTrue with assertEquals at
https://github.com/apache/tomcat/commit/fee1f457f287a56d3d490a5ab5b3f643d280ecf5#diff-fae30dfd485f718b7b7d76763204c70a1d7257d319018763b98366d3f446decbR200


>
> Mark
>
>
> On 20/10/2021 12:53, Martin Grigorov wrote:
> > Hi,
> >
> > Today I've tested JDK 17.0.1 and noticed these failures:
> >
> > Testcase: testCanonicalizationSpecification[49:
> > requestURI[/foo%E2%82%ACbar]] took 0.055 sec
> >  FAILED
> > HTTP/1.1 200
> > /foo€bar
> > junit.framework.AssertionFailedError: HTTP/1.1 200
> > /foo€bar
> >  at
> >
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
> >  at
> >
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
> >  at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
> > Source)
> >  at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >
> > Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]]
> took
> > 0.087 sec
> >  FAILED
> > HTTP/1.1 200
> > /foo€bar
> > junit.framework.AssertionFailedError: HTTP/1.1 200
> > /foo€bar
> >  at
> >
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
> >  at
> >
> org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
> >  at jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
> > Source)
> >  at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >
> > They fail consitently on both x86_64 and aarch64.
> >
> > Regards,
> > Martin
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

2 tests in TestCoyoteAdapterCanonicalization fail

[Martin Grigorov]

Hi,

Today I've tested JDK 17.0.1 and noticed these failures:

Testcase: testCanonicalizationSpecification[49:
requestURI[/foo%E2%82%ACbar]] took 0.055 sec
FAILED
HTTP/1.1 200
/foo€bar
junit.framework.AssertionFailedError: HTTP/1.1 200
/foo€bar
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationSpecification(TestCoyoteAdapterCanonicalization.java:156)
at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Testcase: testCanonicalizationTomcat[49: requestURI[/foo%E2%82%ACbar]] took
0.087 sec
FAILED
HTTP/1.1 200
/foo€bar
junit.framework.AssertionFailedError: HTTP/1.1 200
/foo€bar
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.doTestCanonicalization(TestCoyoteAdapterCanonicalization.java:200)
at
org.apache.catalina.connector.TestCoyoteAdapterCanonicalization.testCanonicalizationTomcat(TestCoyoteAdapterCanonicalization.java:161)
at jdk.internal.reflect.GeneratedMethodAccessor29.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

They fail consitently on both x86_64 and aarch64.

Regards,
Martin

Re: [VOTE] Release Apache Tomcat 9.0.54

[Martin Grigorov]

On Tue, Sep 28, 2021 at 5:32 PM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.54 release is now available for voting.
>
> The notable changes compared to 9.0.54 are:
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> - Improvements to the DataSourceUserDatabase
>
> - Fix an issue that caused some Servlet non-blocking API reads of the
>HTTP request body to incorrectly use blocking IO.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.54/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1336
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.54
> 454f804f3336ec980e84eb84bb6a051e349c6d3a
>
> The proposed 9.0.54 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.54 (stable)
>

Regards,
Martin


>
> Rémy
>
> -
> 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.12

[Martin Grigorov]

On Tue, Sep 28, 2021 at 4:59 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.12 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.11 are:
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> - Improvements to the DataSourceUserDatabase
>
> - Fix an issue that caused some Servlet non-blocking API reads of the
>HTTP request body to incorrectly use blocking IO.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.12/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1335
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.12
> 84e18583f461778707f7fd2e25b1f0677e44e899
>
> The proposed 10.0.12 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.12 (stable)
>

Regards,
Martin


>
> -
> 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.0-M6

[Martin Grigorov]

On Tue, Sep 28, 2021 at 3:31 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M6 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M5 are:
>
> - Servlet API updates for Servlet 6 including removal of all deprecated
>code, updated schemas and a new API for connection and request IDs.
>
> - EL API updates for EL 5.0 including deprecation of the use of
>FeatureDescriptor, improvements to BeanELResolver and the addition of
>MethodReference
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M6/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1334
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M6
> 51d1031c36c0f2b3ee1e0d14b56228a559144153
>
>
> The proposed 10.1.0-M6 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M6 (alpha)
>


Regards,
Martin


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

Re: Release Announcement: General Availability of Java 17 / JDK 17

[Martin Grigorov]

Hi Rory,

Congratiolations for JDK 17 GA!

Apache Tomcat 10.1.x build and tests pass successfully with
JDK 18-ea+14-756 on both Linux x86_64 and aarch64 !

Regards,
Martin

On Tue, Sep 14, 2021 at 6:55 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Release Announcement: General Availability of Java 17 / JDK 17 *
>
> **
>
>   * JDK 17, the reference implementation of Java 17, is now Generally
> Available. [1]
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> https://jdk.java.net/17/ 
>   * JDK 17 Release notes
> 
>   * Inside Java: The Arrival of Java 17!
> 
>
> *JDK 17 includes the following features [2]:*
>
>   * JEP 306: Restore Always-Strict Floating-Point Semantics
> 
>   * JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   * JEP 382: New macOS Rendering Pipeline
> 
>   * JEP 391: macOS/AArch64 Port 
>   * JEP 398: Deprecate the Applet API for Removal
> 
>   * JEP 403: Strongly Encapsulate JDK Internals
> 
>   * JEP 406: Pattern Matching for switch (Preview)
> 
>   * JEP 407: Remove RMI Activation 
>   * JEP 409: Sealed Classes 
>   * JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>   * JEP 411: Deprecate the Security Manager for Removal
> 
>   * JEP 412: Foreign Function & Memory API (Incubator)
> 
>   * JEP 414: Vector API (Second Incubator)
> 
>   * JEP 415: Context-Specific Deserialization Filters
> 
>
> *JDK 17 will be a long-term-support (LTS) release* from most
> vendors,including Oracle. If you’re upgrading from the previous LTS
> release,JDK 11, then you have many more JEPs to look forward to,
> summarized here:
>
> https://openjdk.java.net/jdk/17/jeps-since-jdk-11
> 
>
>
> Thanks to everyone who contributed to JDK 17, whether by creating
> features or enhancements, logging bugs, or
>
> downloading and testing the early-access builds.
>
>
> *OpenJDK 18 Early Access build 14 is now available at
> https://jdk.java.net/18/ 
> *
>
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * JEPs targeted to JDK 18, so far:
>   o JEP 400: UTF-8 by Default 
>   o JEP 413: Code Snippets in Java API Documentation
> 
>
>   * Release Notes are available at https://jdk.java.net/18/release-notes
> 
>
>   * Significant changes since the last availability email:
>   o JDK-8271745: Fix Issues With the KW and KWP Modes of SunJCE
> Provider
>   o JDK-8262186: Call X509KeyManager.chooseClientAlias once for all
> key types
>   o JDK-8225083: Remove Google certificate that is expiring in
> December 2021
>   o JDK-8251329: Zip File System Provider Throws ZipException when
> entry name element contains "." or ".."
>   o JDK-8225082: Remove IdenTrust certificate that is expiring in
> September 2021
>   o
>
> *Project Loom Early-Access Builds*
>
>   * Build 18-loom+2-74 (2021/8/7) based on jdk-18+9
>  is
> available - https://jdk.java.net/loom/ 
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> Rgds,Rory
>
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006037.html
>
> [2] https://openjdk.java.net/projects/jdk/17/
> 
>
>

Re: [VOTE] Release Apache Tomcat 8.5.71

[Martin Grigorov]

On Thu, Sep 9, 2021 at 10:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> The proposed Apache Tomcat 8.5.71 release is now available for voting.
>
> The notable changes compared to 8.5.70 are:
>
> - Add a UserDatabase implementation as a superset of the DataSourceRealm
> functionality.
>
> - Update the internal fork of Apache Commons DBCP to 2.9.0, Apache
> Commons Pool to 2.9.1, Apache Commons FileUpload to 2.0, and
> Apache Commons Codec to 1.16.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.31 to
> pick up Windows binaries built with OpenSSL 1.1.1l.
>
> - Correct parsing of Content-Range headers
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-8.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.71/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1333
> The tag is:
>
>
> https://github.com/apache/tomcat/commit/9e60ee33816f3f28af81535c108e6bd23f2ef970
>
> https://github.com/apache/tomcat/tree/8.5.71
> 9e60ee33816f3f28af81535c108e6bd23f2ef970
>
> The proposed 8.5.71 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.71 (stable)
>

Regards,
Martin


>
> Remy
>
> -
> 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: building Tomcat with a third-party library

[Martin Grigorov]

On Wed, Sep 8, 2021 at 11:34 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Alain,
>
> On 9/8/21 14:26, alain hubert wrote:
> > Hello,
> >
> > my colleagues just gave me a challenge before I can retire but the
> problem
> > is I haven't done anything else than Email/Excel for years, being an
> > old-school manager. Please be indulgent.
> >
> > It took hours before I could find the Tomcat source, unzip it, and much
> > more to understand the magics with ANT which needs Java to run (I was
> > ashamed to learn that but the Tomcat documentation is well written,
> thanks).
> >
> > Here I am blocked, I need to implement a very simple Authenticator
> relying
> > on a proprietary Java library.
> > When adding the import lines for importing this proprietary package, it's
> > not possible to compile anymore.
>
> How important is it to build Tomcat *with* your custom library? What if,
> instead, you compiled your library separately and used Tomcat as a
> (previously-built) dependency?
>

As Chris suggested you could use Tomcat's jars as dependencies to build
your own library.
See https://search.maven.org/artifact/org.apache.tomcat/tomcat-catalina
Then put your-library.jar either in yourApp.war#lib or in
$CATALINA_BASE/lib and configure your Authenticator in
yourApp.war#META-INF/context.xml or
$CATALINA_HOME/conf/context.xml/server.xml
See https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html and
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Authentication



>
> > I get the following errors. From what I understand, building Tomcat
> > with an additional library would need to add it somewhere but I was
> > not able to find this in the documentation. Does anyone have an
> > idea? >
> > thanks for reading
> > A.Hubert.
> >
> > compile:
> >  [javac] Compiling 1 source file to
> > /home/ahubert/tests/tomcat-src/apache-tomcat-9.0.52-src/output/classes
> >  [javac]
> >
> /home/ahubert/tests/tomcat-src/apache-tomcat-9.0.52-src/java/org/apache/catalina/authenticator/BasicAuthenticatorToto.java:19:
> > error: package com.exane.authentification does not exist
> >  [javac] import static com.exane.authentification.Authent.*;
> >  [javac]^
> >  [javac]
> >
> /home/ahubert/tests/tomcat-src/apache-tomcat-9.0.52-src/java/org/apache/catalina/authenticator/BasicAuthenticatorToto.java:20:
> > error: package com.exane.authentification does not exist
> >  [javac] import static com.exane.authentification.Verif.*;
> >  [javac]^
> >  [javac]
> >
> /home/ahubert/tests/tomcat-src/apache-tomcat-9.0.52-src/java/org/apache/catalina/authenticator/BasicAuthenticatorToto.java:22:
> > error: package com.exane.authentification does not exist
> >  [javac] import com.exane.authentification.*;
> >  [javac] ^
> >  [javac] 3 errors
> >
> > BUILD FAILED
> > /home/ahubert/tests/tomcat-src/apache-tomcat-9.0.52-src/build.xml:973:
> > Compile failed; see the compiler error output for details.
>
> Where are the source files for com.exane.* to be found?
>

If you decide to modify Tomcat's sources directly then you should add your
library to the build classpath.
See
https://github.com/apache/tomcat/blob/386912a93f130078f52e7094be3a730cda742121/build.xml#L214-L221
The sources of com.exane.* are not really needed. You need the classes,
i.e. the jar.

Martin


>
> -chris
>
> -
> 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.53

[Martin Grigorov]

On Mon, Sep 6, 2021 at 10:22 PM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.53 release is now available for voting.
>
> The notable changes compared to 9.0.53 are:
>
> - Add a UserDatabase implementation as a superset of the DataSourceRealm
>functionality.
>
> - Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
>Commons Pool to 2.11.1
>
> - Update the packaged version of the Tomcat Native Library to 1.2.31 to
>pick up Windows binaries built with OpenSSL 1.1.1l.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.53/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1332
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.53
> 966ec5401970b9d4b41b53f5fff9f65966d887dd
>
> The proposed 9.0.53 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.53 (stable)
>

Regards,
Martin


>
> Remy
>
> -
> 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.11

[Martin Grigorov]

On Mon, Sep 6, 2021 at 9:30 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.11 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.10 are:
>
> - Add a UserDatabase implementation as a superset of the DataSourceRealm
>functionality.
>
> - Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
>Commons Pool to 2.11.1
>
> - Update the packaged version of the Tomcat Native Library to 1.2.31 to
>pick up Windows binaries built with OpenSSL 1.1.1l.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.11/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1331
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.11
> c191bad5a0cd7f1606f573dd960d0b396aeb288d
>
> The proposed 10.0.11 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 10.0.11 (stable)
>

Regards,
Martin


>
> -
> 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.0-M5

[Martin Grigorov]

On Mon, Sep 6, 2021 at 5:43 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M5 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M4 are:
>
> - Remove the deprecated APR/Native connector which includes the HTTP APR
>and the AJP APR connector. Also remove the Java interfaces to the
>APR/Native library that are not used by the OpenSSL integration for
>the NIO and NIO2 connectors.
>
> - Add a UserDatabase implementation as a superset of the DataSourceRealm
>functionality.
>
> - Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
>Commons Pool to 2.11.1
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M4/


This should be -M5


>
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1330
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M5
> 2a10c8d9110d7b1c7f526f3352648c6b19ba2c52
>
>
> The proposed 10.1.0-M5 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 10.1.0-M5 (alpha)
>

Regards,
Martin


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

Re: JDK 17 is now in the Release Candidate Phase

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17+35-2724
and 18-ea+9-409 on both Linux aarch64 and x86_64!

Regards,
Martin

On Sat, Aug 7, 2021 at 6:36 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Per the JDK 17 schedule , we are now in the Release Candidate Phase
> [1][2].*
>
> *
> *
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.*
>
>   * Schedule:
>   o *2021/08/05   Initial Release Candidate *
>   o 2021/08/19Final Release Candidate
>   o 2021/09/14General Availability
>
>
> The overall feature set is frozen. No further JEPs will be targeted to
> this release.
>
>   * Features integrated in JDK 17:
>
>   o JEP 306: Restore Always-Strict Floating-Point Semantics
> 
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>   o JEP 403: Strongly Encapsulate JDK Internals
> 
>   o JEP 406: Pattern Matching for switch (Preview)
> 
>   o JEP 407: Remove RMI Activation 
>   o JEP 409: Sealed Classes 
>   o JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>   o JEP 411: Deprecate the Security Manager for Removal
> 
>   o JEP 412: Foreign Function & Memory API (Incubator)
> 
>   o JEP 414: Vector API (Second Incubator)
> 
>   o JEP 415: Context-Specific Deserialization Filters
> 
>
> *
> *
>
> *OpenJDK 17 Early Accessbuild 35 is available at
> **https://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Release Notes are available at https://jdk.java.net/17/release-notes
> 
>   * Changes in recent builds that maybe of interest:
>   o JDK-8270866: NPE in DocTreePath.getTreePath()[build 33]
>   + Reportedby jOOQ
>
> **Topics of Interest: *
> *
>
>   * The latest Newscast covers 17's JEP 356
> : Enhanced Pseudo-Random Number
> Generators - Here
> 
>   * The latest JEP Café cover 17's JEP 409
>  : Sealed Classes - Here
> 
>   * A few updates to JEP 411 :
> Deprecate the Security Manager for Removal - Here
> <
> https://mail.openjdk.java.net/pipermail/security-dev/2021-July/026806.html
> >
>
> *
> *
>
> *OpenJDK**18 Early Access build 9 is available at
> **https://jdk.java.net/18* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Release Notes are available at https://jdk.java.net/18/release-notes
> 
>   * Changes in recent builds that maybe of interest:
>   o JDK-8225082: Remove IdenTrust certificate that is expiring in
> September 2021 [build 9]
>   o JDK-8251329: Zip File System Provider Throws ZipException when
> entry name element contains "." or ".." [build 9]
>   o JDK-8271359: NPE in DocTreePath.getTreePath() [build 8]
>   + Reported by jOOQ
>
> *July 2021 Critical Patch Update Released*
>
>   * As part of the July 2021, we released JDK 16.0.2, JDK 11.0.12 LTS,
> JDK 8u301 and JDK 7u311 as well as OpenJDK 16.0.2 (publicly available)
>
>
> Rgds,Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005894.html
> [2]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005906.html
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: JDK 17 is now in Rampdown Phase Two

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+31-2664
and 18-ea+6-237, on both Linux x86_64 and aarch64!

Regards,
Martin

On Thu, Jul 15, 2021 at 11:12 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *Per the JDK 17 schedule , we are in Rampdown Phase Two [1].*
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.*
>
>   * Schedule:
>
>   o *2021/07/15 Rampdown Phase Two*
>   o 2021/08/05  Initial Release Candidate
>   o 2021/08/19 Final Release Candidate
>   o 2021/09/14  General Availability
>
>
> The overall feature set is frozen. No further JEPs will be targeted to
> this release.
>
>   * Features integrated in JDK 17:
>
>   o JEP 306: Restore Always-Strict Floating-Point Semantics
> 
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>   o JEP 403: Strongly Encapsulate JDK Internals
> 
>   o JEP 406: Pattern Matching for switch (Preview)
> 
>   o JEP 407: Remove RMI Activation 
>   o JEP 409: Sealed Classes 
>   o JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>   o JEP 411: Deprecate the Security Manager for Removal
> 
>   o JEP 412: Foreign Function & Memory API (Incubator)
> 
>   o JEP 414: Vector API (Second Incubator)
> 
>   o JEP 415: Context-Specific Deserialization Filters
> 
>
> *
> *
>
> *OpenJDK 17 Early Access build 31 is available at
> **https://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Release Notes are available at https://jdk.java.net/17/release-notes
> 
>
>
> *
> *
>
> *OpenJDK 18 Early Access build 6 is available at *
> *https://jdk.java.net/18* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Release Notes are available at https://jdk.java.net/18/release-notes
> 
>   * Changes in recent builds that maybe of interest:
>   o JDK-8269697: JNI_GetPrimitiveArrayCritical() should not accept
> object array [build 6]
>   o JDK-8253119: Remove the legacy PlainSocketImpl and
> PlainDatagramSocketImpl implementation [build 6]
>   o JDK-8268960: Prohibit Null for Header Keys and Values in
> com.sun.net.httpserver.Headers [build 5]
>   o JDK-8256425: Obsolete Biased Locking in JDK 18 [build 4]
>
> *Topics of Interest: *
>
>   * ‘Inside Java’ Podcast #18: Java's steady march towards strong
> encapsulation 
>
>
> Rgds,Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005752.html
> 
>
>

Re: Possible code clean-up

[Martin Grigorov]

On Wed, Jun 30, 2021 at 3:51 PM Mark Thomas  wrote:

> All,
>
> I wanted to get some feedback on a possible code clean-up. Currently, we
> declare literal arrays like this:
>
> String[] array = new String[] { "value1", "value2", "value3" );
>
> We could simplify these declarations to:
>
> String[] array = { "value1", "value2", "value3" );
>
> There doesn't appear to be a checkstyle rule to enforce one approach or
> the other.
>
> Assuming someone is willing to spend the time to make these changes what
> do the folks here think?
>
> I think the code is a little cleaner and therefore easier to read but
> the benefit seems minimal. I'm not sure it is worth "fixing" the
> existing code.
>
> We could use this going forward as the opportunity arises. The
> inconsistency in style bugs me a little - but not so much I couldn't
> live with it.
>
> Thoughts?
>

+1 to simplify !


>
> Mark
>
> -
> 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.0-M2

[Martin Grigorov]

On Sat, Jun 26, 2021 at 1:07 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M2 release is now available for
> voting.
>
> 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.
>
> The notable changes compared to 10.1.0-M1 are:
>
> - Re-work the HTTP/2 overhead protection to reduce the likelihood of
>false positives. Note that the default overheadCountFactor has changed
>from 1 to 10 and that the useful range is now 0 to ~20.
>
> - Update to Eclipse JDT compiler 4.20.
>
> - Fix regressions in JSP compilation in the previous release.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M2/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1318
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M2
> 0e59fedb28df646930c5aff945159b64d7a52260
>
> The proposed 10.1.0-M2 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 10.1.0-M2 (alpha)
>

Regards,
Martin


>
> -
> 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.8

[Martin Grigorov]

On Sat, Jun 26, 2021 at 2:27 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.8 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.7 are:
>
> - Re-work the HTTP/2 overhead protection to reduce the likelihood of
>false positives. Note that the default overheadCountFactor has changed
>from 1 to 10 and that the useful range is now 0 to ~20.
>
> - Update to Eclipse JDT compiler 4.20.
>
> - Fix regressions in JSP compilation in the previous release.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.8/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1319
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.8
> 64520a63e23437b4e92db42bfc70a20d1f9e79c4
>
> The proposed 10.0.8 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 10.0.8 (stable)
>

Regards,
Martin


>
> -
> 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.69

[Martin Grigorov]

Hi,

On Wed, Jun 30, 2021 at 11:54 AM Rémy Maucherat  wrote:

> On Wed, Jun 30, 2021 at 7:45 AM Konstantin Kolinko
>  wrote:
> >
> > ср, 30 июн. 2021 г. в 00:03, Christopher Schultz <
> ch...@christopherschultz.net>:
> > >
> > > [...]
> > >
> > > It can be obtained from:
> > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.69/
> > >
> > > The Maven staging repo is:
> > >
> https://repository.apache.org/content/repositories/orgapachetomcat-1322/
> >
> > The Maven repository responds with 404:
> >
> > Repository "orgapachetomcat-1322 (staging: open)"
> > [id=orgapachetomcat-1322] exists but is not exposed.
>
> I tried closing it but this failed as the artefacts are not signed. So
> this will have to be dropped and rebuilt.
>

One more issue:

$ tar zxvf apache-tomcat-8.5.69.tar.gz
apache-tomcat-8.5.69/conf/
apache-tomcat-8.5.69/conf/catalina.policy
tar: apache-tomcat-8.5.69/conf/catalina.policy: time stamp 2021-06-30
21:00:00 is 27213.161195036 s in the future
apache-tomcat-8.5.69/conf/catalina.properties
tar: apache-tomcat-8.5.69/conf/catalina.properties: time stamp 2021-06-30
21:00:00 is 27213.160612259 s in the future
apache-tomcat-8.5.69/conf/context.xml
tar: apache-tomcat-8.5.69/conf/context.xml: time stamp 2021-06-30 21:00:00
is 27213.160310352 s in the future
apache-tomcat-8.5.69/conf/jaspic-providers.xml
tar: apache-tomcat-8.5.69/conf/jaspic-providers.xml: time stamp 2021-06-30
21:00:00 is 27213.159964308 s in the future
apache-tomcat-8.5.69/conf/jaspic-providers.xsd
.


>
> Rémy
>
> >
> > Best regards,
> > Konstantin Kolinko
> >
> > -
> > 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 9.0.50

[Martin Grigorov]

On Mon, Jun 28, 2021 at 11:57 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.50 release is now available for voting.
>
> The notable changes compared to 9.0.50 are:
>
> - Re-work the HTTP/2 overhead protection to reduce the likelihood of
>false positives. Note that the default overheadCountFactor has changed
>from 1 to 10 and that the useful range is now 0 to ~20.
>
> - Update to Eclipse JDT compiler 4.20.
>
> - Fix regressions in JSP compilation in the previous release.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.50/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1321
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.50
> 06572792aa5424b5995c91edcc1e3fca4cc89bc1
>
> The proposed 9.0.50 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.50 (stable)
>

Regards,
Martin

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

Re: JDK 17 Early Access build 28 & JDK 18 build 3 are available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+28-2534
and 18-ea+3-63 on Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Jun 25, 2021 at 11:24 AM Rory O'Donnell 
wrote:

>
> Hi Mark, **
>
> *
> *
>
> *Per the JDK 17 schedule , we are in Rampdown Phase One.*
>
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.*
>
>
> The overall feature set is frozen. No further JEPs will be targeted to
> this release.
>
>   * Features integrated in JDK 17:
>
>   o JEP 306: Restore Always-Strict Floating-Point Semantics
> 
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>   o JEP 403: Strongly Encapsulate JDK Internals
> 
>   o JEP 406: Pattern Matching for switch (Preview)
> 
>   o JEP 407: Remove RMI Activation 
>   o JEP 409: Sealed Classes 
>   o JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>   o JEP 411: Deprecate the Security Manager for Removal
> 
>   o JEP 412: Foreign Function & Memory API (Incubator)
> 
>   o JEP 414: Vector API (Second Incubator)
> 
>   o JEP 415: Context-Specific Deserialization Filters
> 
>
>
> *OpenJDK 17 Early Access build 28 is available at
> **https://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Release Notes are available at https://jdk.java.net/17/release-notes
> 
>   * Changes in build 28 that maybe of interest:
>   o *JDK-8269028: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs *
>   o JDK-8268774: Residual logging output written to STDOUT, not
> STDERR [*Reported by Apache Ant*]
>   o JDK-8264843: Javac crashes with NullPointerException when
> finding unencoded XML in  tag [*Reported by Apache Lucene*]
>
>
> *OpenJDK 18 Early Access build 3 is now available at
> **https://jdk.java.net/18* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Changes in recent builds that maybe of interest:
>   o JDK-8266791: Annotation property which is compiled as an array
> property but changed to a single element throws NPE [*Reported
> by Byte Buddy*]
>   * Coming in a future JDK 18 build
>   o Removal of Biased Locking in JDK 18  - Details
> 
>
> *Other Topics of Interest: *
>
>   * State of Loom: https://www.youtube.com/watch?v=KG24inClY2M
> 
>   * State of Panama: https://www.youtube.com/watch?v=B8k9QGvPxC0
> 
>   * What's a JEP: https://www.youtube.com/watch?v=l1VrmvyIEpM
> 
>
>
> *Quality Report for June 2021 was published here [1]. ***
>
>   * Thanks to everyone who contributed by creating features or
> enhancements, logging bugs, or downloading and testing the
> early-access builds.
>
> Rgds,Rory
>
> [1]
>
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+June+2021*
> *
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [tomcat] branch main updated: Extend the time allowed for tests to complete

[Martin Grigorov]

Hi Mark,

On Wed, Jun 16, 2021 at 11:55 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
>  new 56e439a  Extend the time allowed for tests to complete
> 56e439a is described below
>
> commit 56e439ada85c7c99cf3fa2d1b44bfdeb9a9d43eb
> Author: Mark Thomas 
> AuthorDate: Wed Jun 16 09:54:15 2021 +0100
>
> Extend the time allowed for tests to complete
> ---
>  .travis.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 8556c36..75b0b24 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -80,7 +80,7 @@ install:
>
>  script:
>  - ant -q clean
> -- travis_wait 60 "./.travis/antTest.sh"
> +- travis_wait 120 "./.travis/antTest.sh"
>

I don't think this helps.
The maximum time for a job at TravisCI is 50 mins for public repositories,
and 120 mins for private ones.
In our case it is 50 mins.


>
>  after_failure:
>  - tail -n 5000 ant-test.log
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: JDK 17 is now in Rampdown Phase One

[Martin Grigorov]

Same for JDK 18-ea+1-7 !

Regards,
Martin

On Mon, Jun 14, 2021 at 2:35 PM Martin Grigorov 
wrote:

> Hi Rory,
>
> Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439
> on Linux x86_64 and aarch64 !
>
> Regards,
> Martin
>
> On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
> wrote:
>
>>
>> Hi Mark,
>>
>> *Per the JDK 17 schedule , we are in Rampdown Phase One [1].*
>>
>> **Please advise if you find any issues while testing the latest Early
>> Access builds**.**
>>
>>   * Schedule:
>>   o *2021/06/10   Rampdown Phase One*
>>   o 2021/07/15Rampdown Phase Two
>>   o 2021/08/05Initial Release Candidate
>>   o 2021/08/19Final Release Candidate
>>   o 2021/09/14General Availability
>>
>> The overall feature set is frozen. No further JEPs will be targeted to
>> this release.
>>
>> **
>>
>>   * Important JEPs have been integrated – Attention Required!
>>   * *JEP 411: **Deprecate the Security Manager for
>> Removal*<https://openjdk.java.net/jeps/411>
>>   o Deprecate, for removal, most Security Manager related classes
>> and methods.
>>   o Warning message at startup if the Security Manager is enabled on
>> the command line.
>>   o Warning message at run time if a Java application or library
>> installs a Security Manager dynamically.
>>   o Deprecation is in concert with the legacy Applet API (JEP 398).
>>   * *JEP 407: **Remove RMI Activation*<https://openjdk.java.net/jeps/407>
>>   o Removal the Remote Method Invocation (RMI) Activation mechanism,
>> while preserving the rest of RMI.
>>   o It was deprecated for removal by JEP
>> 385<https://openjdk.java.net/jeps/385>in Java SE 15.
>>   * *JEP 403: **Strongly Encapsulate JDK
>> Internals*<https://openjdk.java.net/jeps/403>
>>   o Strongly encapsulate all internal elements of the JDK, except
>> for critical internal APIs such as /sun.misc.Unsafe/.
>>   o It will no longer be possible to relax the strong encapsulation
>> of internal elements via a single command-line option.
>>
>>   * Other features integrated in JDK 17:
>>   o *JEP 306: **Restore Always-Strict Floating-Point
>> Semantics*<https://openjdk.java.net/jeps/306>
>>   o JEP 356: Enhanced Pseudo-Random Number
>> Generators<https://openjdk.java.net/jeps/356>
>>   o JEP 382: New macOS Rendering
>> Pipeline<https://openjdk.java.net/jeps/382>
>>   o JEP 391: macOS/AArch64 Port<https://openjdk.java.net/jeps/391>
>>   o JEP 398: Deprecate the Applet API for
>> Removal<https://openjdk.java.net/jeps/398>
>>   o *JEP 406: **Pattern Matching for switch
>> (Preview)*<https://openjdk.java.net/jeps/406>
>>   o JEP 409: Sealed Classes<https://openjdk.java.net/jeps/409>
>>   o JEP 410: Remove the Experimental AOT and JIT
>> Compiler<https://openjdk.java.net/jeps/410>
>>   o JEP 412: Foreign Function & Memory API
>> (Incubator)<https://openjdk.java.net/jeps/412>
>>   o *JEP 414: **Vector API (Second
>> Incubator)*<https://openjdk.java.net/jeps/414>
>>   o *JEP 415: **Context-Specific Deserialization
>> Filters*<https://openjdk.java.net/jeps/415>
>>
>> *OpenJDK 17 Early Access build 26 is available at
>> **https://jdk.java.net/17*<https://jdk.java.net/17>
>>
>>   * These early-access , open-source builds are provided under the
>>   o GNU General Public License, version 2, with the Classpath
>> Exception<https://openjdk.java.net/legal/gplv2+ce.html>
>>
>>   * Release Notes are available at
>> https://jdk.java.net/17/release-notes<
>> https://jdk.java.net/17/release-notes>
>>
>>   * Changes in recent builds that maybe of interest:
>>   * *Build 26:*
>>   o JDK-8268241: deprecate JVM TI Heap functions 1.0
>>   o JDK-8266846: Add java.time.InstantSource
>>   o JDK-8248268: Support KWP in addition to KW
>>   o JDK-8204686: Dynamic parallel reference processing support for
>> Parallel GC
>>   o JDK-8259530: Generated docs contain MIT/GPL-licenced works
>> without reproducing the licence [*Reported by Apache Maven*]
>>   o JDK-8266766: Arrays of types that cannot be an annotation member
>> do not yield exceptions 

Re: JDK 17 is now in Rampdown Phase One

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439 on
Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *Per the JDK 17 schedule , we are in Rampdown Phase One [1].*
>
> **Please advise if you find any issues while testing the latest Early
> Access builds**.**
>
>   * Schedule:
>   o *2021/06/10   Rampdown Phase One*
>   o 2021/07/15Rampdown Phase Two
>   o 2021/08/05Initial Release Candidate
>   o 2021/08/19Final Release Candidate
>   o 2021/09/14General Availability
>
> The overall feature set is frozen. No further JEPs will be targeted to
> this release.
>
> **
>
>   * Important JEPs have been integrated – Attention Required!
>   * *JEP 411: **Deprecate the Security Manager for
> Removal*
>   o Deprecate, for removal, most Security Manager related classes
> and methods.
>   o Warning message at startup if the Security Manager is enabled on
> the command line.
>   o Warning message at run time if a Java application or library
> installs a Security Manager dynamically.
>   o Deprecation is in concert with the legacy Applet API (JEP 398).
>   * *JEP 407: **Remove RMI Activation*
>   o Removal the Remote Method Invocation (RMI) Activation mechanism,
> while preserving the rest of RMI.
>   o It was deprecated for removal by JEP
> 385in Java SE 15.
>   * *JEP 403: **Strongly Encapsulate JDK
> Internals*
>   o Strongly encapsulate all internal elements of the JDK, except
> for critical internal APIs such as /sun.misc.Unsafe/.
>   o It will no longer be possible to relax the strong encapsulation
> of internal elements via a single command-line option.
>
>   * Other features integrated in JDK 17:
>   o *JEP 306: **Restore Always-Strict Floating-Point
> Semantics*
>   o JEP 356: Enhanced Pseudo-Random Number
> Generators
>   o JEP 382: New macOS Rendering
> Pipeline
>   o JEP 391: macOS/AArch64 Port
>   o JEP 398: Deprecate the Applet API for
> Removal
>   o *JEP 406: **Pattern Matching for switch
> (Preview)*
>   o JEP 409: Sealed Classes
>   o JEP 410: Remove the Experimental AOT and JIT
> Compiler
>   o JEP 412: Foreign Function & Memory API
> (Incubator)
>   o *JEP 414: **Vector API (Second
> Incubator)*
>   o *JEP 415: **Context-Specific Deserialization
> Filters*
>
> *OpenJDK 17 Early Access build 26 is available at
> **https://jdk.java.net/17*
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception
>
>   * Release Notes are available at
> https://jdk.java.net/17/release-notes<
> https://jdk.java.net/17/release-notes>
>
>   * Changes in recent builds that maybe of interest:
>   * *Build 26:*
>   o JDK-8268241: deprecate JVM TI Heap functions 1.0
>   o JDK-8266846: Add java.time.InstantSource
>   o JDK-8248268: Support KWP in addition to KW
>   o JDK-8204686: Dynamic parallel reference processing support for
> Parallel GC
>   o JDK-8259530: Generated docs contain MIT/GPL-licenced works
> without reproducing the licence [*Reported by Apache Maven*]
>   o JDK-8266766: Arrays of types that cannot be an annotation member
> do not yield exceptions [*Reported by ByteBuddy*]
>   o JDK-8266598: Exception values for
> AnnotationTypeMismatchException are not always informative
> [*Reported by ByteBuddy*]
>   * *Build 25*
>   o JDK-8266653: Change update mode for JDK rpm/deb installers as it
> breaks "yum update" for JDK11+
>   o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
> codes to current
>   o JDK-8229517: Support for optional asynchronous/buffered logging
>   o JDK-8182043: Access to Windows Large Icons
>
>
> *OpenJDK 18 Early Access build 1 is now available at
> **https://jdk.java.net/18* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Issues addressed in 

Re: [VOTE] Release Apache Tomcat 8.5.68

[Martin Grigorov]

On Fri, Jun 11, 2021 at 5:01 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> The proposed Apache Tomcat 8.5.68 release is now available for voting.
>
> The notable changes compared to the (cancelled) 8.5.67 release is:
>
> - Windows installer / uninstaller are now properly-signed.
>
> The notable changes compared to the 8.5.66 release are:
>
> - Improve robustness of HTTP/2 HPACK decoding
>
> - Improvements to the handling of the Transfer-Encoding header
>
> - Review code used to generate Java source from JSPs and tags and remove
> code found to be unnecessary.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.68/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1317/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.68
> 06846f94cda226d1ed0ff7fe05faff177d5b20b6
>
> The proposed 8.5.68 release is:
> [ ] Broken - do not release
> [  X ] Stable - go ahead and release as 8.5.68
>


Regards,
Martin


>
> -
> 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.67

[Martin Grigorov]

On Fri, Jun 11, 2021 at 1:36 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> The proposed Apache Tomcat 8.5.67 release is now available for voting.
>
> The notable changes compared to the 8.5.66 release are:
>
> - Improve robustness of HTTP/2 HPACK decoding
>
> - Improvements to the handling of the Transfer-Encoding header
>
> - Review code used to generate Java source from JSPs and tags and remove
> code found to be unnecessary.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.67/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1316/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.67
> 64f53975de68f57a1aef663d3ff05d4cca7d9a5b
>
> The proposed 8.5.67 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.67
>


Regards,
Martin


>
> -
> 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.7

[Martin Grigorov]

On Tue, Jun 8, 2021 at 8:47 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.7 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.6 are:
>
> - Improve robustness of HTTP/2 HPACK decoding
>
> - Improvements to the handling of the Transfer-Encoding header
>
> - Review code used to generate Java source from JSPs and tags and remove
>code found to be unnecessary.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.7/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1313
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.7
> f0213194669c0d6ac9d60d564f198e3fcf47cbf9
>
> The proposed 10.0.7 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 10.0.7 (stable)
>

Regards,
Martin


>
> -
> 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.48

[Martin Grigorov]

On Thu, Jun 10, 2021 at 1:20 PM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.48 release is now available for voting.
>
> The notable changes compared to 9.0.46 are:
>
> - Improve robustness of HTTP/2 HPACK decoding
>
> - Improvements to the handling of the Transfer-Encoding header
>
> - Review code used to generate Java source from JSPs and tags and remove
>code found to be unnecessary.
>
> - Backport the updated blocking NIO code and optimizations from Tomcat
> 10.0.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.48/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1315
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.48
> 327fb6ff6de541e3d3e321a434d13585cea07875
>
> The proposed 9.0.48 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.48 (stable)
>

Regards,
Martin


>
> Rémy
>

Re: [VOTE] Release Apache Tomcat 10.1.0-M1

[Martin Grigorov]

On Tue, Jun 8, 2021 at 6:37 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M1 release is now available for
> voting.
>
> 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.
>
> This is the first milestone release of the 10.1.x branch.
>
> The notable changes compared to 10.0.x are:
>
> - Remove code (but not the APR/Native Connector) previously marked for
>removal in 10.1.x The APR/Native Connector will almost certainly be
>removed in a future milestone.
>
> - Align the Servlet API implementation with the current Servlet API
>development branch.
>
> - Align the EL API implementation with the current El API development
>branch.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1312
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M1
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
>
> The proposed 10.1.0-M1 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 10.1.0-M1 (alpha)
>

Regards,
Martin


>
> -
> 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.0-M1

[Martin Grigorov]

Hi Mark,

On Tue, Jun 8, 2021 at 6:37 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M1 release is now available for
> voting.
>
> 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.
>
> This is the first milestone release of the 10.1.x branch.
>
> The notable changes compared to 10.0.x are:
>
> - Remove code (but not the APR/Native Connector) previously marked for
>removal in 10.1.x The APR/Native Connector will almost certainly be
>removed in a future milestone.
>
> - Align the Servlet API implementation with the current Servlet API
>development branch.
>
> - Align the EL API implementation with the current El API development
>branch.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1312
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M1
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
>

Any reason why
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M1/ is not
mentioned above ?


>
> The proposed 10.1.0-M1 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 10.1.0-M1 (alpha)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: JDK 17 Early Access build 23 is available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+23-2064 on
Linux x86_64 and aarch64!

Regards,
Martin

On Fri, May 21, 2021 at 10:38 AM Rory O'Donnell 
wrote:

> Hi Mark, **
>
> *OpenJDK 17 Early Access build 23 is now available at
> *_*https://jdk.java.net/17* _
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: _Enhanced Pseudo-Random Number Generators
> _
>   o JEP 382: _New macOS Rendering Pipeline
> _
>   o JEP 391: _macOS/AArch64 Port _
>   o JEP 398: _Deprecate the Applet API for Removal
> _
>   o JEP 409: _Sealed Classes _
>   o JEP 410: _Remove the Experimental AOT and JIT Compiler
> _
>   o JEP 412: _Foreign Function & Memory API (Incubator)
> _
>   o JEP 414: _Vector API (Second Incubator)
> _
>   * Release Notes are available at
> _https://jdk.java.net/17/release-notes
> _
>   * Changes in recent builds that maybe of interest:
>   o Build 23
>   + JDK-8243287: Removal of Unsafe::defineAnonymousClass.
>   o Build 22
>   + *JDK-8266369: New implementation of
> java.nio.channels.Selector on Microsoft Windows. *
>   o Build 21
>   + *JDK-8196415: JARs signed with SHA-1 algorithms are
> restricted by default.*
>   + *JDK-8266858: macOS on ARM early access available.*
>   # The ARM port should behave similarly to the Intel port.
> There are no known feature differences.
>   # When reporting issues on macOS please specify if using
> ARM or x64.
>
> *We need your help in testing new Selector implementation on Windows [1]:*
>
>   * The implementation of the Selector API on Windows has been replaced
> in JDK 17 b22 with a new more scalable implementation [2].
>   * The old select based Selector implementation has been the default
> since Java 1.4 (2002) so replacing it is a significant change.
>   * It would be really helpful to get more testing of the new
> implementation before the fork for Rampdown Phase One on June 10th.
>
> *Other Topics which might be of Interest:*
>
>   * Updates to JEP 411: Deprecate the Security Manager for Removal |
> _Link_
> 
>   * "The meaning, or not, of “LTS” | _Link_
> 
>   * JFR Remote Recording Stream | _Link_
> 
>
> *Project Loom Early-Access Build: **_Build 17-loom+7-342_*
> *(2021/5/11)*
>
>   * These early-access builds are provided under the _GNU General Public
> License, version 2, with the Classpath Exception_
> .
>   * These builds are produced for the purpose of gathering feedback. Use
> for any other purpose is at your own risk.
>   * Please send feedback via e-mail to _loom-...@openjdk.java.net
> _.To send e-mail to this address
> you must first _subscribe to the mailing list_
> .
>
> *Project Panama Early-Access Build: *_*Build 17-panama+3-167*
> _*(2021/5/18)*
>
>   * These early-access builds are provided under the _GNU General Public
> License, version 2, with the Classpath Exception_
> .
>   * This build is aimed at testing a prototype implementation of the
> foreign memory support, foreign function support and native
> extraction tooling from the "foreign-jextract" branch of the Panama
> repo.
>   * Please send feedback via e-mail to _panama-...@openjdk.java.net
> _. To send e-mail to this
> address you must first _subscribe to the mailing list_
> .
>
>
> Rgds,Rory
>
>
> [1]
> _https://mail.openjdk.java.net/pipermail/nio-dev/2021-May/008988.html_
> 
> [2] _https://bugs.openjdk.java.net/browse/JDK-8266369_
> 
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: Time to create Tomcat 10.1.x and master->main migration

[Martin Grigorov]

On Tue, May 18, 2021 at 3:16 PM Romain Manni-Bucau 
wrote:

> +1 to move forward even if jakarta is not yet adopted (there is a single
> time direction - at least at our scale ;))
> -0 to break all clones and related toolings/automotion for hypothetical
> reasons, didn't pay in all projects which did AFAIK
>

Same vote from me!


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 18 mai 2021 à 14:13, Emmanuel Bourg  a écrit :
>
> > 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: [VOTE] Release Apache Tomcat 10.0.6

[Martin Grigorov]

On Sat, May 8, 2021 at 7:18 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.6 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.5 are:
>
> - Ensure the correct escaping of attribute values and search filters in
>the JNDIRealm.
>
> - HandlesTypes should include classes that use the specified annotation
>types on fields or methods.
>
> - Refactor the creation of WebSocket end point, decoder and encoder
>instances to be more IoC friendly. Instances are now created via the
>InstanceManager where possible.
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.6/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1309
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.6
> f725f57f195de035a5cbc6602a1f7a3ad43ee5b5
>
> The proposed 10.0.6 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 10.0.6 (stable)
>

Regards,
Martin


>
> -
> 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.46

[Martin Grigorov]

On Sat, May 8, 2021 at 9:15 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.46 release is now available for voting.
>
> The notable changes compared to the 9.0.45 release are:
>
> - Ensure the correct escaping of attribute values and search filters in
>the JNDIRealm.
>
> - HandlesTypes should include classes that use the specified annotation
>types on fields or methods.
>
> - Refactor the creation of WebSocket end point, decoder and encoder
>instances to be more IoC friendly. Instances are now created via the
>InstanceManager where possible.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.46/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1310/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.46
> 37ae42a2996911b9ba6b88e7b0828f855b9d38f6
>
> The proposed 9.0.46 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.46
>

Regards,
Martin


>
> -
> 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.66

[Martin Grigorov]

On Sun, May 9, 2021 at 2:12 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.66 release is now available for voting.
>
> The notable changes compared to the 8.5.65 release are:
>
> - Ensure the correct escaping of attribute values and search filters in
>the JNDIRealm.
>
> - HandlesTypes should include classes that use the specified annotation
>types on fields or methods.
>
> - Refactor the creation of WebSocket end point, decoder and encoder
>instances to be more IoC friendly. Instances are now created via the
>InstanceManager where possible.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.66/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1311/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.66
> 12afa2cd11ffa9522cd98acc228ecb1bad6b8006
>
> The proposed 8.5.66 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.66
>

Regards,
Martin


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

Re: Disabling Some Test Cases by Pattern

[Martin Grigorov]

Hi Igal,

On Mon, May 10, 2021 at 4:28 AM Igal Sapir  wrote:

> I am trying to disable some test cases that constantly fail on my machine.
> I have added the following to build.properties:
>
>
> test.exclude=org.apache.catalina.tribes.group.Test**,org.apache.catalina.tribes.group.interceptors.Test**
>
> But I still get the following failures:
>
>[concat] Testsuites with failed tests:
>[concat]
>
> TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO2.txt
>[concat]
>
> TEST-org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator.NIO2.txt
>[concat]
>
> TEST-org.apache.catalina.tribes.group.interceptors.TestOrderInterceptor.NIO2.txt
>[concat]
>
> TEST-org.apache.catalina.tribes.group.interceptors.TestTcpFailureDetector.NIO2.txt
>
> I expect the pattern [org.apache.catalina.tribes.group.interceptors.Test**]
> to exclude the last 3 for example, but that doesn't happen.
>
> What am I doing wrong?
>

Looking at
https://github.com/apache/tomcat/blob/9747a3a6334369deb9b5bef1b17b1fe0ce774cdf/build.xml#L2024-L2039
I think you should use '/' instead of '.',
i.e.
test.exclude=org/apache/catalina/tribes/group/Test*,org/apache/catalina/tribes/group/interceptors/Test*


>
> Thanks,
>
> Igal
>

Re: JDK 17 Early Access build 21 is available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and test pass successfully with JDK 17-ea+21-1866 on
Linux x86_64 and aarch64!

Regards,
Martin

On Mon, May 10, 2021 at 12:04 PM Rory O'Donnell 
wrote:

>
> Hi Mark, **
>
> *OpenJDK 17 Early Access build 21 is now available at
> **https://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>
>   * Schedule
>   o 2021/06/10 Rampdown Phase One
>   o 2021/07/15 Rampdown Phase Two
>   o 2021/08/05 Initial Release Candidate
>   o 2021/08/19 Final Release Candidate
>   o 2021/09/14 General Availability
>
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>   o JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>
>   * Release Notes are available at https://jdk.java.net/17/release-notes
> 
>
>   * Changes in recent builds that maybe of interest:
>   o Build 21:
>   + JDK-8196415: JARs signed with SHA-1 algorithms are
> restricted by default.
>   + JDK-8265989: System property for the native character
> encoding name.
>   + JDK-8265137: java.util.Random suddenly has new public
> methods nowhere documented.
>   # [*Reported by Apache Lucene]*
>   o Build 20
>   + JDK-8037397: RegEx pattern matching loses character class
> after intersection (&&) operator.
>   + JDK-8264208: A new public method that returns the `Charset`
> used in the `Console.
>   o Build 19
>   + JDK-8228988: AnnotationParser throws NullPointerException on
> incompatible member type.
>   # *[Reported by ByteBuddy]*
>   + JDK-8258794: Support for CLDR version 39.
>   + JDK-8262108: SimpleDateFormat formatting broken for sq_MK
> Locale.
>   # *[**Reported by ApacheCommons]*
>   o Build 18
>   + JDK-8260693: Provide the support for specifying a signer in
> keytool -genkeypair.
>   + JDK-8263763: Synthetic constructor parameters of enum are
> not considered for annotation indices.
>   # *[Reported by ByteBuddy]*
>
> *Topics of interest from 'Insider Java':*
>
>   * Security and Sandboxing Post SecurityManager : Link
> <
> https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/
> >
>   * Foreign Memory Access and NIO channels - Going Further : Link
> 
>
> *Project Loom Early-Access Build: **Build 17-loom+6-225*
> *(2021/4/1)*
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> .
>   * These builds are produced for the purpose of gathering feedback. Use
> for any other purpose is at your own risk.
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .**
>
> *April 2021 Critical Patch Update Released:*
>
>   * As part of the April 2021 CPU we released JDK 16.0.1, JDK 11.0.11
> LTS, JDK 8u291 and JDK 7u301 as well as OpenJDK 16.0.1 (publicly
> available).
>
> Rgds,Rory
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [VOTE] Apache Tomcat migration tool for Jakarta EE 1.0.0

[Martin Grigorov]

On Tue, May 4, 2021 at 3:06 PM Mark Thomas  wrote:

> The proposed Apache Tomcat migration tool for Jakarta EE 1.0.0 is now
> available for voting.
>
> The significant changes since 0.2.0 are:
>
> - Further fixes to exclude javax.xml packages that are not part of
>Java EE from the migration
>
> - The class transformer now validates that the target classes in the
>Jakarta namespace exist in the runtime environment
>
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v1.0.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1308/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/1.0.0
> 2a27b633f456710dc5d51680344ca7f047642a60
>
> The proposed 1.0.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [ X ] +1: Acceptable. Go ahead and release.
>

Regards,
Martin


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

Re: [VOTE] Release Apache Tomcat 7.0.109

[Martin Grigorov]

On Thu, Apr 22, 2021 at 10:13 PM Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.109 release is now available for voting.
> Please note that this is the last Tomcat 7 release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.109/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1307/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.109
> 2cdef2c0241cdf70b5edd88d3733a52e6b675047
>
> The proposed 7.0.109 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 7.0.109 Stable
>

Martin


>
> Regards,
> Violeta
>

Re: JDK 17 Early Access build 18 is available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests passed successfully with JDK 17-ea+18-1490
on Linux x86_64 and aarch64!

Regards,
Martin

On Tue, Apr 20, 2021 at 1:35 PM Rory O'Donnell 
wrote:

>
> *Hi Mark, *
>
> *OpenJDK 17 Early Access build 18is now available at
> **https://jdk.java.net/17 *
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>   * Release Notes are available at http://jdk.java.net/17/release-notes
> 
>
>
> **G1 pauses may be extremely long with EA build JDK-17+18*
>
> *During performance testing we noticed that due to a recent change
> (JDK-8262068) GC pauses after a G1 full GC may be extremely slow. The
> problem has been fixed with JDK-8264987 and that has already been
> integrated. This change will be available with the following EA build
> JDK-17+19.  For more technical info please see [1]
>
>
> *JEP 382 [2]**  - Starting with build 19, **JDK 17 for macOS is
> *temporarily* switched from using OpenGL**to using Apple's Metal
> API**for Java 2D rendering.*
>
> Heads up to anyone who is testing JDK 17 for running apps on macOS.
> Starting with build 19, JDK 17 for macOS is *temporarily* switched from
> using OpenGL to using Apple's Metal API for Java 2D rendering.
>
> If you are running any kind of 2D / Swing/ AWT UI application on macOS,
> and see any rendering related problems
> starting with JDK 17 b19, please do report them to us along with a test
> case and screen shots.
>
> You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which
> implicitly disables Metal - to confirm that it is a Metal related
> rendering glltch.
>
>
> Rgds,Rory
>
> [1]
>
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-April/034745.html
> [2] https://openjdk.java.net/jeps/382
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: TCK Signature for EL API

[Martin Grigorov]

Hi,

On Tue, Apr 6, 2021 at 7:22 PM Raymond Augé
 wrote:

> Great news! I'm both sad that the annotations caused you pain (the complete
> opposite was intended) and happy that you managed to work around the
> problem.
>
> It's not by coincidence that BND uses the intermediate state of the
> manifest to go between the annotations and the module info. However, I
> wasn't sure that this would cover all cases particularly w.r.t. the service
> loader handling. However, it appears it does.
>

I am not sure how exactly BND works but at [1] I see that ServiceConsumer
annotation has retention policy CLASS.
Would it be possible to use SOURCE instead ? This way at compile time it
could be used to generate module-info.class and be discarded, i.e. the
annotation won't be in the API .class


1.
https://github.com/bndtools/bnd/blob/ba0bd37c2c33afe4ccfd8660b1a37b1c1ac52eaa/biz.aQute.bnd.annotation/src/aQute/bnd/annotation/spi/ServiceConsumer.java#L33


>
> Sincerely,
> Ray
>
>
> On Tue, Apr 6, 2021 at 10:39 AM Mark Thomas  wrote:
>
> > On 02/04/2021 13:58, Raymond Augé wrote:
> > > I just wanted to make a note that removing the annotation will also
> mean
> > > that the module-info.java will need to be manually managed since bnd
> also
> > > generated that based on the annotations.
> >
> > Good news. I compared the module-info.class files for the EL API jar and
> > the WebSocket API jar between the 9.0.45 release (that used the
> > annotation) and a current build from source (that doesn't use the
> > annotation) and they are identical. On that basis I think we have a
> > working solution.
> >
> > Mark
> >
> >
> > >
> > > Just FYI,
> > > - Ray
> > >
> > > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO  >
> > > wrote:
> > >
> > >> That's awesome news.
> > >>
> > >> I'm glad it's something that can be achieved without too much effort.
> > >> I understand and buy the pragmatic approach.
> > >>
> > >> But at the same time, if we can do a step forward and get even closer
> to
> > >> being certified, that'd be great.
> > >>
> > >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas  a écrit :
> > >>
> > >>> I've been playing with this a bit more and it appears we can simply
> > >>> hard-code the "Require-Capability" header in el-api.jar.bnd
> > >>>
> > >>> Having taken the time to look at the actual values generated for
> these
> > >>> API JARs, this does look like something that would be simple to
> > maintain
> > >>> manually - especially for the API JARs where adding a new use of
> > >>> ServiceLoader is likely to happen fairly rarely.
> > >>>
> > >>> We should be able to remove the Bnd annotation in
> > >>> - 10.0.x for 10.0.6 onwards
> > >>> - 9.0.x for 9.0.46 onwards
> > >>>
> > >>> We'll certainly do this for the API JARs. I think we'll leave it in
> > >>> place for the implementation JARs
> > >>>
> > >>> I have a few things on my TODO list at the moment but I don't see
> why I
> > >>> shouldn't be able to get this done for the May set of releases.
> > >>>
> > >>> Mark
> > >>>
> > >>>
> > >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> >  Hi,
> > 
> >  AFAIK TomEE will try to be certified and will try to not fork as
> much
> > >> as
> >  possible Tomcat code so can be neat to solve it in particular when
> >  relatively easy:
> > 
> >  1. compile tomcat classes with bnd as of today
> >  2. run bnd to get the manifest.mf (
> >  3. post process tomcat classes to remove bnd from the .class
> >  4. jar it
> > 
> >  should solve the process and does not look crazy compared to what
> > >> tomcat
> >  already does, no?
> > 
> >  Alternative is indeed to drop bnd since the manifest is quite easy
> to
> > >>> write
> >  manually or with an ant task to filter the version for tomcat case,
> at
> >  least for spec jars (it is harder for the impl but here bnd is
> fine).
> > 
> >  Romain Manni-Bucau
> >  @rmannibucau  |  Blog
> >   | Old Blog
> >   | Github <
> > >>> https://github.com/rmannibucau> |
> >  LinkedIn  | Book
> >  <
> > >>>
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > 
> > 
> > 
> >  Le jeu. 1 avr. 2021 à 09:19, Mark Thomas  a
> écrit :
> > 
> > > On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> > >> Hello,
> > >>
> > >> It appears the TCK Signature tests will not be relaxed (see 1 &
> 2),
> > >> and I'm wondering how Tomcat will proceed with the bnd annotation
> in
> > >> the EL API? Will it be removed in the next release?
> > >
> > > Currently, there are no plans to change the Tomcat code.
> > >
> > > We do run the TCKs but take a pragmatic view of any failures. For
> > > example, the Servlet TCK test that tests setting a context path in
> > > web.xml always fails because 

Re: [VOTE] Release Apache Tomcat Native 1.2.28

[Martin Grigorov]

On Thu, Apr 1, 2021 at 4:56 PM Mark Thomas  wrote:

> Version 1.2.28 includes the following changes compared to 1.2.27
>
> - Correct regression in previous fix for BZ 65181
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.28 release is
>   [ X ] Stable, go ahead and release
>   [ ] Broken because of ...
>
>
Tested build on Linux x86_64 and aarch64, and runtime usage on aarch64 with
HTTP2 - "INFO: The ["https-openssl-apr-8080"] connector has been configured
to support negotiation to [h2] via ALPN"

Regards,
Martin

Thanks,
>
> Mark
>
>
> [1]
>
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.28
> [2]
>
> https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=5566385ab63361d8d707613508d803964a15a1f8
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: OpenJDK 17 Early Access build 16 is now available

[Martin Grigorov]

On Fri, Apr 2, 2021 at 12:19 PM Rémy Maucherat  wrote:

> On Fri, Apr 2, 2021 at 10:09 AM Rory O'Donnell 
> wrote:
>
> >
> > Hi Mark,
> >
> > *OpenJDK 17 Early Access build 16 is now available at
> > **http://jdk.java.net/17* 
> >
> >   * These early-access , open-source builds are provided under the
> >   o GNU General Public License, version 2, with the Classpath
> > Exception 
> >
> >   * Schedule (proposed)
> >   o 2021/06/10 Rampdown Phase One
> >   o 2021/07/15 Rampdown Phase Two
> >   o 2021/08/05 Initial Release Candidate
> >   o 2021/08/19 Final Release Candidate
> >   o 2021/09/14 General Availability
> >
> >   * Features:*Heads-up on an important Candidate JEP
> > *
> >   o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
> > *
> >   o successor to JEP 396: Strongly Encapsulate JDK Internals by
> > Default 
> >   o strongly encapsulate all internal elements of the JDK by default
> >   o exception for Critical Internal APIs such as /sun.misc.Unsafe/
> >
>
> Our use of Unsafe does indeed seem to still work, and the testsuite and
> OpenSSL TLS support is still functional.
> It would be good to get a better method to deallocate a direct ByteBuffer,
> eventually ...
>

This has been mentioned recently at
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005269.html

"Finally, a related point: The sun.misc package has been exported and

available for reflection since JDK 9. It was neither removed nor
strongly encapsulated in JDK 9. It was available in JDK 9, and continues

to be available in JDK 17."


> Rémy
>
>
> >
> >   * JEPs targeted to JDK 17, so far:
> >   o JEP 356: Enhanced Pseudo-Random Number Generators
> > 
> >   o JEP 382: New macOS Rendering Pipeline
> > 
> >   o JEP 391: macOS/AArch64 Port 
> >   o JEP 398: Deprecate the Applet API for Removal
> > 
> >
> >   * Release Notes are available at http://jdk.java.net/17/release-notes
> > 
> >   * Changes in recent builds that maybe of interest:
> >   o Build 16
> >   + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
> > device throws FileSystemException: "nul: Incorrect function"
> > (win)
> >   # Reported by Apache Ant
> >   o Build 15
> >   + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
> > prevents dnf install/updates
> >   o Build 14
> >   + JDK-8262277: URLClassLoader.getResource throws undocumented
> > IllegalArgumentException
> >   + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
> > conversion with a sign character
> >
> > *Project Loom Early-Access Build: **Build 17-loom+5-191*
> > *(2021/3/19)*
> >
> >   * These early-access builds are provided under the GNU General Public
> > License, version 2, with the Classpath Exception
> > .
> >   * These builds are produced for the purpose of gathering feedback. Use
> > for any other purpose is at your own risk.
> >   * Please send feedback via e-mail to loom-...@openjdk.java.net
> > . To send e-mail to this address
> > you must first subscribe to the mailing list
> > .
> >
> > *Quality Report for March 2021 was published here [1]*.
> >
> >   * Thanks to everyone who contributed by creating features or
> > enhancements, logging  bugs, or downloading and testing the
> > early-access builds.
> >
> > *Worth reading - **The Arrival of Java 16!
> > *
> >
> >   * JDK 16 Migration guide -
> >
> https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
> >   * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
> > respond to this *tweet
> > *.
> >   * Oracle Developer Live event - Individual sessions:
> >  1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
> > https://youtu.be/1acKCBbd6f4 
> >  2. *Java Language Futures: Spring 2021* (Gavin Bierman):
> > https://youtu.be/K9SVV0XNIP8 
> >  3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
> > Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
> > 
> >  4. *Learn Java 16 with IntelliJ IDEA *(Trisha 

Re: OpenJDK 17 Early Access build 16 is now available

[Martin Grigorov]

Hi Rory,

Apache Tomcat 10.x build and tests pass successfully with JDK 17-ea+16-1315
on Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Apr 2, 2021 at 11:02 AM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *OpenJDK 17 Early Access build 16 is now available at
> **http://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>
>   * Schedule (proposed)
>   o 2021/06/10 Rampdown Phase One
>   o 2021/07/15 Rampdown Phase Two
>   o 2021/08/05 Initial Release Candidate
>   o 2021/08/19 Final Release Candidate
>   o 2021/09/14 General Availability
>
>   * Features:*Heads-up on an important Candidate JEP
> *
>   o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
> *
>   o successor to JEP 396: Strongly Encapsulate JDK Internals by
> Default 
>   o strongly encapsulate all internal elements of the JDK by default
>   o exception for Critical Internal APIs such as /sun.misc.Unsafe/
>
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>
>   * Release Notes are available at http://jdk.java.net/17/release-notes
> 
>   * Changes in recent builds that maybe of interest:
>   o Build 16
>   + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
> device throws FileSystemException: "nul: Incorrect function"
> (win)
>   # Reported by Apache Ant
>   o Build 15
>   + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
> prevents dnf install/updates
>   o Build 14
>   + JDK-8262277: URLClassLoader.getResource throws undocumented
> IllegalArgumentException
>   + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
> conversion with a sign character
>
> *Project Loom Early-Access Build: **Build 17-loom+5-191*
> *(2021/3/19)*
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> .
>   * These builds are produced for the purpose of gathering feedback. Use
> for any other purpose is at your own risk.
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> *Quality Report for March 2021 was published here [1]*.
>
>   * Thanks to everyone who contributed by creating features or
> enhancements, logging  bugs, or downloading and testing the
> early-access builds.
>
> *Worth reading - **The Arrival of Java 16!
> *
>
>   * JDK 16 Migration guide -
> https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
>   * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
> respond to this *tweet
> *.
>   * Oracle Developer Live event - Individual sessions:
>  1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
> https://youtu.be/1acKCBbd6f4 
>  2. *Java Language Futures: Spring 2021* (Gavin Bierman):
> https://youtu.be/K9SVV0XNIP8 
>  3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
> Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
> 
>  4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:
> *https://youtu.be/1hyWJTjxeGM **
>  5. *How Records Can Improve Serialization* (Julia Boes, Chris
> Hegarty): https://youtu.be/44D8M6ZxuLU
> 
>  6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya
> Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8
> 
>  7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson):
> https://youtu.be/bHcKTYy_Nec 
>  8. *Project Skara: Migrating OpenJDK to Git and GitHub* (Erik
> Duveblad, Robin Westberg): https://youtu.be/-pBgplk7fVk
>  

Re: [VOTE] Release Apache Tomcat 10.0.5

[Martin Grigorov]

On Tue, Mar 30, 2021 at 11:46 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.5 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.4 are:
>
> - Fix a regression in 10.0.4 that meant that an error during an
>asynchronous read broke all future asynchronous reads associated with
>the same request instance.
>
> - Prevent concurrent calls to ServletInputStream.isReady() corrupting
>the input buffer.
>
> - Update the packaged version of Tomcat Native to 1.2.27 to pick up
>binaries built with OpenSSL 1.1.1k
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.5/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1304
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.5
> 328d87e3d1ef41c46b5173114e30d37394bd68b9
>
> The proposed 10.0.5 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 10.0.5 (stable)
>

Martin


>
> -
> 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.65

[Martin Grigorov]

On Tue, Mar 30, 2021 at 4:13 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.65 release is now available for voting.
>
> The notable changes compared to the 8.5.64 release are:
>
> - Fix a regression in 8.5.64 that meant that an error during an
>asynchronous read broke all future asynchronous reads associated with
>the same request instance.
>
> - Prevent concurrent calls to ServletInputStream.isReady() corrupting
>the input buffer.
>
> - Update the packaged version of Tomcat Native to 1.2.27 to pick up
>binaries built with OpenSSL 1.1.1k
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.65/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1306/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.65
> 752c1b9221f7d51a9f0f13d5ce83540589e228e4
>
> The proposed 8.5.65 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.65
>

Martin


>
> -
> 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.45

[Martin Grigorov]

On Tue, Mar 30, 2021 at 1:52 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.45 release is now available for voting.
>
> The notable changes compared to the 9.0.44 release are:
>
> - Fix a regression in 9.0.44 that meant that an error during an
>asynchronous read broke all future asynchronous reads associated with
>the same request instance.
>
> - Prevent concurrent calls to ServletInputStream.isReady() corrupting
>the input buffer.
>
> - Update the packaged version of Tomcat Native to 1.2.27 to pick up
>binaries built with OpenSSL 1.1.1k
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.45/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1305/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.45
> 4dcf07fd1b53d3934d408060c6ef1ea13894c16f
>
> The proposed 9.0.45 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.45
>

Regards,
Martin


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

Re: Release Announcement: General Availability of Java 16 / JDK 16

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 16 16+36-2231
and 17-ea+13-1000 on both Linux x86_64 and aarch64!

Regards,
Martin

On Tue, Mar 16, 2021 at 5:26 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *Release Announcement: General Availability of Java 16 / JDK 16 *
>
> **
>
>   * JDK 16, the reference implementation of Java 16, is now Generally
> Available. [1]
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> http://jdk.java.net/16/ 
>   * JDK 16 Release notes
> 
>
> *JDK 16 includes the following features [2]:*
>
>   * JEP 338:Vector API (Incubator) 
>   * JEP 347:Enable C++14 Language Features
> 
>   * JEP 357:Migrate from Mercurial to Git
> 
>   * JEP 369:Migrate to GitHub 
>   * JEP 376:ZGC: Concurrent Thread-Stack Processing
> 
>   * JEP 380:Unix-Domain Socket Channels  >
>   * JEP 386:Alpine Linux Port 
>   * JEP 387:Elastic Metaspace 
>   * JEP 388:Windows/AArch64 Port 
>   * JEP 389:Foreign Linker API (Incubator)
> 
>   * JEP 390:Warnings for Value-Based Classes
> 
>   * JEP 392:Packaging Tool 
>   * JEP 393:Foreign-Memory Access API (Third Incubator)
> 
>   * JEP 394:Pattern Matching for instanceof
> 
>   * JEP 395:Records 
>   * JEP 396:Strongly Encapsulate JDK Internals by Default
> 
>   * JEP 397:Sealed Classes (Second Preview)
> 
>
> Thanks to everyone who contributed to JDK 16, whether by creating
> features or enhancements, logging bugs, or
>
> downloading and testing the early-access builds.
>
> *OpenJDK 17 Early Access build 13 is now available at
> http://jdk.java.net/17 
> *
>
>
> **
>
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>
>   * Release Notes are available at http://jdk.java.net/17/release-notes
> 
>
>   * Significant changes since the last availability email:
>   o JDK-8259709: Disable SHA-1 XML Signatures (b13)
>   o JDK-6323374: (coll) Optimize Collections.unmodifiable* and
> synchronized*(b13)
>   o JDK-8139348: Deprecate 3DES and RC4 in Kerberos (b12)
>   o JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in
> SSLSocketImpl (b11)
>   o JDK-8235139: Deprecate the socket impl factory mechanism(b10)
>   o JDK-8225081: Remove Telia Company CA certificate expiring in
> April 2021(b9)
>
>
> *Project Lanai Early-Access Builds
> *
>
>   * EA 10 Build 17-lanai+3-133 (2021/3/2) is available -
> http://jdk.java.net/lanai/
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>
> *Project Loom Early-Access Builds*
>
>   * Build 17-loom+4-174 (2021/3/12) is available -
> http://jdk.java.net/loom/
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>
> *Project Panama Early-Access Builds
> *
>
>   * Build 17-panama+2-51 (2021/2/12) is available -
> http://jdk.java.net/panama/
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>
> Rgds,Rory
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005188.html
>
> [2] https://openjdk.java.net/projects/jdk/16/
> 
>
>

Re: Refactoring the HTTP/2 API

[Martin Grigorov]

On Thu, Mar 11, 2021 at 12:03 PM Mark Thomas  wrote:

> Hi all,
>
> I've been spending a lot of time looking at the HTTP/2 code lately. It
> has become apparent to me that the naming of various methods is not as
> clear as it code be. For example, it is not clear if a method is:
> - triggered by receiving a given frame
> - will send a given frame
> - is called before/after receiving/sending a given frame to update state
> - somethign else
> I'd like to fix this. Mostly, this means renaming a lot of the methods.
>
> In 10.0.x and 9.0.x much of the API is package private so we are
> relatively free to make changes. That is not the case with 8.5.x.
> However, I'd *really* like to keep the HTTP/2 code aligned between all
> versions as much as possible.
>
> We have made changes to the 8.5.x public API in the past (adding
> methods, adding parameters to methods) and we haven't received any
> negative feedback afterwards. Also, the HTTP/2 code is unlikely to be
> extended for some custom purpose.
>
> Given all of the above, I'd like to bring the current HTTP/2 code into
> alignment across all three versions. The majority of the changes will be
> in the public API in 8.5.x.
>
> Are there any objections to me doing this?
>

No objections from me!

Martin


>
> Mark
>
> -
> 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.64

[Martin Grigorov]

On Fri, Mar 5, 2021 at 1:49 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.64 release is now available for voting.
>
> The notable changes compared to the 8.5.63 release are:
>
> - Improvements to Async and non-blocking IO error handling
>
> - Improvements to handling of OpenSSL errors
>
> - Align the behaviour when null is passed to the ServletResponse
>methods setCharacterEncoding(), setContentType() and setLocale()
>with the recent clarification from the Jakarta Servlet project of
>the expected behaviour in these cases.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.64/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1302/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.64
> c47f86adea090175669df8b2ca04c93050bcaf8c
>
> The proposed 8.5.64 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.64
>


Martin


>
> -
> 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

[Martin Grigorov]

On Fri, Mar 5, 2021 at 12:22 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.44 release is now available for voting.
>
> The notable changes compared to the 9.0.43 release are:
>
> - Improvements to Async and non-blocking IO error handling
>
> - Improvements to handling of OpenSSL errors
>
> - Align the behaviour when null is passed to the ServletResponse
>methods setCharacterEncoding(), setContentType() and setLocale()
>with the recent clarification from the Jakarta Servlet project of
>the expected behaviour in these cases.
>
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.44/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1301/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.44
> 7b4007a6a77300056f4681b064d7332c2284cbdd
>
> The proposed 9.0.44 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.44
>


Martin


>
> -
> 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.4

[Martin Grigorov]

On Fri, Mar 5, 2021 at 1:26 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.4 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 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
>
> The notable changes compared to 10.0.2 are:
>
> - Integration of the Apache Tomcat Migration Tool for Jakarta EE via
>the webapps-javaee directory
>
> - Improvements to Async and non-blocking IO error handling
>
> - Add support for Unix Domain Sockets to the APR/Native connector
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.4/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1303
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.4
> ec47d24b49bc176f47b786bc96248e94d1823685
>
> The proposed 10.0.4 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 10.0.4 (stable)
>

Tested with Apache Wicket 9.x examples - both as already migrated Jakarta
app and as Javax app deployed via webapps-javaee.

Martin


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

Re: [tomcat] branch master updated: Filter out classes streams through class file transformers

[Martin Grigorov]

On Wed, Feb 17, 2021 at 5:49 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 6ef6875  Filter out classes streams through class file
> transformers
> 6ef6875 is described below
>
> commit 6ef68752dc43f9d459e0ae23a4a767112ab531b9
> Author: remm 
> AuthorDate: Wed Feb 17 16:46:41 2021 +0100
>
> Filter out classes streams through class file transformers
>
> Make getResourceAsStream go through the ClassFileTransformer(s) for
> .class resources. In a way this is consistent, but the actual reason is
> helping JSP work better [JDT uses that to do its compilation] if
> choosing a very basic runtime Jakarta conversion. I'm not seeing any
> basis for doing it, but it's completely unlikely to break anything
> either.
> ---
>  .../catalina/loader/WebappClassLoaderBase.java | 37
> ++
>  1 file changed, 37 insertions(+)
>
> diff --git a/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> index 2bc07a1..d809c3e 100644
> --- a/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> +++ b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> @@ -16,6 +16,8 @@
>   */
>  package org.apache.catalina.loader;
>
> +import java.io.ByteArrayInputStream;
> +import java.io.ByteArrayOutputStream;
>  import java.io.File;
>  import java.io.FilePermission;
>  import java.io.IOException;
> @@ -1136,6 +1138,41 @@ public abstract class WebappClassLoaderBase extends
> URLClassLoader
>  WebResource resource = resources.getClassLoaderResource(path);
>  if (resource.exists()) {
>  stream = resource.getInputStream();
> +// Filter out .class resources through the ClassFileTranformer
> +if (name.endsWith(".class") && transformers.size() > 0) {
>

nit: you could use CLASS_FILE_SUFFIX as you did below


> +// If the resource is a class, decorate it with any
> attached transformers
> +ByteArrayOutputStream baos = new ByteArrayOutputStream();
> +byte[] buf = new byte[8192];
> +int numRead;
> +try {
> +while ((numRead = stream.read(buf)) >= 0) {
> +baos.write(buf, 0, numRead);
> +}
> +} catch (IOException e) {
> +
> log.error(sm.getString("webappClassLoader.transformError", name), e);
> +return null;
> +} finally {
> +try {
> +stream.close();
> +} catch (IOException e) {
> +}
> +}
> +byte[] binaryContent = baos.toByteArray();
> +String internalName = path.substring(1, path.length() -
> CLASS_FILE_SUFFIX.length());
> +for (ClassFileTransformer transformer :
> this.transformers) {
> +try {
> +byte[] transformed = transformer.transform(
> +this, internalName, null, null,
> binaryContent);
> +if (transformed != null) {
> +binaryContent = transformed;
> +}
> +} catch (IllegalClassFormatException e) {
> +
> log.error(sm.getString("webappClassLoader.transformError", name), e);
> +return null;
> +}
> +}
> +stream = new ByteArrayInputStream(binaryContent);
> +}
>  trackLastModified(path, resource);
>  }
>  try {
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat-jakartaee-migration] 03/07: Reduce object creation during conversion

[Martin Grigorov]

On Tue, Feb 9, 2021 at 7:18 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository
> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>
> commit 4a0b09d3e43dfcb35c5a7488a222b1c7ea941669
> Author: Mark Thomas 
> AuthorDate: Tue Feb 9 14:25:17 2021 +
>
> Reduce object creation during conversion
> ---
>  src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
> b/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
> index 9d398d7..cc06bde 100644
> --- a/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
> +++ b/src/main/java/org/apache/tomcat/jakartaee/ClassConverter.java
> @@ -46,8 +46,12 @@ public class ClassConverter implements Converter {
>  if (constantPool[i] instanceof ConstantUtf8) {
>  ConstantUtf8 c = (ConstantUtf8) constantPool[i];
>  String str = c.getBytes();
> -c = new ConstantUtf8(profile.convert(str));
> -constantPool[i] = c;
> +String converted = profile.convert(str);
> +// Object comparison is deliberate
> +if (converted != str) {
> +c = new ConstantUtf8(profile.convert(str));
>

Does it need to convert the second time ?
 c = new ConstantUtf8(converted) should work too, no ?


> +constantPool[i] = c;
> +}
>  }
>  }
>
>
>
> -
> 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 0.2.0

[Martin Grigorov]

On Thu, Feb 11, 2021 at 7:47 PM Mark Thomas  wrote:

> The proposed Apache Tomcat migration tool for Jakarta EE 0.2.0 is now
> available for voting.
>
> The significant changes since 0.1.0 are:
>
> - Various fixes to the packages that are and are not converted
>
> - A new option to process zip archives in memory to support zip files
>   that use options that are incompatible with a streaming approach
>
> - A new option to exclude files from transformation
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.2.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1299/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/0.2.0
> 041e256e92078cd3b16a9adcd77faf257e3a5c88
>
> The proposed 0.2.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [ X ] +1: Acceptable. Go ahead and release.
>

Built it from sources.
Migrated Apache Wicket 9.x examples application, with streaming.

Martin


> Thanks,
>
> Mark
>
> -
> 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

[Martin Grigorov]

On Wed, Feb 10, 2021 at 12:24 PM Mark Thomas  wrote:

> On 10/02/2021 09:30, Martin Grigorov wrote:
>
> 
>
> > Believe me it is not that simple.
> > Spring Boot Maven/Gradle plugins produce a jar file that contains other
> jar
> > files inside. Those jar files are not compressed for optimization reasons
> > and the Jakarta EE migration tool cannot handle that because
> > java.util.jar.* APIs does not provide a way to not compress, after
> > re-writing the classes/files.
> > So, a Spring Boot application cannot be really migrated to Jakarta EE.
>
> This is no longer correct. Use of the "-zipInMemory" option will address
> this.
>

Good to know!


>
> There are other complications with Spring Boot applications (you need to
> swap out the Tomcat implementation JARs as well) but those should be
> solvable. Whether it is the migration tool's job to solve them is a
> different question.
>
> Mark
>
> -
> 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

[Martin Grigorov]

Hi Romain,

On Wed, Feb 10, 2021 at 10:39 AM Romain Manni-Bucau 
wrote:

> Le mer. 10 févr. 2021 à 09:32, Martin Grigorov  a
> écrit :
>
> > Hi,
> >
> > On Tue, Feb 9, 2021 at 11:12 PM Mark Thomas  wrote:
> >
> > > Hi all,
> > >
> > > I've been looking at the options to integrate the Java EE to Jakarta EE
> > > migration functionality into Tomcat 10.
> > >
> > > There are essentially two ways to do this: deployment time and runtime.
> > >
> > > The simplest solution to implement is probably a separate
> webapps-legacy
> > > directory (or some other name) where WARs and DIRs added to that
> > > directory get converted to Jakarta EE with the new version being placed
> > > in the webapps directory. There are complexities (such as handling an
> > > updates of the legacy WAR) but they should be manageable.
> > >
> > > A more complex version of the deploy time solution has the legacy web
> > > application placed in webapps, identified as a legacy webapp and then
> > > replaced with the new version (several ways to do this). The hard part
> > > here is the identification of the webapp as a Java EE app. The only
> > > reliable way to do this is class scanning and that is slow.
> > >
> > > The runtime approach converts classes and static resources as they are
> > > loaded. The classes are relatively easy to handle. A
> > > ClassFileTransformer can be added to the WebappClassLoader to do this.
> > > The static files are more of a problem. The good news is that the
> > > WebResources refactoring means static file access all goes through the
> > > same code but the filtering required essentially means we'd need to
> load
> > > static files into memory - regardless of size, convert them, and then
> > > update the cache with the converted version. That is likely to have a
> > > performance impact.
> > >
> > > Because of the performance impacts of handling static resources, the
> > > runtime approach also needs a way to identify applications that need
> > > conversion. I don't see a reliable, performant way to do that. Which, I
> > > think, leaves us with the simple deployment time approach and something
> > > (filename, special directory, something else) to mark an app as needing
> > > conversion.
> > >
> > > A final point, which probably should have been first, is is there a
> > > demand for this feature? Early indications from the users list and
> $work
> > > is that there is (going to be) a demand for this feature.
> > >
> > > Thoughts?
> > >
> >
> > We should also think about Tomcat Embedded! Many of the modern web
> > frameworks use embedded Tomcat/Jetty/Undertow.
> > I guess it should be even easier for them to set a property saying "I
> need
> > this app to be migrated" or to put it in the special folder
> > (webapps-legacy/).
> > We just need to make sure tomcat-embed is taken into account for the
> > eventual solution!
> >
>
> I'm actually not sure:
>
> 1. embed case almost never have a webapps/ folder and always uses flat
> classpath so only option is a javaagent but 2.
>

"almost never" does not mean that it is not possible to do
org.apache.catalina.startup.Tomcat#addContext("someName",
"/path/to/folder/with/static/files/which/need/to/be/migrated")
javaagent alone won't help you for any non-class files


> 2. embed case does not have this standalone status where you put an app in
> another one so if you want to change you change it in your build
>

I don't really understand you here


>
> I can see you speaking of spring-boot or so but this is all solved by maven
> shade plugin or gradle equivalent task so I wouldn't invest in a solution
> which - for this case - wouldnt be used compared to the standalone case
> which still has ops vs dev coverage and need IMHO.
>

Believe me it is not that simple.
Spring Boot Maven/Gradle plugins produce a jar file that contains other jar
files inside. Those jar files are not compressed for optimization reasons
and the Jakarta EE migration tool cannot handle that because
java.util.jar.* APIs does not provide a way to not compress, after
re-writing the classes/files.
So, a Spring Boot application cannot be really migrated to Jakarta EE.


>
>
> >
> > Martin
> >
> >
> > > Mark
> > >
> > > -
> > > 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

[Martin Grigorov]

Hi,

On Tue, Feb 9, 2021 at 11:12 PM Mark Thomas  wrote:

> Hi all,
>
> I've been looking at the options to integrate the Java EE to Jakarta EE
> migration functionality into Tomcat 10.
>
> There are essentially two ways to do this: deployment time and runtime.
>
> The simplest solution to implement is probably a separate webapps-legacy
> directory (or some other name) where WARs and DIRs added to that
> directory get converted to Jakarta EE with the new version being placed
> in the webapps directory. There are complexities (such as handling an
> updates of the legacy WAR) but they should be manageable.
>
> A more complex version of the deploy time solution has the legacy web
> application placed in webapps, identified as a legacy webapp and then
> replaced with the new version (several ways to do this). The hard part
> here is the identification of the webapp as a Java EE app. The only
> reliable way to do this is class scanning and that is slow.
>
> The runtime approach converts classes and static resources as they are
> loaded. The classes are relatively easy to handle. A
> ClassFileTransformer can be added to the WebappClassLoader to do this.
> The static files are more of a problem. The good news is that the
> WebResources refactoring means static file access all goes through the
> same code but the filtering required essentially means we'd need to load
> static files into memory - regardless of size, convert them, and then
> update the cache with the converted version. That is likely to have a
> performance impact.
>
> Because of the performance impacts of handling static resources, the
> runtime approach also needs a way to identify applications that need
> conversion. I don't see a reliable, performant way to do that. Which, I
> think, leaves us with the simple deployment time approach and something
> (filename, special directory, something else) to mark an app as needing
> conversion.
>
> A final point, which probably should have been first, is is there a
> demand for this feature? Early indications from the users list and $work
> is that there is (going to be) a demand for this feature.
>
> Thoughts?
>

We should also think about Tomcat Embedded! Many of the modern web
frameworks use embedded Tomcat/Jetty/Undertow.
I guess it should be even easier for them to set a property saying "I need
this app to be migrated" or to put it in the special folder
(webapps-legacy/).
We just need to make sure tomcat-embed is taken into account for the
eventual solution!

Martin


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

Re: JDK 16 is now in the Release Candidate Phase

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 16 b35 & 17 b8
on Ubuntu 20.04 x86_64 and aarch64!

Regards,
Martin

On Fri, Feb 5, 2021 at 1:12 PM Rory O'Donnell 
wrote:

>
> *Hi Mark, *
>
> *Per the JDK 16 schedule , we are in the Release Candidate Phase**[1] .*
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.*
>
>   * Schedule for JDK 16
>   o *2021/02/04 Initial Release Candidate*
>   o 2021/02/18 Final Release Candidate
>   o 2021/03/16 General Availability
>   * Release Notes [2]
>
> OpenJDK 16 Early Access build 35**is now available at
> http://jdk.java.net/16 
>
>   * These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Features [3] - the overall feature set is frozen. No further JEPs
> will be targeted to this release.
>   * Changes in recent builds that maybe of interest:
>   o Build 34:
>   + JDK-8259025: Record compact constructor using
> Objects.requireNonNull
>   # Reported by JUnit5
>   o Build 32:
>   + JDK-8259014: Incomplete support for Unix domain sockets in
> Windows 2019 Server
>
>   * JDK 16 - topics of interest:
>   o Unix domain socket channels (JEP-380) overview:
>
> https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/
> <
> https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/>
>   o Java Feature Spotlight: Pattern Matching
> https://inside.java/2021/01/22/feature-spotlight-pattern-matching/
> <
> https://inside.java/2021/01/22/feature-spotlight-pattern-matching/>
>   o Foreign Memory Access - Pulling all the thread
>
> https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/
> <
> https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/>
>   * General – topic of interest:
>   o Inside Java Episode 11 “How to contribute to OpenJDK” with
> Stuart Marks and Jesper Wilhelmsson
> https://inside.java/2021/01/29/podcast-011/
> 
>
>
> Project Lanai EA 9 Build 17-lanai+2-49 (2021/1/20)
>  is available now
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> 
>   * EA builds are intended for developers looking to test and provide
> feedback on using Project Lanai.
>   * This is a macOS-specific project which implements a new Java 2D
> graphics rendering pipeline for macOS.
>   * Project Lanai Wiki: https://wiki.openjdk.java.net/display/lanai/Main
> 
>   * Please send feedback via e-mail to lanai-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> Project Loom Build 17-loom+2-42 (2021/1/14) 
> based on JDK-17+5
>  is available now
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> 
>   * These builds are intended for developers looking to "kick the tyres"
> and provide feedback on using the API or by sending bug reports.
>   * API Javadoc :
> https://download.java.net/java/early_access/loom/docs/api/
> 
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> OpenJDK 17 Early Access build 8**is now available at
> http://jdk.java.net/17 
>
>   * These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Changes in recent builds that maybe of interest:
>   o Build 8:
>   + JDK-8222850: Misleading cascade compiler error in switch
> expression with undefined vars
>   # Reported by jOOQ.
>   + JDK-8217633: Configurable extensions with system properties
>   + JDK-8249867: DOM LSSerializer control of newline after XML
> header
>   + JDK-8256421: Added 2 HARICA Root CA Certificates
>   + JDK-8259801: Enable XML Signature secure validation mode by
> default
>   o Build 7:
>   + JDK-8165276: Spec states to invoke the 

Re: JDK 16 is now in the Release Candidate Phase

[Martin Grigorov]

Hi Rémy,

On Mon, Feb 8, 2021 at 11:23 AM Rémy Maucherat  wrote:

> On Mon, Feb 8, 2021 at 10:10 AM Martin Grigorov 
> wrote:
>
> > Hi devs,
> >
> > TestXxxEndpoint fails concitently on both JDK 16 b35 and JDK 17 b8 with:
> >
> > Testsuite: org.apache.tomcat.util.net.TestXxxEndpoint
> > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.983 sec
> > - Standard Error -
> > 08-Feb-2021 08:38:08.129 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [testUnixDomainSocket]
> > 08-Feb-2021 08:38:08.867 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-1"]
> > 08-Feb-2021 08:38:08.926 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [testStartStopBindOnStart]
> > 08-Feb-2021 08:38:11.842 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2"]
> > 08-Feb-2021 08:38:11.976 INFO [main]
> > org.apache.catalina.core.StandardService.startInternal Starting service
> > [Tomcat]
> > 08-Feb-2021 08:38:11.979 INFO [main]
> > org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
> > engine: [Apache Tomcat/10.0.3-dev]
> > 08-Feb-2021 08:38:12.813 INFO [main]
> > org.apache.catalina.startup.ContextConfig.getDefaultWebXmlFragment No
> > global web.xml found
> > 08-Feb-2021 08:38:14.322 INFO [main]
> > org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
> scanned
> > for TLDs yet contained no TLDs. Enable debug logging for this logger for
> a
> > complete list of JAR
> > s that were scanned but no TLDs were found in them. Skipping unneeded
> JARs
> > during scanning can improve startup time and JSP compilation time.
> > 08-Feb-2021 08:38:14.462 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log ContextListener:
> > contextInitialized()
> > 08-Feb-2021 08:38:14.463 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log SessionListener:
> > contextInitialized()
> > 08-Feb-2021 08:38:14.483 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log ContextListener:
> > attributeAdded('StockTicker', 'async.Stockticker@3a12c404')
> > 08-Feb-2021 08:38:14.667 INFO [main]
> > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2"]
> > 08-Feb-2021 08:38:14.812 INFO [main]
> > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2-34601"]
> > 08-Feb-2021 08:38:14.824 INFO [main]
> > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2"]
> > 08-Feb-2021 08:38:14.966 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2"]
> > 08-Feb-2021 08:38:14.967 INFO [main]
> > org.apache.catalina.core.StandardService.stopInternal Stopping service
> > [Tomcat]
> > 08-Feb-2021 08:38:14.971 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log SessionListener:
> > contextDestroyed()
> > 08-Feb-2021 08:38:14.972 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log ContextListener:
> > contextDestroyed()
> > 08-Feb-2021 08:38:15.024 INFO [main]
> > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2"]
> > 08-Feb-2021 08:38:15.128 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-2"]
> > 08-Feb-2021 08:38:15.134 INFO [main]
> > org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
> > [testStartStopBindOnInit]
> > 08-Feb-2021 08:38:15.135 INFO [main]
> > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> > ["http-nio2-127.0.0.1-auto-3"]
> > 08-Feb-2021 08:38:15.240 INFO [main]
> > org.apache.catalina.core.StandardService.startInternal Starting service
> > [Tomcat]
> > 08-Feb-2021 08:38:15.240 INFO [main]
> > org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
> > engine: [Apache Tomcat/10.0.3-dev]
> > 08-Feb-2021 08:38:15.252 INFO [main]
> > org.apache.catalina.startup.ContextConfig.getDefaultWebXmlFragment No
> > global web.xml found
> > 08-Feb-2021 08:38:15.747 INFO [main]
> > org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was

Re: JDK 16 is now in the Release Candidate Phase

[Martin Grigorov]

Hi devs,

TestXxxEndpoint fails concitently on both JDK 16 b35 and JDK 17 b8 with:

Testsuite: org.apache.tomcat.util.net.TestXxxEndpoint
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.983 sec
- Standard Error -
08-Feb-2021 08:38:08.129 INFO [main]
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
[testUnixDomainSocket]
08-Feb-2021 08:38:08.867 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["http-nio2-127.0.0.1-auto-1"]
08-Feb-2021 08:38:08.926 INFO [main]
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
[testStartStopBindOnStart]
08-Feb-2021 08:38:11.842 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio2-127.0.0.1-auto-2"]
08-Feb-2021 08:38:11.976 INFO [main]
org.apache.catalina.core.StandardService.startInternal Starting service
[Tomcat]
08-Feb-2021 08:38:11.979 INFO [main]
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
engine: [Apache Tomcat/10.0.3-dev]
08-Feb-2021 08:38:12.813 INFO [main]
org.apache.catalina.startup.ContextConfig.getDefaultWebXmlFragment No
global web.xml found
08-Feb-2021 08:38:14.322 INFO [main]
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
for TLDs yet contained no TLDs. Enable debug logging for this logger for a
complete list of JAR
s that were scanned but no TLDs were found in them. Skipping unneeded JARs
during scanning can improve startup time and JSP compilation time.
08-Feb-2021 08:38:14.462 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
contextInitialized()
08-Feb-2021 08:38:14.463 INFO [main]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextInitialized()
08-Feb-2021 08:38:14.483 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
attributeAdded('StockTicker', 'async.Stockticker@3a12c404')
08-Feb-2021 08:38:14.667 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio2-127.0.0.1-auto-2"]
08-Feb-2021 08:38:14.812 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio2-127.0.0.1-auto-2-34601"]
08-Feb-2021 08:38:14.824 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio2-127.0.0.1-auto-2"]
08-Feb-2021 08:38:14.966 INFO [main]
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
["http-nio2-127.0.0.1-auto-2"]
08-Feb-2021 08:38:14.967 INFO [main]
org.apache.catalina.core.StandardService.stopInternal Stopping service
[Tomcat]
08-Feb-2021 08:38:14.971 INFO [main]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextDestroyed()
08-Feb-2021 08:38:14.972 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
contextDestroyed()
08-Feb-2021 08:38:15.024 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio2-127.0.0.1-auto-2"]
08-Feb-2021 08:38:15.128 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["http-nio2-127.0.0.1-auto-2"]
08-Feb-2021 08:38:15.134 INFO [main]
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case
[testStartStopBindOnInit]
08-Feb-2021 08:38:15.135 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio2-127.0.0.1-auto-3"]
08-Feb-2021 08:38:15.240 INFO [main]
org.apache.catalina.core.StandardService.startInternal Starting service
[Tomcat]
08-Feb-2021 08:38:15.240 INFO [main]
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
engine: [Apache Tomcat/10.0.3-dev]
08-Feb-2021 08:38:15.252 INFO [main]
org.apache.catalina.startup.ContextConfig.getDefaultWebXmlFragment No
global web.xml found
08-Feb-2021 08:38:15.747 INFO [main]
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
for TLDs yet contained no TLDs. Enable debug logging for this logger for a
complete list of JAR
s that were scanned but no TLDs were found in them. Skipping unneeded JARs
during scanning can improve startup time and JSP compilation time.
08-Feb-2021 08:38:15.767 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
contextInitialized()
08-Feb-2021 08:38:15.768 INFO [main]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextInitialized()
08-Feb-2021 08:38:15.769 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
attributeAdded('StockTicker', 'async.Stockticker@2f48b3d2')
08-Feb-2021 08:38:15.774 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio2-127.0.0.1-auto-3-39117"]
08-Feb-2021 08:38:15.817 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio2-127.0.0.1-auto-3-39117"]
08-Feb-2021 08:38:15.838 INFO [main]
org.apache.tomcat.util.net.TestXxxEndpoint.testStartStopBindOnInit
Exception was
java.net.BindException: Address already in use
   at 

Re: [tomcat] branch master updated: Remove ugly reflection using a generic id

[Martin Grigorov]

On Mon, Feb 1, 2021 at 4:06 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 48c9b87  Remove ugly reflection using a generic id
> 48c9b87 is described below
>
> commit 48c9b873ab0eef18d5a4d76cf80033ee2afca7eb
> Author: remm 
> AuthorDate: Mon Feb 1 15:04:32 2021 +0100
>
> Remove ugly reflection using a generic id
>
> The id if available then replaces address-port to name threads and
> mbeans.
> ---
>  java/org/apache/catalina/connector/Connector.java | 14 +++---
>  java/org/apache/coyote/AbstractProtocol.java  | 12 +---
>  java/org/apache/coyote/ProtocolHandler.java   | 11 +++
>  java/org/apache/tomcat/util/net/AbstractEndpoint.java | 11 +++
>  java/org/apache/tomcat/util/net/AprEndpoint.java  | 10 ++
>  java/org/apache/tomcat/util/net/NioEndpoint.java  | 12 
>  6 files changed, 60 insertions(+), 10 deletions(-)
>
> diff --git a/java/org/apache/catalina/connector/Connector.java
> b/java/org/apache/catalina/connector/Connector.java
> index 4f4be1c..8eb235d 100644
> --- a/java/org/apache/catalina/connector/Connector.java
> +++ b/java/org/apache/catalina/connector/Connector.java
> @@ -950,11 +950,11 @@ public class Connector extends LifecycleMBeanBase  {
>
>  StringBuilder sb = new StringBuilder("type=");
>  sb.append(type);
> -Object path = getProperty("unixDomainSocketPath");
> -if (path != null) {
> +String id = protocolHandler.getId();
> +if (id != null) {
>  // Maintain MBean name compatibility, even if not accurate
>  sb.append(",port=0,address=");
> -sb.append(ObjectName.quote(path.toString()));
> +sb.append(ObjectName.quote(id));
>  } else {
>  sb.append(",port=");
>  int port = getPortWithOffset();
> @@ -1066,7 +1066,7 @@ public class Connector extends LifecycleMBeanBase  {
>  protected void startInternal() throws LifecycleException {
>
>  // Validate settings before starting
> -if (getProperty("unixDomainSocketPath") == null &&
> getPortWithOffset() < 0) {
> +if (protocolHandler.getId() == null && getPortWithOffset() < 0) {
>  throw new LifecycleException(sm.getString(
>  "coyoteConnector.invalidPort",
> Integer.valueOf(getPortWithOffset(;
>  }
> @@ -1132,9 +1132,9 @@ public class Connector extends LifecycleMBeanBase  {
>  StringBuilder sb = new StringBuilder("Connector[");
>  sb.append(getProtocol());
>  sb.append('-');
> -Object path = getProperty("unixDomainSocketPath");
> -if (path != null) {
> -sb.append(path.toString());
> +Object id = protocolHandler.getId();
>

Why Object + toString() ? It is a String


> +if (id != null) {
> +sb.append(id.toString());
>  } else {
>  int port = getPortWithOffset();
>  if (port > 0) {
> diff --git a/java/org/apache/coyote/AbstractProtocol.java
> b/java/org/apache/coyote/AbstractProtocol.java
> index 09b60dd..7b8756d 100644
> --- a/java/org/apache/coyote/AbstractProtocol.java
> +++ b/java/org/apache/coyote/AbstractProtocol.java
> @@ -207,6 +207,12 @@ public abstract class AbstractProtocol implements
> ProtocolHandler,
>  }
>
>
> +@Override
> +public String getId() {
> +return endpoint.getId();
> +}
> +
> +
>  // -- Properties that are passed through to the
> EndPoint
>
>  @Override
> @@ -347,9 +353,9 @@ public abstract class AbstractProtocol implements
> ProtocolHandler,
>  private String getNameInternal() {
>  StringBuilder name = new StringBuilder(getNamePrefix());
>  name.append('-');
> -String path = getProperty("unixDomainSocketPath");
> -if (path != null) {
> -name.append(path);
> +String id = getId();
> +if (id != null) {
> +name.append(id);
>  } else {
>  if (getAddress() != null) {
>  name.append(getAddress().getHostAddress());
> diff --git a/java/org/apache/coyote/ProtocolHandler.java
> b/java/org/apache/coyote/ProtocolHandler.java
> index dfa5a25..cf25010 100644
> --- a/java/org/apache/coyote/ProtocolHandler.java
> +++ b/java/org/apache/coyote/ProtocolHandler.java
> @@ -207,6 +207,17 @@ public interface ProtocolHandler {
>
>
>  /**
> + * The default behavior is to identify connectors uniquely with
> address
> + * and port. However, certain connectors are not using that and need
> + * some other identifier, which then can be used as a replacement.
> + * @return the id
> + */
> +public default String getId() {
> +return null;
> +}
> 

Re: [VOTE] Release Apache Tomcat 8.5.63

[Martin Grigorov]

On Fri, Jan 29, 2021 at 1:43 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.63 release is now available for voting.
>
> The notable changes compared to the 8.5.61 release are:
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> - Escape elements in the access log that need to be escaped for the
>   access log to be parsed unambiguously.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.63/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1298/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.63
> eb8d36c30857866536e8c931731c9f86980b00a6
>
> The proposed 8.5.63 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.63
>

Regards,
Martin


>
> -
> 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

[Martin Grigorov]

On Thu, Jan 28, 2021 at 10:48 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.43 release is now available for voting.
>
> The notable changes compared to the 9.0.41 release are:
>
> - Add support for using Unix domain sockets for NIO when running on
>   Java 16 or later.
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.43/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1297/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.43
> dc8bcd9c0704235319d322ca3d4c32263a054766
>
> The proposed 9.0.43 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.43
>

Regards,
Martin


>
> -
> 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.2

[Martin Grigorov]

On Thu, Jan 28, 2021 at 9:13 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.2 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.0 are:
>
> - Add support for using Unix domain sockets for NIO when running on
>   Java 16 or later.
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.2/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1296
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.2
> 228209117457e9b30d96f235c45efac9d4b8d9cb
>
> The proposed 10.0.2 release is:
> [ ] Broken - do not release
> [ ] Beta   - go ahead and release as 10.0.2 (beta)
> [ X ] Stable - go ahead and release as 10.0.2 (stable)
>
>
Regards,
Martin


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

Re: [VOTE] Release Apache Tomcat 7.0.108

[Martin Grigorov]

On Thu, Jan 28, 2021 at 11:49 AM Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.108 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.108/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1295/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.108
> b57a2ea4466a2d4ea03a0f90e3f0d6c485b3cfea
>
> The proposed 7.0.108 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 7.0.108 Stable
>

Regards,
Martin


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 8.5.62

[Martin Grigorov]

On Wed, Jan 27, 2021 at 9:25 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.62 release is now available for voting.
>
> The notable changes compared to the 8.5.61 release are:
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> - Escape elements in the access log that need to be escaped for the
>   access log to be parsed unambiguously.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.62/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1294/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.62
> 0c41d44e32bc4479f0de02e6eb29bb703549a05c
>
> The proposed 8.5.62 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.62
>

Regards,
Martin


>
> -
> 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.42

[Martin Grigorov]

On Wed, Jan 27, 2021 at 7:40 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.42 release is now available for voting.
>
> The notable changes compared to the 9.0.41 release are:
>
> - Add support for using Unix domain sockets for NIO when running on
>   Java 16 or later.
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.42/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1293/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.42
> 868b50e7af1dd6c3489ba0fda86dfc1ff1b8c8cb
>
> The proposed 9.0.42 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.42
>

Regards,
Martin


>
> -
> 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.1

[Martin Grigorov]

On Wed, Jan 27, 2021 at 5:08 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.1 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.1 are:
>
> - Add support for using Unix domain sockets for NIO when running on
>   Java 16 or later.
>
> - Add a new StringInterpreter interface that allows applications to
>   provide customised string attribute value to type conversion within
>   JSPs. This allows applications to provide a conversion
>   implementation that is optimised for the application.
>
> - Add peerAddress to coyote request, which contains the IP address of
>   the direct connection peer. If a reverse proxy sits in front of
>   Tomcat and the protocol used is AJP or HTTP in combination with the
>   RemoteIp(Valve|Filter), the peer address might differ from the
>   remoteAddress. The latter then contains the address of the client in
>   front of the reverse proxy, not the address of the proxy itself.
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.1/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1292/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.1
> e4344b6bd67359e1690312674d83710a793f1d5b
>
> The proposed 10.0.1 release is:
> [ ] Broken - do not release
> [ ] Beta   - go ahead and release as 10.0.1 (beta)
> [ X ] Stable - go ahead and release as 10.0.1 (stable)
>

Tested with a fresh build of tomcat-jakarta-migration tool master branch
and Apache Wicket 9.x examples.

Regards,
Martin


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

Re: [tomcat] branch master updated: Add UDS test case

[Martin Grigorov]

On Mon, Jan 18, 2021 at 1:07 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 16e3ef4  Add UDS test case
>  new bda7cbb  Merge branch 'master' of g...@github.com:
> apache/tomcat.git
> 16e3ef4 is described below
>
> commit 16e3ef43f2fd3aa4ac9dcf14a8e985ef0754022c
> Author: remm 
> AuthorDate: Mon Jan 18 12:06:22 2021 +0100
>
> Add UDS test case
>
> And a Java 16 compat flag.
> ---
>  java/org/apache/tomcat/util/compat/JreCompat.java  |  9 +++
>  .../apache/tomcat/util/net/TestXxxEndpoint.java| 29
> ++
>  2 files changed, 38 insertions(+)
>
> diff --git a/java/org/apache/tomcat/util/compat/JreCompat.java
> b/java/org/apache/tomcat/util/compat/JreCompat.java
> index b8b3b48..d58c1a0 100644
> --- a/java/org/apache/tomcat/util/compat/JreCompat.java
> +++ b/java/org/apache/tomcat/util/compat/JreCompat.java
> @@ -45,6 +45,7 @@ public class JreCompat {
>
>  private static final JreCompat instance;
>  private static final boolean graalAvailable;
> +private static final boolean jre16Available;
>  private static final boolean jre11Available;
>  private static final boolean jre9Available;
>  private static final StringManager sm =
> StringManager.getManager(JreCompat.class);
> @@ -69,12 +70,15 @@ public class JreCompat {
>  if (Jre16Compat.isSupported()) {
>  instance = new Jre16Compat();
>  jre9Available = true;
> +jre16Available = true;
>  } else if (Jre9Compat.isSupported()) {
>  instance = new Jre9Compat();
>  jre9Available = true;
> +jre16Available = false;
>  } else {
>  instance = new JreCompat();
>  jre9Available = false;
> +jre16Available = false;
>  }
>  jre11Available = instance.jarFileRuntimeMajorVersion() >= 11;
>
> @@ -116,6 +120,11 @@ public class JreCompat {
>  }
>
>
> +public static boolean isJre16Available() {
> +return jre16Available;
> +}
> +
> +
>  // Java 8 implementation of Java 9 methods
>
>  /**
> diff --git a/test/org/apache/tomcat/util/net/TestXxxEndpoint.java
> b/test/org/apache/tomcat/util/net/TestXxxEndpoint.java
> index 2db184f..12a4015 100644
> --- a/test/org/apache/tomcat/util/net/TestXxxEndpoint.java
> +++ b/test/org/apache/tomcat/util/net/TestXxxEndpoint.java
> @@ -19,8 +19,12 @@ package org.apache.tomcat.util.net;
>  import java.io.File;
>  import java.net.InetAddress;
>  import java.net.ServerSocket;
> +import java.net.SocketAddress;
> +import java.nio.ByteBuffer;
> +import java.nio.channels.SocketChannel;
>
>  import org.junit.Assert;
> +import org.junit.Assume;
>  import org.junit.Test;
>
>  import org.apache.catalina.connector.Connector;
> @@ -29,6 +33,7 @@ import org.apache.catalina.startup.TomcatBaseTest;
>  import org.apache.tomcat.jni.Error;
>  import org.apache.tomcat.jni.Library;
>  import org.apache.tomcat.jni.Pool;
> +import org.apache.tomcat.util.compat.JreCompat;
>
>  /**
>   * Test case for the Endpoint implementations. The testing framework will
> ensure
> @@ -206,4 +211,28 @@ public class TestXxxEndpoint extends TomcatBaseTest {
>  Assert.assertNull(e);
>  tomcat.getConnector().start();
>  }
> +
> +@Test
> +public void testUnixDomainSocket() throws Exception {
> +
>

maybe move Assume.assumeTrue("JDK 16 is
required", JreCompat.isJre16Available()); here ? Before starting Tomcat
instance


> +Tomcat tomcat = getTomcatInstance();
> +Connector c = tomcat.getConnector();
> +Assume.assumeTrue("SSL renegotiation has to be supported for this
> test",
>

Is this copy/paste error ?
The SSL renegotiation message seems unrelated.


> +c.getProtocolHandlerClassName().contains("Nio")
> +&& JreCompat.isJre16Available());
> +
> +final String unixDomainSocketPath = "/tmp/testUnixDomainSocket";
> +Assert.assertTrue(c.setProperty("unixDomainSocketPath",
> unixDomainSocketPath));
> +tomcat.start();
> +
> +SocketAddress sa =
> JreCompat.getInstance().getUnixDomainSocketAddress(unixDomainSocketPath);
> +ByteBuffer response = ByteBuffer.allocate(1024);
> +try (SocketChannel socket =
> JreCompat.getInstance().openUnixDomainSocketChannel()) {
> +socket.connect(sa);
> +socket.write(ByteBuffer.wrap("OPTIONS *
> HTTP/1.0\r\n\r\n".getBytes()));
>

Is HTTP/1.0 intentional ? Because the assertion below checks for 1.1


> +socket.read(response);
> +}
> +
> +Assert.assertTrue((new String(response.array(), 0,
> response.position()).startsWith("HTTP/1.1 200")));
> +}
>  }
>
>
> -
> To 

Re: [tomcat] branch master updated: Happy New Year 2021

[Martin Grigorov]

On Tue, Jan 19, 2021 at 7:55 PM Mark Thomas  wrote:

> On 19/01/2021 17:26, Christopher Schultz wrote:
> > Mark,
> >
> > It seems like this could be easier if we defined a string constant or
> > two somewhere and referenced it from everywhere.
>
> Another of life's constants appears to be that there is an XKCD for
> every situation:
>
> https://xkcd.com/1205/
>
> Given how easy the IDE makes find and replace, I'm happy with the manual
> approach at the moment. But I won't complain if someone wants to make it
> easier.
>
> > For the JSP files, perhaps the Manager web application could stuff the
> > copyright notice into the servlet (application) context on startup and
> > the JSP could pull the values out and into the  elements.
>
> Apart from the NOTICE files (which I think would have to stay manual)
> the rest are in strings so I think source code filtering might be
> another option.
>

Or just use LocalDate.now().getYear() ?


>
> Mark
>
> >
> > -chris
> >
> > On 1/17/21 12:51, ma...@apache.org wrote:
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> markt pushed a commit to branch master
> >> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/master by this push:
> >>   new c58fe9a  Happy New Year 2021
> >> c58fe9a is described below
> >>
> >> commit c58fe9a378bb23ad202f91780b4cd936e6e8a3c5
> >> Author: Mark Thomas 
> >> AuthorDate: Sun Jan 17 17:49:51 2021 +
> >>
> >>  Happy New Year 2021
> >> ---
> >>   NOTICE   | 2 +-
> >>   java/org/apache/catalina/manager/Constants.java  | 2 +-
> >>   java/org/apache/catalina/manager/HTMLManagerServlet.java | 2 +-
> >>   java/org/apache/catalina/manager/host/Constants.java | 2 +-
> >>   modules/jdbc-pool/NOTICE | 2 +-
> >>   webapps/manager/WEB-INF/jsp/connectorCerts.jsp   | 2 +-
> >>   webapps/manager/WEB-INF/jsp/connectorCiphers.jsp | 2 +-
> >>   webapps/manager/WEB-INF/jsp/connectorTrustedCerts.jsp| 2 +-
> >>   webapps/manager/WEB-INF/jsp/sessionDetail.jsp| 2 +-
> >>   webapps/manager/WEB-INF/jsp/sessionsList.jsp | 2 +-
> >>   10 files changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/NOTICE b/NOTICE
> >> index 7480ff4..43bc6be 100644
> >> --- a/NOTICE
> >> +++ b/NOTICE
> >> @@ -1,5 +1,5 @@
> >>   Apache Tomcat
> >> -Copyright 1999-2020 The Apache Software Foundation
> >> +Copyright 1999-2021 The Apache Software Foundation
> >> This product includes software developed at
> >>   The Apache Software Foundation (https://www.apache.org/).
> >> diff --git a/java/org/apache/catalina/manager/Constants.java
> >> b/java/org/apache/catalina/manager/Constants.java
> >> index c17eafc..c92998b 100644
> >> --- a/java/org/apache/catalina/manager/Constants.java
> >> +++ b/java/org/apache/catalina/manager/Constants.java
> >> @@ -131,7 +131,7 @@ public class Constants {
> >>   HTML_TAIL_SECTION =
> >>   "\n" +
> >>   "\n" +
> >> -" Copyright  1999-2020, Apache Software
> >> Foundation" +
> >> +" Copyright  1999-2021, Apache Software
> >> Foundation" +
> >>   "\n" +
> >>   "\n" +
> >>   "\n" +
> >> diff --git a/java/org/apache/catalina/manager/HTMLManagerServlet.java
> >> b/java/org/apache/catalina/manager/HTMLManagerServlet.java
> >> index c2e5179..749ab83 100644
> >> --- a/java/org/apache/catalina/manager/HTMLManagerServlet.java
> >> +++ b/java/org/apache/catalina/manager/HTMLManagerServlet.java
> >> @@ -798,7 +798,7 @@ public final class HTMLManagerServlet extends
> >> ManagerServlet {
> >>*/
> >>   @Override
> >>   public String getServletInfo() {
> >> -return "HTMLManagerServlet, Copyright (c) 1999-2020, The
> >> Apache Software Foundation";
> >> +return "HTMLManagerServlet, Copyright (c) 1999-2021, The
> >> Apache Software Foundation";
> >>   }
> >> /**
> >> diff --git a/java/org/apache/catalina/manager/host/Constants.java
> >> b/java/org/apache/catalina/manager/host/Constants.java
> >> index eccdead..3d768c1 100644
> >> --- a/java/org/apache/catalina/manager/host/Constants.java
> >> +++ b/java/org/apache/catalina/manager/host/Constants.java
> >> @@ -81,7 +81,7 @@ public class Constants {
> >>   public static final String HTML_TAIL_SECTION =
> >>   "\n" +
> >>   "\n" +
> >> -" Copyright  1999-2020, Apache Software
> >> Foundation" +
> >> +" Copyright  1999-2021, Apache Software
> >> Foundation" +
> >>   "\n" +
> >>   "\n" +
> >>   "\n" +
> >> diff --git a/modules/jdbc-pool/NOTICE b/modules/jdbc-pool/NOTICE
> >> index 0767528..ad8a327 100644
> >> --- a/modules/jdbc-pool/NOTICE
> >> +++ b/modules/jdbc-pool/NOTICE
> >> @@ -1,5 +1,5 @@
> >>   Apache Tomcat JDBC Pool
> >> -Copyright 2008-2020 The Apache Software 

Re: JDK 16 is now in Rampdown Phase Two

[Martin Grigorov]

Hi Rory,

Same for JDK 17 b5 (Linux x86_64 & aarch64)!.

Regards,
Martin

On Mon, Jan 18, 2021 at 12:08 PM Rory O'Donnell 
wrote:

> Thanks for the feedback Mark!
>
> On 18/01/2021 09:47, Mark Thomas wrote:
> > Tomcat 10.0.x (latest development) builds and all tests pass with JDK 16
> > EA build 32.
> >
> > Mark
> >
> >
> > On 15/01/2021 09:36, Rory O'Donnell wrote:
> >> Hi Mark,
> >>
> >> *Per the JDK 16 schedule , we are in Rampdown Phase Two* *[1] .
> >> *
> >>
> >> *Please advise if you find any issues while testing the latest Early
> >> Access builds.*
> >>
> >>   * Schedule for JDK 16
> >>   o *2021/01/14  Rampdown Phase Two*
> >>   o 2021/02/04  Initial Release Candidate
> >>   o 2021/02/18  Final Release Candidate
> >>   o 2021/03/16  General Availability
> >>   * Release Notes [2]
> >>
> >> OpenJDK 16 Early Access build 32**is now available at
> >>
> https://urldefense.com/v3/__http://jdk.java.net/16__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHAgdnC6Hs$
> >>
> >>   * These early-access, open-source builds are provided under the GNU
> >> General Public License, version 2, with the Classpath Exception
> >> .
> >>   * Features [3] - the overall feature set is frozen. No further JEPs
> >> will be targeted to this release.
> >>   * Changes in recent builds that maybe of interest:
> >>   o Build 32:
> >>   + JDK-8259028 - ClassCastException when using custom
> >> filesystem with wrapper FileChannel impl
> >>   # Apache Lucene found.
> >>   + JDK-8253996 - Javac error on jdk16 build 18: invalid flag:
> >> -Xdoclint:-missing
> >>   # Apache Zookeeper found.
> >>   o Build 31:
> >>   + JDK-8259027: NullPointerException in makeMappedSegment due
> >> to NULL Unmapper when length of segment is 0
> >>   # Reported by Apache Lucene
> >>   o Build 30:
> >>   + JDK-8254023: A module declaration is not allowed to be a
> >> target of an annotation that lacks an @Target
> meta-annotation
> >>   # Reported by JUnit5
> >>   + JDK-8256693: getAnnotatedReceiverType parameterizes types
> >> too eagerly
> >>
> >>   * JDK 16 - topics of interest
> >>   o Investigating MD5 overheads:
> >>
> https://urldefense.com/v3/__https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHAZMwXA3I$
> >>   o Towards OpenJDK 17 - a quick update on startup performance
> >>
> https://urldefense.com/v3/__https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHARyBC8ag$
> >>   o Migrating OpenJDK to Git & GitHub - GitHub Universe 2020 session
> >> replay
> >>
> https://urldefense.com/v3/__https://inside.java/2020/12/11/skara-github-universe/__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHABw8U3nc$
> >>
> >> Project Panama/foreign EA Build 16-panama+3-385 (2020/12/10)
> >> <
> https://urldefense.com/v3/__https://jdk.java.net/panama/__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHApBH3NSA$
> > is available now [4]
> >>
> >>   * What's new
> >>   o jextract is now fully compatible with Java 16
> >>   o New architecture based on Foreign-Memory Access API (JEP 370
> >> , JEP 383
> >> , JEP 393
> >> ) and Foreign Linker API
> (JEP
> >> 389 )
> >>
> >>   * These early-access builds are provided under the GNU General Public
> >> License, version 2, with the Classpath Exception
> >> 
> >>   * EA builds are produced for the purpose of gathering feedback. Use
> >> for any other purpose is at your own risk.
> >>   * Please send feedback via e-mail to panama-...@openjdk.java.net
> >> . To send e-mail to this address you
> >> must first subscribe to the mailing list
> >> .
> >>
> >>   * Project Panama - topics of interest
> >>   o “The Vector API” with John Rose and Paul Sandoz
> >>
> https://urldefense.com/v3/__https://inside.java/2020/11/17/podcast-007/__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHA9L2EXQ4$
> >>   o “The Foreign Memory Access API” with Maurizio Cimadamore and
> >> Jorn Vernee
> >>
> https://urldefense.com/v3/__https://inside.java/2020/12/11/podcast-009/__;!!GqivPVa7Brio!Nv1DW1Db-7-N0XcwVgvF2fjmrY_bOqBMV7aGnIRV1EwhV0FODpsxIxBUQVHAnvz2-Oc$
> >>   o “The Foreign Linker API” with Maurizio Cimadamore and Jorn
> Vernee
> >>
> 

Re: Compat versions

[Martin Grigorov]

On Fri, Dec 18, 2020 at 11:12 AM Rémy Maucherat  wrote:

> Hi,
>
> I'd like to refactor the compat classes to align with the LTS versions:
> - Move Jre9Compat to Jre11Compat
> - I'll probably refactor out GraalCompat
> - For the upcoming Java 12+ features, they will all go to a new Jre17Compat
>

s/Java 12+/Java 17+/, right ?


> class, which will actually be useable in the meantime by the latest Java
> milestone release from which the interesting features come from
>
> Although not fully accurate, this is more maintainable as the interim non
> LTS Java releases quickly come and go and are not good platforms for
> Tomcat.
>

+1



>
> Rémy
>