Re: JDK 16 is in Rampdown Phase One

[Martin Grigorov]

Hi Rory,

We added some --add-opens to Tomcat and now the build and tests pass with
JDK 16 b28 on both x86_64 and aarch64, Ubuntu 20.04!

https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486
https://github.com/apache/tomcat/commit/61f4baf64c69c5fd738d34b6139eda4549258cea
https://github.com/apache/tomcat/commit/0a2ee9b1ba7ded327c2aa2361cccff6a16cdef84

On Mon, Dec 14, 2020 at 9:52 AM Martin Grigorov 
wrote:

> Hi Tomcat team,
>
> The following tests fail on JDK 16 b28:
>
> [concat] Testsuites with failed tests:
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.APR.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.APR.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO.txt
>[concat]
> TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO2.txt
>
>
> with this reason:
>
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field final java.util.concurrent.ThreadPoolExecutor
> java.util.concurrent.ThreadPoolExecutor$Worker.this$0 accessible: module
> java.base does not "opens java.util.concurrent" to unnamed module @80503
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads(WebappClassLoaderBase.java:1798)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1622)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1554)
> at
> org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:461)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
>
> Regards,
> Martin
>
> On Sun, Dec 13, 2020 at 7:08 PM Rory O'Donnell 
> wrote:
>
>> Hi Mark,
>>
>> *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] .
>> *
>>
>> *Please advise if you find any issues while testing the latest Early
>> Access builds.*
>>
>>   * Schedule for JDK 16
>>   o *2020/12/10 Rampdown Phase One*
>>   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 28**is now available at
>> http://jdk.java.net/16
>>
>>   * Features - the overall feature set is frozen. No further JEPs will
>> be targeted to this release.
>>   * Significant Integrations in b28:
>>   o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by
>> Default <https://openjdk.java.net/jeps/396>**
>> *
>>   + Strongly encapsulate all internal elements of the JDK by
>> default, except for critical internal APIs
>> <https://openjdk.java.net/jeps/260#Description> such as
>> |sun.misc.Unsafe|.
>>   + Allow end users to choose the relaxed strong encapsulation
>> that has been the default since JDK 9.
>>   o Integrated JEP 397: Sealed Classes (Second Preview)
>> <https://openjdk.java.net/jeps/397> with this release.
>>   + Enhance the Java programming language with sealed classes
>> and interfaces
>> <https://cr.openjdk.java.net/~briangoetz/amber/datum.html>.
>>   + Refines JEP 360 <https://openjdk.java.net/jeps/360> which
>> was delivered in JDK 15 as a preview feature.
>>
>>   * These early-access , open-source builds are provided under the GNU
>> General Public License, version 2, with the Classpath Exception
>> <http://openjdk.java.net/legal/gplv2+ce.html>.
>>   * Changes in recent builds that maybe of interest:
>>   o Build 28
>>   + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by
>> Default
>>   + JDK-8166596: TLS support for the EdDSA signature algorithm
>>   + JDK-8256718: Old traci

Re: [tomcat] branch master updated: Add opens for Java 16

[Martin Grigorov]

On Tue, Dec 15, 2020 at 3:35 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 61f4baf  Add opens for Java 16
> 61f4baf is described below
>
> commit 61f4baf64c69c5fd738d34b6139eda4549258cea
> Author: remm 
> AuthorDate: Tue Dec 15 14:30:51 2020 +0100
>
> Add opens for Java 16
> ---
>  build.xml | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/build.xml b/build.xml
> index f937fc3..913dd0c 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -226,6 +226,10 @@
>   property="java9.test.option.4"
>   value="--add-opens=java.base/java.util=ALL-UNNAMED"/>
>
> +   + property="java9.test.option.5"
> +
>  value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
> +  
>
>
>
> @@ -1947,6 +1951,7 @@
>  
>  
>  
> +
>

What about catalina.(sh|bat) ? As in
https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486
I guess the opens for j.u.concurrent will be needed at runtime too.


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

Re: JDK 16 is in Rampdown Phase One

[Martin Grigorov]

Hi Rémy,

On Mon, Dec 14, 2020 at 10:51 PM Mark Thomas  wrote:

> On 14/12/2020 11:06, Martin Grigorov wrote:
> > On Mon, Dec 14, 2020 at 12:30 PM Rémy Maucherat  wrote:
> >
> >> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov 
> >> wrote:
> >>
> >>> Hi Tomcat team,
> >>>
> >>> The following tests fail on JDK 16 b28:
> >>>
> >>
> >> Ok, so I installed JDK 16 and tested. No issues overall, nice !
> >>
> >> About this particular one however, the proper exceptions are now caught
> and
> >> everything (so it's "ok") but it's not possible to make the
> functionality
> >> work anymore by default. So the executor and its threads are still
> hanging,
> >> causing the assertions to fail [as well as the traces when stopping the
> >> blocked threads]. Should we relax module security somehow to allow the
> >> fields setAccessible(true) to work again ? [that doesn't sound like a
> great
> >> plan to me ...]
> >>
> >
> > One can work it around by adding --add-opens=java.base/java.
> > <http://java.io/>util.concurrent=ALL-UNNAMED to the JVM arguments
> > I am not sure whether some module-info.java hackery can make it better.
>
> This is what we currently do:
>
> https://github.com/apache/tomcat/blob/master/bin/catalina.sh#L313
>
> (and the same for .bat). Looks like we need to add another entry there.
>

Your fix
<https://github.com/apache/tomcat/commit/f42f1899eda28244218bf4d29602bc99574d4486>
does not solve the issue for me. Do the tests pass for you with JDK 16 b28 ?

diff --git build.xml build.xml
index 2c2b532..2c1a54f 100644
--- build.xml
+++ build.xml
@@ -220,7 +220,7 @@
   
   
+
value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
   

^^ this fixes them!


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

Re: JDK 16 is in Rampdown Phase One

[Martin Grigorov]

On Mon, Dec 14, 2020 at 12:30 PM Rémy Maucherat  wrote:

> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov 
> wrote:
>
> > Hi Tomcat team,
> >
> > The following tests fail on JDK 16 b28:
> >
>
> Ok, so I installed JDK 16 and tested. No issues overall, nice !
>
> About this particular one however, the proper exceptions are now caught and
> everything (so it's "ok") but it's not possible to make the functionality
> work anymore by default. So the executor and its threads are still hanging,
> causing the assertions to fail [as well as the traces when stopping the
> blocked threads]. Should we relax module security somehow to allow the
> fields setAccessible(true) to work again ? [that doesn't sound like a great
> plan to me ...]
>

One can work it around by adding --add-opens=java.base/java.
<http://java.io/>util.concurrent=ALL-UNNAMED to the JVM arguments
I am not sure whether some module-info.java hackery can make it better.



>
> Rémy
>
>
> >
> > [concat] Testsuites with failed tests:
> >[concat]
> >
> >
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.APR.txt
> >[concat]
> >
> >
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt
> >[concat]
> >
> >
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt
> >[concat]
> > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.APR.txt
> >[concat]
> > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO.txt
> >[concat]
> > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO2.txt
> >
> >
> > with this reason:
> >
> > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> > field final java.util.concurrent.ThreadPoolExecutor
> > java.util.concurrent.ThreadPoolExecutor$Worker.this$0 accessible: module
> > java.base does not "opens java.util.concurrent" to unnamed module @80503
> > at
> >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> > at
> >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> > at
> > java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
> > at
> java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
> > at
> >
> >
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads(WebappClassLoaderBase.java:1798)
> > at
> >
> >
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1622)
> > at
> >
> >
> org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1554)
> > at
> >
> org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:461)
> > at
> > org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> >
> > Regards,
> > Martin
> >
> > On Sun, Dec 13, 2020 at 7:08 PM Rory O'Donnell  >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] .
> > > *
> > >
> > > *Please advise if you find any issues while testing the latest Early
> > > Access builds.*
> > >
> > >   * Schedule for JDK 16
> > >   o *2020/12/10 Rampdown Phase One*
> > >   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 28**is now available at
> > > http://jdk.java.net/16
> > >
> > >   * Features - the overall feature set is frozen. No further JEPs will
> > > be targeted to this release.
> > >   * Significant Integrations in b28:
> > >   o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by
> > > Default <https://openjdk.java.net/jeps/396>**
> > > *
> > >   + Strongly encapsulate all internal elements of the JDK by
> > > default, except for critical internal APIs
> > > <https://openjdk.java.net/jeps/260#Description> such as
> > > |sun.misc.Unsafe|.
> > >   + Allow end users to choose the relaxed strong encapsulation
> > &g

Re: JDK 16 is in Rampdown Phase One

[Martin Grigorov]

On Mon, Dec 14, 2020 at 10:08 AM Rémy Maucherat  wrote:

> On Mon, Dec 14, 2020 at 8:53 AM Martin Grigorov 
> wrote:
>
> > Hi Tomcat team,
> >
> > The following tests fail on JDK 16 b28:
> >
> > [concat] Testsuites with failed tests:
> >[concat]
> >
> >
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.APR.txt
> >[concat]
> >
> >
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt
> >[concat]
> >
> >
> TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt
> >[concat]
> > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.APR.txt
> >[concat]
> > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO.txt
> >[concat]
> > TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO2.txt
> >
> >
> > with this reason:
> >
> > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> > field final java.util.concurrent.ThreadPoolExecutor
> > java.util.concurrent.ThreadPoolExecutor$Worker.this$0 accessible: module
> > java.base does not "opens java.util.concurrent" to unnamed module @80503
> > at
> >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> > at
> >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> > at
> > java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
> > at
> java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
> > at
> >
> >
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads(WebappClassLoaderBase.java:1798)
> > at
> >
> >
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1622)
> > at
> >
> >
> org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1554)
> > at
> >
> org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:461)
> > at
> > org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> >
>
> The changelog does say it's tightening up this sort of stuff, so I guess
> it's working just fine ! For now, I'll add the exception to the list of
> caught exceptions.
>

This fixed the old failure. Now it prints a WARNING with the same message
as before.

But the next problem is:

14-Dec-2020 08:41:48.999 INFO [main]
org.apache.catalina.core.StandardService.stopInternal Stopping service
[Tomcat]
Exception in thread "pool-1-thread-2" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
14-Dec-2020 08:41:49.000 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio-127.0.0.1-auto-1-37203"]
Exception in thread "pool-1-thread-4" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1006)
at
java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at
java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
Exception in thread "pool-1-thread-5" java.lang.IllegalMonitorStateException
at
java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175)
 

Re: JDK 16 is in Rampdown Phase One

[Martin Grigorov]

Hi Tomcat team,

The following tests fail on JDK 16 b28:

[concat] Testsuites with failed tests:
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.APR.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.NIO2.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.APR.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO.txt
   [concat]
TEST-org.apache.catalina.loader.TestWebappClassLoaderMemoryLeak.NIO2.txt


with this reason:

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
field final java.util.concurrent.ThreadPoolExecutor
java.util.concurrent.ThreadPoolExecutor$Worker.this$0 accessible: module
java.base does not "opens java.util.concurrent" to unnamed module @80503
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
at
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads(WebappClassLoaderBase.java:1798)
at
org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1622)
at
org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1554)
at
org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:461)
at
org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)

Regards,
Martin

On Sun, Dec 13, 2020 at 7:08 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] .
> *
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.*
>
>   * Schedule for JDK 16
>   o *2020/12/10 Rampdown Phase One*
>   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 28**is now available at
> http://jdk.java.net/16
>
>   * Features - the overall feature set is frozen. No further JEPs will
> be targeted to this release.
>   * Significant Integrations in b28:
>   o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by
> Default **
> *
>   + Strongly encapsulate all internal elements of the JDK by
> default, except for critical internal APIs
>  such as
> |sun.misc.Unsafe|.
>   + Allow end users to choose the relaxed strong encapsulation
> that has been the default since JDK 9.
>   o Integrated JEP 397: Sealed Classes (Second Preview)
>  with this release.
>   + Enhance the Java programming language with sealed classes
> and interfaces
> .
>   + Refines JEP 360  which
> was delivered in JDK 15 as a preview feature.
>
>   * 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 28
>   + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by
> Default
>   + JDK-8166596: TLS support for the EdDSA signature algorithm
>   + JDK-8256718: Old tracing flags are now obsolete and must be
> replaced with unified logging
>   o Build 27
>   + JDK-8159746: (proxy) Support for default methods
>   + JDK-8254631: Better support ALPN byte wire values in SunJSSE
>
> Project Loom Early-Access: *Build 16-loom+9-316
> * (2020/11/30) - based on JDK-16+25
> 
>
>   * 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.
>   * 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

Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory

[Martin Grigorov]

On Fri, Dec 11, 2020, 21:34 Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Rainer,
>
> On 12/11/20 14:19, Rainer Jung wrote:
> > Hi Chris,
> >
> > Am 11.12.2020 um 19:53 schrieb Christopher Schultz:
> >> Rainer,
> >>
> >> On 12/11/20 06:19, Rainer Jung wrote:
> >>> Am 11.12.2020 um 09:49 schrieb Martin Grigorov:
> >>>> On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov <
> mgrigo...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Hi Rainer,
> >>>>>
> >>>>> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung <
> rainer.j...@kippdata.de>
> >>>>> wrote:
> >>>>>
> >>>>>> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
> >>>>>>> This is an automated email from the ASF dual-hosted git repository.
> >>>>>>>
> >>>>>>> mgrigorov pushed a commit to branch master
> >>>>>>> in repository
> >>>>>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
> >>>>>>>
> >>>>>>>
> >>>>>>> The following commit(s) were added to refs/heads/master by this
> >>>>>>> push:
> >>>>>>>new 000c876  Make migrate.sh usable from any directory
> >>>>>>> 000c876 is described below
> >>>>>>>
> >>>>>>> commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
> >>>>>>> Author: Martin Tzvetanov Grigorov 
> >>>>>>> AuthorDate: Fri Dec 11 09:22:22 2020 +0200
> >>>>>>>
> >>>>>>>   Make migrate.sh usable from any directory
> >>>>>>>
> >>>>>>>   Until now one has to `cd` to the bin/ folder to be able to
> >>>>>>> execute
> >>>>>> migrate.sh, otherwise lib/ folder won't be found
> >>>>>>> ---
> >>>>>>>src/main/scripts/migrate.sh | 4 +++-
> >>>>>>>1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/src/main/scripts/migrate.sh
> >>>>>>> b/src/main/scripts/migrate.sh
> >>>>>>> index c2b941c..3d3f34c 100755
> >>>>>>> --- a/src/main/scripts/migrate.sh
> >>>>>>> +++ b/src/main/scripts/migrate.sh
> >>>>>>> @@ -1,4 +1,6 @@
> >>>>>>>#!/bin/sh
> >>>>>>>
> >>>>>>> +BIN_FOLDER=`dirname $PWD/$0`
> >>>>>>
> >>>>>> Does that work if $0 is an absolute path?
> >>>>>>
> >>>>>
> >>>>> Yes, it does. I have tested it!
> >>>>> BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it
> works
> >>>>> just fine on my Ubuntu.
> >>>>> Does it work on Solaris ? :-)
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Maybe one could
> >>>>>>
> >>>>>> cd `dirname $0`
> >>>>>>
> >>>>>
> >>>> Two issues with this:
> >>>>
> >>>> 1) the script usage is: ./bin/migrate.sh input.war output.war
> >>>> if we "cd" into bin/ then input.war is not there anymore. Its path
> >>>> should
> >>>> be fixed to ../input.war somehow
> >>>>
> >>>> 2) it would be good to leave the user back to the original directory
> >>>> after
> >>>> executing the script but pushd/popd are not available for 'sh'. We
> will
> >>>> need to use Bash or another
> >>>
> >>> Solaris check:
> >>>
> >>> apache% cat test.sh
> >>> #!/bin/sh
> >>>
> >>> echo `dirname $PWD/$0`
> >>>
> >>> apache% /home/jung/test.sh
> >>> /home/jung//home/jung
> >>>
> >>> apache% ./test.sh
> >>> /home/jung/.
> >>>
> >>> So the full path case does not work there. Switching to /bin/bash or
> >>> /bin/ksh does not help.
> >>>
> >>> I agree with Mark concerning the TC scripts.
> >>>
> >>> Concerning your 2) above: a "cd&

Re: [VOTE] Release Apache Tomcat Native 1.2.26

[Martin Grigorov]

On Thu, Dec 10, 2020 at 11:10 PM Mark Thomas  wrote:

> Version 1.2.26 includes the following changes compared to 1.2.25
>
> - Windows binaries built using 1.1.1i
>
> - BZ 64942 - expose support for unix domain sockets
>
> Various other fixes and improvements. See the changelog for details.
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.26 release is
>  [ X ] Stable, go ahead and release
>  [ ] Broken because of ...
>

UDS works well!

Martin


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

Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory

[Martin Grigorov]

On Fri, Dec 11, 2020 at 1:20 PM Rainer Jung  wrote:

> Am 11.12.2020 um 09:49 schrieb Martin Grigorov:
> > On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov 
> > wrote:
> >
> >> Hi Rainer,
> >>
> >> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung 
> >> wrote:
> >>
> >>> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
> >>>> This is an automated email from the ASF dual-hosted git repository.
> >>>>
> >>>> mgrigorov pushed a commit to branch master
> >>>> in repository
> >>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
> >>>>
> >>>>
> >>>> The following commit(s) were added to refs/heads/master by this push:
> >>>>new 000c876  Make migrate.sh usable from any directory
> >>>> 000c876 is described below
> >>>>
> >>>> commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
> >>>> Author: Martin Tzvetanov Grigorov 
> >>>> AuthorDate: Fri Dec 11 09:22:22 2020 +0200
> >>>>
> >>>>   Make migrate.sh usable from any directory
> >>>>
> >>>>   Until now one has to `cd` to the bin/ folder to be able to
> execute
> >>> migrate.sh, otherwise lib/ folder won't be found
> >>>> ---
> >>>>src/main/scripts/migrate.sh | 4 +++-
> >>>>1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh
> >>>> index c2b941c..3d3f34c 100755
> >>>> --- a/src/main/scripts/migrate.sh
> >>>> +++ b/src/main/scripts/migrate.sh
> >>>> @@ -1,4 +1,6 @@
> >>>>#!/bin/sh
> >>>>
> >>>> +BIN_FOLDER=`dirname $PWD/$0`
> >>>
> >>> Does that work if $0 is an absolute path?
> >>>
> >>
> >> Yes, it does. I have tested it!
> >> BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works
> >> just fine on my Ubuntu.
> >> Does it work on Solaris ? :-)
> >>
> >>
> >>>
> >>> Maybe one could
> >>>
> >>> cd `dirname $0`
> >>>
> >>
> > Two issues with this:
> >
> > 1) the script usage is: ./bin/migrate.sh input.war output.war
> > if we "cd" into bin/ then input.war is not there anymore. Its path should
> > be fixed to ../input.war somehow
> >
> > 2) it would be good to leave the user back to the original directory
> after
> > executing the script but pushd/popd are not available for 'sh'. We will
> > need to use Bash or another
>
> Solaris check:
>
> apache% cat test.sh
> #!/bin/sh
>
> echo `dirname $PWD/$0`
>
> apache% /home/jung/test.sh
> /home/jung//home/jung
>
> apache% ./test.sh
> /home/jung/.
>
> So the full path case does not work there. Switching to /bin/bash or
> /bin/ksh does not help.
>
> I agree with Mark concerning the TC scripts.
>
> Concerning your 2) above: a "cd" in the script does not change the
> working diretory of the calling shell. After the end of the script, the
> user is still in the same directory where he was before starting it.
>
> 1) is a bit more tricky, because again one would have to handle the
> absolute and the relative case.
>
> What might help and should be compatible would be something like
>
> mydir="$PWD"
> cd `dirname "$0"`
> BIN_FOLDER="$PWD"
> cd "$mydir"
>

This works perfect!
Thank you, Rainer!


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

Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory

[Martin Grigorov]

On Fri, Dec 11, 2020 at 10:53 AM Mark Thomas  wrote:

> On 11/12/2020 08:49, Martin Grigorov wrote:
> > On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov 
> > wrote:
> >> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung 
>
> 
>
> >>> Maybe one could
> >>>
> >>>cd `dirname $0`
> >>>
> >>
> > Two issues with this:
> >
> > 1) the script usage is: ./bin/migrate.sh input.war output.war
> > if we "cd" into bin/ then input.war is not there anymore. Its path should
> > be fixed to ../input.war somehow
> >
> > 2) it would be good to leave the user back to the original directory
> after
> > executing the script but pushd/popd are not available for 'sh'. We will
> > need to use Bash or another
>
> You might find inspiration for a fix in the Tomcat startup scripts.
>

Do we need to fix it ? It works fine.


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

Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory

[Martin Grigorov]

On Fri, Dec 11, 2020 at 10:41 AM Martin Grigorov 
wrote:

> Hi Rainer,
>
> On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung 
> wrote:
>
>> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
>> > This is an automated email from the ASF dual-hosted git repository.
>> >
>> > mgrigorov pushed a commit to branch master
>> > in repository
>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>> >
>> >
>> > The following commit(s) were added to refs/heads/master by this push:
>> >   new 000c876  Make migrate.sh usable from any directory
>> > 000c876 is described below
>> >
>> > commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
>> > Author: Martin Tzvetanov Grigorov 
>> > AuthorDate: Fri Dec 11 09:22:22 2020 +0200
>> >
>> >  Make migrate.sh usable from any directory
>> >
>> >  Until now one has to `cd` to the bin/ folder to be able to execute
>> migrate.sh, otherwise lib/ folder won't be found
>> > ---
>> >   src/main/scripts/migrate.sh | 4 +++-
>> >   1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh
>> > index c2b941c..3d3f34c 100755
>> > --- a/src/main/scripts/migrate.sh
>> > +++ b/src/main/scripts/migrate.sh
>> > @@ -1,4 +1,6 @@
>> >   #!/bin/sh
>> >
>> > +BIN_FOLDER=`dirname $PWD/$0`
>>
>> Does that work if $0 is an absolute path?
>>
>
> Yes, it does. I have tested it!
> BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works
> just fine on my Ubuntu.
> Does it work on Solaris ? :-)
>
>
>>
>> Maybe one could
>>
>>cd `dirname $0`
>>
>
Two issues with this:

1) the script usage is: ./bin/migrate.sh input.war output.war
if we "cd" into bin/ then input.war is not there anymore. Its path should
be fixed to ../input.war somehow

2) it would be good to leave the user back to the original directory after
executing the script but pushd/popd are not available for 'sh'. We will
need to use Bash or another


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

Re: [tomcat-jakartaee-migration] branch master updated: Make migrate.sh usable from any directory

[Martin Grigorov]

Hi Rainer,

On Fri, Dec 11, 2020 at 10:37 AM Rainer Jung 
wrote:

> Am 11.12.2020 um 08:25 schrieb mgrigo...@apache.org:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > mgrigorov pushed a commit to branch master
> > in repository
> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >   new 000c876  Make migrate.sh usable from any directory
> > 000c876 is described below
> >
> > commit 000c876ea3a1e700df2fffef70b29d9c3a9dfef2
> > Author: Martin Tzvetanov Grigorov 
> > AuthorDate: Fri Dec 11 09:22:22 2020 +0200
> >
> >  Make migrate.sh usable from any directory
> >
> >  Until now one has to `cd` to the bin/ folder to be able to execute
> migrate.sh, otherwise lib/ folder won't be found
> > ---
> >   src/main/scripts/migrate.sh | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/main/scripts/migrate.sh b/src/main/scripts/migrate.sh
> > index c2b941c..3d3f34c 100755
> > --- a/src/main/scripts/migrate.sh
> > +++ b/src/main/scripts/migrate.sh
> > @@ -1,4 +1,6 @@
> >   #!/bin/sh
> >
> > +BIN_FOLDER=`dirname $PWD/$0`
>
> Does that work if $0 is an absolute path?
>

Yes, it does. I have tested it!
BIN_FOLDER looks a bit strange: ///some/absolute/path/bin but it works just
fine on my Ubuntu.
Does it work on Solaris ? :-)


>
> Maybe one could
>
>cd `dirname $0`
>
> Regards,
>
> Rainer
>
> -
> 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

[Martin Grigorov]

On Thu, Dec 10, 2020 at 1:39 PM Mark Thomas  wrote:

> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> available for voting.
>
> This is (potentially) the first release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>
> The proposed 0.1.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] Apache Tomcat migration tool for Jakarta EE

[Martin Grigorov]

On Thu, Dec 10, 2020 at 11:50 PM Igal Sapir  wrote:

> On Thu, Dec 10, 2020 at 5:58 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Mark,
> >
> > On 12/10/20 06:39, Mark Thomas wrote:
> > > The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> > > available for voting.
> > >
> > > This is (potentially) the first release.
> > >
> > > It can be obtained from:
> > >
> >
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
> > >
> > > The Maven staging repo is:
> > >
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
> > >
> > > The tag is:
> > > https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> > > cbada3204bf9c43ca0cf481cd88c7521690b30a0
> > >
> > > The proposed 0.1.0 release is:
> > >
> > > [ ] -1: Broken. Do not release because...
> > > [ ] +1: Acceptable. Go ahead and release.
> >
> > Do we even need (a) a release and (b) a VOTE?
> >
> > I once heard Ross say that there was an ASP project (Subversion?) that
> > never had votes; they only had releases. That seemed to cut-down on the
> > red-tape required to get things out into the world. I can't find a
> > reference for that, now.
> >
> > Since this is a developer tool and not a runtime library or anything
> > like that, maybe we can just say "YMMV, this is available any time you
> > want it"?
> >
> > That said, I have no objections whatsoever with holding a vote. I am an
> > unsigned "0" on the vote itself; I have not even downloaded the source
> > let alone attempted to migrate a project using it.
> >
>
> I'm a +0 on this one.  Like Chris, I also did not even download nor tested
> that tool.
>
> Did we use that tool to migrate the Tomcat examples?  Were they all
> migrated successfully?
>

No. The examples were migrated manually, i.e. their source code was
migrated.
The tool migrates binary files (.war,.jar, .class). It is useful when your
application depends on third party libraries which still use javax.**

Martin


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

Re: Snapshot published for Jakarta EE migration tool

[Martin Grigorov]

On Tue, Dec 8, 2020 at 8:13 PM Martin Grigorov  wrote:

>
>
> On Tue, Dec 8, 2020, 19:13 Mark Thomas  wrote:
>
>> On 01/12/2020 17:09, Mark Thomas wrote:
>> > Hi all,
>> >
>> > I've just published the following snapshot:
>> >
>> >
>> https://repository.apache.org/content/groups/snapshots/org/apache/tomcat/jakartaee-migration/0.1.0-SNAPSHOT/
>> >
>> > This isn't a formal RC as I am expecting there to be some issues. Please
>> > take a look and report any issues back to this thread.
>> >
>> > I hope to clean things up and be in a position to start a formal release
>> > vote late this week / early next.
>>
>> Ping. Anyone found any issues?
>>
>
> I've built the latest master to test 10.0.0 and migrated Apache Wicket 9.x
> examples.
> I will re-test tomorrow with the jar from Maven!
>

https://repository.apache.org/content/groups/snapshots/org/apache/tomcat/jakartaee-migration/0.1.0-SNAPSHOT/jakartaee-migration-0.1.0-20201201.170558-1-shaded.jar
works just fine !


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

Re: Snapshot published for Jakarta EE migration tool

[Martin Grigorov]

On Tue, Dec 8, 2020, 19:13 Mark Thomas  wrote:

> On 01/12/2020 17:09, Mark Thomas wrote:
> > Hi all,
> >
> > I've just published the following snapshot:
> >
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/tomcat/jakartaee-migration/0.1.0-SNAPSHOT/
> >
> > This isn't a formal RC as I am expecting there to be some issues. Please
> > take a look and report any issues back to this thread.
> >
> > I hope to clean things up and be in a position to start a formal release
> > vote late this week / early next.
>
> Ping. Anyone found any issues?
>

I've built the latest master to test 10.0.0 and migrated Apache Wicket 9.x
examples.
I will re-test tomorrow with the jar from Maven!


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

io_uring backend for NIO

[Martin Grigorov]

Hi devs,

Maybe you have also noticed some noise in the web about io_uring
 - the better epoll.

Pros:
- less syscalls
- no copying of data between userland and kernel

Cons:
- it seems rather unstable to me.
Many articles say that io_uring should be more stable since kernel v5.6.x
but in my experience there are many changes in each kernel versions

https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/
is a good article explaining the benefits.

Recently Netty project released 0.0.1-SNAPSHOT (
https://netty.io/news/2020/11/16/io_uring-0-0-1-Final.html) and
0.0.2-SNAPSHOT with some nice numbers:
- epoll

Speed: 80820 request/sec, 80820 response/sec
Requests: 2424626
Responses: 2424625

- io_uring

Speed: 267371 request/sec, 267370 response/sec
Requests: 8021137
Responses: 8021128

I've tried it with my HTTP2 comparison tests
(https://martin-grigorov.medium.com/comparing-the-performance-of-several-http2-web-servers-fb5f3787532a)

and the results were better but not so dramatic:

- epoll

-- x86_64: 24688 reqs/sec

-- aarch64: 25344

- uring

-- x86_64: 26731

-- aarch64: 28443


So I thought: What about introducing a Uring Protocol/Connector ?!
Since Netty uses JNI

to talk to io_uring C APIs it should look something like the AprConnector.

But soon after I realized that it would be much more reusable if implemented

as  java.nio.channels.spi.SelectorProvider. This way any project (not
just Tomcat) can

make use of it.


Here I wanted to poll what other devs think about this idea ?

Does that sound interesting to you ? Or we should leave it to the JDK developers

to do it for JDK XY (I guess this could be as early as Java 18 since 17 will

be a LTS and most probably the current epoll based impl won't be replaced so

soon).

I don't suggest to put it in Tomcat's code, so the dependency on JNI

should not be considered as a stopper.


I have some very early attempts implementing it with Netty's JNI code and

with Java Panama's jextract, but I've faced issues with both.


Please encourage/discourage me to continue digging in this! :-)


Regards,

Martin

Re: [VOTE] Release Apache Tomcat 10.0.0

[Martin Grigorov]

On Thu, Dec 3, 2020 at 12:50 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0 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-M10 are:
>
> - Specs are now final. Tomcat passes the TCKs apart from a number of
>   expected failures that don't impact spec compliance.
>
> - The APR/Native AJP and HTTP connectors have been deprecated.
>   Tomcat Native will continue to be used to support OpenSSL use with NIO
>   and NIO2.
>
> - Align the behaviour of ServletContext.getRealPath(String path) with
>   the recent clarification from the Servlet specification project. If
>   the path parameter does not start with / then Tomcat processes the
>   call as if / is appended to the beginning of the provided path.
>
> 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.0/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1287/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0
> 4c8b650437e2464c1c31c6598a263b3805b7a81f
>
> The proposed 10.0.0 release is:
> [ ] Broken - do not release
> [ X ] Beta   - go ahead and release as 10.0.0 (beta)
> [ ] Stable - go ahead and release as 10.0.0 (stable)
>
>
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.41

[Martin Grigorov]

On Thu, Dec 3, 2020 at 3:12 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.41 release is now available for voting.
>
> The notable changes compared to the 9.0.40 release are:
>
> - Align the behaviour of ServletContext.getRealPath(String path) with
>   the recent clarification from the Servlet specification project. If
>   the path parameter does not start with / then Tomcat processes the
>   call as if / is appended to the beginning of the provided path.
>
> - Fix a potential file descriptor leak when WebSocket connections are
>   attempted and fail. Patch provided by Maurizio Adami.
>
> -  Ensure that the LoadBalancerDrainingValve uses the correct setting
>for the secure attribute for any session cookies it creates. Based on
>a pull request by Andreas Kurth.
>
> 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.41/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1289/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.41
> 75d7a2069bf4360bcd8b885c6b7387d70c9cb052
>
> The proposed 9.0.41 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.41
>

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

[Martin Grigorov]

On Thu, Dec 3, 2020 at 4:50 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.61 release is now available for voting.
>
> The notable changes compared to the 8.5.60 release are:
>
> - Align the behaviour of ServletContext.getRealPath(String path) with
>   the recent clarification from the Servlet specification project. If
>   the path parameter does not start with / then Tomcat processes the
>   call as if / is appended to the beginning of the provided path.
>
> - Fix a potential file descriptor leak when WebSocket connections are
>   attempted and fail. Patch provided by Maurizio Adami.
>
> - Ensure that the LoadBalancerDrainingValve uses the correct setting
>   for the secure attribute for any session cookies it creates. Based on
>   a pull request by Andreas Kurth.
>
> 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.61/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1290/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.61
> 77d330abea52e4aeb039ca7eb8a766e0e1c56a71
>
> The proposed 8.5.61 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.61
>


Regards,
Martin


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

Re: [tomcat] 01/02: Replace Collections.sort() with List.sort()

[Martin Grigorov]

Hi,

Shall we backport these commits to 9.x and 8.5?
It will make it easier to backport future changes in these classes.

Martin

On Fri, Dec 4, 2020, 00:06 Emmanuel Bourg  wrote:

> Hi Christopher,
>
> Le 03/12/2020 à 21:49, Christopher Schultz a écrit :
>
> > I'm curious as to why this change is warranted. I'm not suggesting it's
> > not... just wondering what the benefit is? Avoiding a pass-through
> > method call?
>
> It's the shorter idiom to sort lists with Java 8+, it just improves the
> readability. I don't think the method call avoided has any impact, the
> actual sorting dominates the time spent anyway.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Objection to the deprecation of the tomcat-native/APR connector

[Martin Grigorov]

Hi Graham,

On Tue, Dec 1, 2020 at 7:43 PM Graham Leggett 
wrote:

> On 01 Dec 2020, at 13:48, Rémy Maucherat  wrote:
>
> > You still have years to plan a migration off the APR connector as it will
> > only be removed in 10.1 and Tomcat 9.0 continues to be supported.
> >
> > This eventual removal or APR has been discussed for years. BTW, so that
> you
> > know, there are also discussions about AJP.
>
> I am painfully aware of the discussions on the removal of AJP.
>
> I first encountered this problem when Atlassian arbitrarily announced
> removal of support for AJP (I assume off the back of the discussion),
> leaving no practical way to pass certificates across to Tomcat.
>
> For this reason I developed the RFC compliant secure base64url API here:
>
> https://github.com/apache/apr/blob/trunk/include/apr_encode.h <
> https://github.com/apache/apr/blob/trunk/include/apr_encode.h>
>
> Organised the donation of and then brought the RFC compliant JSON API up
> to the required security level here:
>
> https://github.com/apache/apr/blob/trunk/include/apr_json.h <
> https://github.com/apache/apr/blob/trunk/include/apr_json.h>
>
> Added digest support to the crypto API here:
>
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_crypto.h <
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_crypto.h>
>
> Add an RFC compliant JOSE implementation here:
>
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_jose.h <
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_jose.h>
>
> Then added the two modules mod_auth_bearer and mod_autht_jwt here
> (outstanding for want of docs):
>
>
> http://apache-http-server.18135.x6.nabble.com/Patch-mod-auth-bearer-mod-autht-jwt-An-alternative-to-AJP-td5051929.html#a5051936
> <
> http://apache-http-server.18135.x6.nabble.com/Patch-mod-auth-bearer-mod-autht-jwt-An-alternative-to-AJP-td5051929.html#a5051936
> >
>
> Then created the option for Tomcat to read info from JWT here:
>
> https://github.com/minfrin/tomcat7-jwt-authenticator <
> https://github.com/minfrin/tomcat7-jwt-authenticator>
>
> While it can be tempting to downplay the arbitrary removal of capabilities
> from tomcat as “a few characters” change, or by telling people they  have
> “years” to make a change, the knock-on effect of these changes are
> significant and very expensive.
>
> I would appreciate the help minimising the impact of these changes before
> I encounter them unexpectedly in an update from a vendor.
>

As I suggested in your PR about Unix Domain Sockets support - what about
extracting the APR (and AJP ?!) code into its own project!
The main work has been done over the years. Now it just needs someone to
maintain it.

Regards,
Martin


>
> Regards,
> Graham
> —
>
>

Re: JDK 16 Early Access build 26 is now available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass with JDK 16 b26 on Ubuntu 20.04.1
(x86_64 & aarch64)!

Regards,
Martin

On Fri, Nov 27, 2020 at 1:15 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> OpenJDK 16 Early Access build 26**is now available at
> http://jdk.java.net/16
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>
>   * Schedule: *JDK 16 Rampdown Phase One Starts on 2020/12/10 [1] *
>
>   * Features [1]: Most recent Integrations:
>   o Integrated JEP 389: Foreign Linker API (Incubator)
>  with this release.
>   + JEP 389 introduces an API that offers statically-typed,
> pure-Java access to native code.
>   + This API, together with the JEP 383
> , will considerably
> simplify the otherwise error-prone process of binding to a
> native library.
>
> **
>
>   * Release Notes [2]
>
>   * Changes in recent builds that maybe of interest:
>   o Build 26
>   + JDK-8202343: *Disable TLS 1.0 and 1.1*
>   + JDK-8251317:**Support for CLDR version 38**
>   + JDK-8212879: Make JVMTI TagMap table concurrent
>   + JDK-8236926: Concurrently uncommit memory in G1
>   + JDK-8243559: Removed Root Certificates with 1024-bit Keys
>   + JDK-8253459: Argument index of zero or unrepresentable by
> int throws IllegalFormatException
>   + JDK-8256643: Terminally deprecate ThreadGroup stop, destroy,
> isDestroyed, setDaemon and isDaemon
>   o Build 25
>   + JDK-8247781: Day period support added to java.time formats
>   + JDK-8202471: (ann) Cannot read type annotations on generic
> receiver type's type variables *[**Reported by ByteBuddy]*
>   + JDK-8255947: [macos] Signed macOS jpackage app doesn't
> filter spurious '-psn' argument *[**Reported by JOSM]*
>   + JDK-8256063: Module::getPackages returns the set of package
> names in this module
>
>   * JDK 16 - topics of interest
>   o Inside Java Episode 7 “The Vector API” with John Rose and Paul
> Sandoz
>   + https://inside.java/2020/11/17/podcast-007/
> 
>   o Biased locking Obsoletion update
>   + https://inside.java/2020/11/17/biased-locking-obsoletion/
> 
>   * Project Loom with Ron Pressler
>   o https://inside.java/2020/11/24/podcast-008/
>   * Update on 64-bit ARM Support for Oracle OpenJDK and Oracle JDK
>   o https://inside.java/2020/11/12/arm-support-update/
> 
>
> Project Lanai Early-Access: EA 7 Build 16-lanai+3-278
>  (2020/11/17)
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> 
>   * These 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 lanai-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> The Java Cryptographic Roadmap has been updated [3]:
>
>   * Distrust TLS 1.0 and TLS 1.1 by default
>   o TLS protocol versions 1.0 and 1.1 are no longer considered
> secure and have been superseded by more secure and modern
> versions (TLS 1.2 and 1.3). This change has been integrated with
> JDK 16 Early Access build 26.
>   * Upgrade of default algorithms used to encrypt PKCS12 keystores
>   o The new algorithms are based on AES-256 and SHA-256 and are
> stronger than the old algorithms which were based on RC2,
> DESede, and SHA-1.This change is already included in JDK 16
> Early Access build 23.
>
> RgdsRory
>
> [1] https://openjdk.java.net/projects/jdk/16/
> [2] https://jdk.java.net/16/release-notes
> [3] https://www.java.com/en/jre-jdk-cryptoroadmap.html
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: Tomcat 10.0.x and Jakarta 9 TCK status

[Martin Grigorov]

On Mon, Nov 23, 2020, 17:07 Mark Thomas  wrote:

> Hi all,
>
> Now that the final versions of the TCKs for Jakarta 9 are available I've
> been running them against the current 10.0.x (effectively 10.0.0-M10).
>
> The results can be summarised as:
>
> Expression Language
>- Passes apart from the API signature test because we use BND
>  annotations for JPMS support
>
> Websocket
>- Passes apart from the API signature test because we use BND
>  annotations for JPMS support
>
> Servlet
>- Passes apart from the default context path test because Tomcat
>  deliberately always overrides the associated web.xml setting
>
> JSP
>   - Passes
>
> All of the above were tested with both Java 8 and Java 11.
>
> The BND failures are not a concern as the annotations have no impact at
> runtime.
>
> The Servlet failure is not a concern as Tomcat's behaviour is spec
> compliant. The spec allows implementations to override the web.xml
> setting and Tomcat will always do this.
>
> It is worth noting the Jakarta EE 9 only targetted Java 8. Current
> planning is that a Jakarta EE 9.1 release will target Java 11 support
> (while retaining Java 8 compatibility). This is essentially


What exactly does this mean?
EE 9.1 will use multi-versioned classes? Or something else?

a no-op for
> Tomcat 10. We already have this and more. Tomcat runs on all current
> versions of the JRE including the Java 16 early access releases.
>
> In summary, Tomcat 10 is in excellent shape.
>
> Given the alpha/beta/stable definition from [1], 10.0.x now clearly
> meets the criteria for beta and some may consider it meets the criteria
> for stable. With that in mind the next 10.0.x release vote will include
> options for broken, beta and stable.
>

Awesome!


> Mark
>
>
> [1] http://tomcat.apache.org/whichversion.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 7.0.107

[Martin Grigorov]

On Wed, Nov 18, 2020 at 3:00 PM Violeta Georgieva 
wrote:

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

Tested with Apache Wicket 8.x examples application.

Regards,
Martin


>
> Regards,
> Violeta
>

Re: JDK 16 Early Access build 24 is now available

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass with JDK 16-ea+24-1553 on Linux both
x86_64 and aarch64!

Regards,
Martin

On Fri, Nov 13, 2020 at 12:19 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> OpenJDK 16 Early Access build 24**is now available at
> http://jdk.java.net/16
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>
>   * Schedule
>
>  2020/12/10 Rampdown Phase One
>  2021/01/14 Rampdown Phase Two
>  2021/02/04 Initial Release Candidate
>  2021/02/18 Final Release Candidate
>  2021/03/16 General Availability
>
>   * Features:
>   o JEPs targeted to JDK 16, so far:
>   + 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 392: Packaging Tool 
>   + JEP 393: Foreign-Memory Access API (Third Incubator)
> 
>   + JEP 394: Pattern Matching for instanceof
> 
>   + JEP 395: Records 
>
> **
>
>   * Release Notes are available at http://jdk.java.net/16/release-notes
> 
>
>   * Changes in recent builds that maybe of interest:
>   o Build 24
>   + JDK-8231599: NPE when loading a preview classfile from a
> future Java version
>   # *Reported by JUnit5*
>   + JDK-8254661: arm32: additional cleanup after fixing SIGSEGV
>   # *Reported by JaCoCo*
>   + JDK-8255584: `HttpPrincipal::getName` returns incorrect name
>   + JDK-8255226: (tz) Upgrade time-zone data to tzdata2020d
>   o Build 23
>   + JDK-8254876: (fs) NullPointerException not thrown when first
> argument to Path.of or Paths.get is null
>   + JDK-8255576: (fs) Files.isHidden() throws
> ArrayIndexOutOfBoundsException (unix)
>   # *Reported by JUnit5*
>   + JDK-8255616: Removal of experimental features AOT and Graal JIT
>   o Build 22
>   + JDK-8243583: Change 'final' error checks to throw ICCE
>   + JDK-8254982: (tz) Upgrade time-zone data to tzdata2020c
>
> Project Loom Early-Access Build: Build 16-loom+7-285
>  (2020/11/4)
>
>   * *Want to know more* - check out -
> https://inside.java/2020/11/11/project-loom-at-nyc-java-sig/
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> 
>   o These builds are based on jdk-16+20
> 
>   o These EA builds are produced for the purpose of gathering
> feedback. Use for any other purpose is at your own risk.
>   o 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
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [VOTE] Release Apache Tomcat 8.5.60

[Martin Grigorov]

On Thu, Nov 12, 2020 at 7:54 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.60 release is now available for voting.
>
> The notable changes compared to the 8.5.59 release are:
>
> - Statistics are now available (via JMX) for HTTP/2, WebSocket and
>   HTTP/1.1 upgraded connections
>
> - Stability improvements for HTTP/2
>
> - Improvements to error handling in the connection pool used by the JNDI
>   Realm
>
> 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.60/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1285/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.60
> 04d663d7541a013098db3a3f81b1c23c255c12a4
>
> The proposed 8.5.60 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.60
>

Tested with Apache Wicket 9.x examples app.

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

[Martin Grigorov]

On Thu, Nov 12, 2020 at 5:58 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.40 release is now available for voting.
>
> The notable changes compared to the 9.0.39 release are:
>
> - Statistics are now available (via JMX) for HTTP/2, WebSocket and
>   HTTP/1.1 upgraded connections
>
> - Stability improvements for HTTP/2
>
> - Stability improvements for the NIO connector
>
> 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.40/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1284/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.40
> 11cce490eb67a8aca64377a22c0cea2e38896725
>
> The proposed 9.0.40 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.40
>

Tested with Apache Wicket 9.x examples app.

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

[Martin Grigorov]

On Thu, Nov 12, 2020 at 2:33 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M10 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-M9 are:
>
> - Statistics are now available (via JMX) for HTTP/2, WebSocket and
>   HTTP/1.1 upgraded connections
>
> - Stability improvements for HTTP/2
>
> - Stability improvements for the NIO 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.0-M10/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1283/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M10
> 9826be4c8368c94eab1e804b456867ca1cb766c3
>
> The proposed 10.0.0-M10 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M10
>

Tested with 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: JDK 16 EA build 21 is available

[Martin Grigorov]

Hi Rory,

I've just ran Tomcat's build and tests on JDK 16-ea+21-1209 - no problems
found!

Regards,
Martin

On Fri, Oct 23, 2020 at 1:13 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> OpenJDK 16 Early Access build 21**is now available at
> http://jdk.java.net/16
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>
>   * Schedule (proposed)
>
>  2020/12/10 Rampdown Phase One
>  2021/01/14 Rampdown Phase Two
>  2021/02/04 Initial Release Candidate
>  2021/02/18 Final Release Candidate
>  2021/03/16 General Availability
>
>   * Features:
>   o JEPs targeted to JDK 16, so far:
>   + 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 386: Alpine Linux Port 
>   + JEP 387: Elastic Metaspace 
>   + JEP 388: Windows/AArch64 Port
> 
>
> **
>
>   * Changes in recent builds that maybe of interest:
>   o Build 21
>   + JDK-8236862: Enhance support of Proxy class
>   + JDK-8237990: Added Property to Control LDAP Authentication
> Mechanisms Allowed to Authenticate Over Clear Connections
>   + JDK-8242068: Signed JAR support for RSASSA-PSS and EdDSA
>   + JDK-8245417: Improve certificate chain handling
>   + JDK-8253952: Refine ZipOutputStream.putNextEntry() to
> recalculate ZipEntry's compressed size
>   o Build 20
>   + JDK-8232092: (fs) Files::isWritable returns false on a
> writeable root directory (win)
>   # Reported by JUnit5
>   + JDK-8248262: Wrong link target in
> ModuleDescriptor#isAutomatic's API documentation
>   # Reported by JUnit5
>   + JDK-8253965: Delete the outdated java.awt.PeerFixer class
>   + JDK-8253566: clazz.isAssignableFrom will return false for
> interface implementors
>   # Found by Hibernate Validator
>   + JDK-8254177: US/Pacific-New Zone name removed as part of
> tzdata2020b
>   o Build 19
>   + JDK-8253761: Wrong URI syntax printed by jar --describe-module
>   # Reported by JUnit5
>
> Project Lanai Early-Access Build: EA 6 Build 16-lanai+2-229
>  (2020/10/4)
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> .
>   * These builds are based upon the latest state of the current in
> development JDK, and so may contain new features and unresolved bugs
> unrelated to Project Lanai. Project Lanai Wiki:
> https://wiki.openjdk.java.net/display/lanai/Main
>   * Please send feedback via e-mail tolanai-...@openjdk.java.net
> . To send e-mail to this address
> you must firstsubscribe to the mailing list
> .
>
> Project Panama Early-Access Build: Build 16-panama+2-193
>  (2020/10/1)
>
>   * These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * These builds are based on an incomplete version of JDK 16.
>   * Please send feedback via e-mail topanama-...@openjdk.java.net
> . To send e-mail to this address
> you must firstsubscribe to the mailing list
> .
>
> Oracle JRE and JDK Cryptographic Roadmap has been updated [1]
>
>   * Oracle has announced plans to add support for x25519 and x448 named
> elliptic curve groups to TLS.
>   * Support is targeted for JDK 11 with the January 2021 CPU release.
>
> Oracle Critical Patch Update released 21-Oct-2020
>
>   * https://www.oracle.com/security-alerts/cpuoct2020.html
>
>
> *__*
> Rgds,Rory
>
> [1] https://java.com/en/jre-jdk-cryptoroadmap.html
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [Bug 64839] HTTP2: Exception in thread "http-nio-x.y.z-1090-ClientPoller" java.lang.NullPointerException

[Martin Grigorov]

On Thu, Oct 22, 2020 at 5:56 PM  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=64839
>
> Arshiya  changed:
>
>What|Removed |Added
>
> 
>  Status|NEEDINFO|NEW
>
> --- Comment #7 from Arshiya  ---
> The BufferOverFlow Exception was printed for about 4 times and then the
> NullPointer Exception.. The exact time stamp of the trace is not known.
>
> Exception in thread "http-nio-x.y.z-1090-exec-20"
> java.nio.BufferOverflowException
>

I think this has been fixed in 9.0.39. Please upgrade!


> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206)
> at
> org.apache.tomcat.util.net
> .SocketBufferHandler.unReadReadBuffer(SocketBufferHandler.java:100)
> at
> org.apache.tomcat.util.net
> .SocketWrapperBase.unRead(SocketWrapperBase.java:401)
> at
>
> org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.completed(Http2AsyncParser.java:306)
> at
>
> org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.completed(Http2AsyncParser.java:163)
> at
> org.apache.tomcat.util.net
> .SocketWrapperBase$VectoredIOCompletionHandler.completed(SocketWrapperBase.java:1087)
> at
> org.apache.tomcat.util.net
> .NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1511)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
> Please let us know if this is of any help ?
>
> Please find the hardware specs /Java version
> Hardware Spec
> Environment - OpenStack Compute hosted on VM
> RAM - RAM - 119478416 - 119 GB
> Cores of CPU - 12
> OS - RHEL 7.4
> Kernel version - 3.10.0-693.58.1.el7.x86_64
> Java Version:1.8.0_241
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat] branch master updated: Add extended ErrorReportValve that returns response as JSON instead of HTML

[Martin Grigorov]

On Wed, Oct 14, 2020 at 5:55 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> kfujino 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 42a0841  Add extended ErrorReportValve that returns response as
> JSON instead of HTML
> 42a0841 is described below
>
> commit 42a0841d289a35117da842201622454a9f387cd7
> Author: KeiichiFujino 
> AuthorDate: Wed Oct 14 23:54:22 2020 +0900
>
> Add extended ErrorReportValve that returns response as JSON instead of
> HTML
> ---
>  .../catalina/valves/JsonErrorReportValve.java  | 111
> +
>  webapps/docs/changelog.xml |   8 +-
>  2 files changed, 117 insertions(+), 2 deletions(-)
>
> diff --git a/java/org/apache/catalina/valves/JsonErrorReportValve.java
> b/java/org/apache/catalina/valves/JsonErrorReportValve.java
> new file mode 100644
> index 000..a438e77
> --- /dev/null
> +++ b/java/org/apache/catalina/valves/JsonErrorReportValve.java
> @@ -0,0 +1,111 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.catalina.valves;
> +
> +import java.io.IOException;
> +import java.io.Writer;
> +import java.util.concurrent.atomic.AtomicBoolean;
> +
> +import org.apache.catalina.connector.Request;
> +import org.apache.catalina.connector.Response;
> +import org.apache.catalina.tribes.util.ExceptionUtils;
> +import org.apache.coyote.ActionCode;
> +import org.apache.tomcat.util.res.StringManager;
> +
> +/**
> + * Implementation of a Valve that outputs error jsons.
> + *
> + * This Valve should be attached at the Host level, although it will
> work
> + * if attached to a Context.
> + *
> + */
> +public class JsonErrorReportValve extends ErrorReportValve {
> +
> +public JsonErrorReportValve() {
> +super();
> +}
> +
> +@Override
> +protected void report(Request request, Response response, Throwable
> throwable) {
> +
> +int statusCode = response.getStatus();
> +
> +// Do nothing on a 1xx, 2xx and 3xx status
> +// Do nothing if anything has been written already
> +// Do nothing if the response hasn't been explicitly marked as in
> error
> +//and that error has not been reported.
> +if (statusCode < 400 || response.getContentWritten() > 0 ||
> !response.setErrorReported()) {
> +return;
> +}
> +
> +// If an error has occurred that prevents further I/O, don't
> waste time
> +// producing an error report that will never be read
> +AtomicBoolean result = new AtomicBoolean(false);
> +response.getCoyoteResponse().action(ActionCode.IS_IO_ALLOWED,
> result);
> +if (!result.get()) {
> +return;
> +}
> +
> +StringManager smClient =
> StringManager.getManager(Constants.Package, request.getLocales());
> +response.setLocale(smClient.getLocale());
> +String type = null;
> +if (throwable != null) {
> +type = smClient.getString("errorReportValve.exceptionReport");
> +} else {
> +type = smClient.getString("errorReportValve.statusReport");
> +}
> +String message = response.getMessage();
> +if (message == null && throwable != null) {
> +message = throwable.getMessage();
> +}
> +String description = null;
> +description = smClient.getString("http." + statusCode + ".desc");
> +if (description == null) {
> +if (message.isEmpty()) {
> +return;
> +} else {
> +description =
> smClient.getString("errorReportValve.noDescription");
> +}
> +}
> +String jsonReport = "{\n" +
> +"  \"type\": \"" + type + "\",\n" +
> +"  \"message\": \"" + message + "\"\n" +
> +"  \"description\": \"" + description +
> "\"\n" +
> +"}";
> +try {
> +try {
> +response.setContentType("application/json");
> +   

Re: [VOTE] Release Apache Tomcat 8.5.59

[Martin Grigorov]

On Tue, Oct 6, 2020 at 8:34 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.59 release is now available for voting.
>
> The notable changes compared to the 8.5.58 release are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Deprecate the JDBCRealm.
>
> - Ensure that none of the methods on a ServletContext instance always
>   fail when running under a SecurityManager. Pull request provided by
>   Kyle Stiemann.
>
> 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.59/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1282/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.59
> c042ec71219dbde3e1ce0381ce5be0801120d0fa
>
> The proposed 8.5.59 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.59
>

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

[Martin Grigorov]

On Tue, Oct 6, 2020 at 5:50 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.39 release is now available for voting.
>
> The notable changes compared to the 9.0.38 release are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Allow using the utility executor for annotation scanning. Patch
>   provided by Jatin Kamnani.
>
> - Add a bloom filter to speed up archive lookup and improve deployment
>   speed of applications with a large number of JARs. Patch provided by
>   Jatin Kamnani.
>
> 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.39/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1281/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.39
> 6989c4e9360b4f9443862968c15a95d17f264321
>
> The proposed 9.0.39 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.39
>

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

[Martin Grigorov]

On Tue, Oct 6, 2020 at 4:38 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M9 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-M8 are:
>
> - Refactor the handling of closed HTTP/2 streams to reduce the heap
>   usage associated with used streams and to retain information for more
>   streams in the priority tree.
>
> - Allow using the utility executor for annotation scanning. Patch
>   provided by Jatin Kamnani.
>
> - Add a bloom filter to speed up archive lookup and improve deployment
>   speed of applications with a large number of JARs. Patch provided by
>   Jatin Kamnani.
>
>
> 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.0-M9/
> The Maven staging repo is:
>
> https://repository.apache.org/content/repositories/orgapachetomcatrepo-1280/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M9
> 6f143d19d151620cd0bfe9ec2ffa429e36ad0e45
>
> The proposed 10.0.0-M9 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M9
>

Tested with Apache Wicket 9.0.x migrated with the latest version of
tomcat-jakartaee-migration

Martin


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

Re: JDK 16 EA build 18 is now available

[Martin Grigorov]

On Fri, Oct 2, 2020 at 1:49 PM Martin Grigorov  wrote:

> Hi Rory,
>
> Before you ask: I've just tested JDK 16-ea+18-901 (x86_64 and aarch64)
> with Apache Tomcat - build and tests are OK!
>

Actually, you did ask! The mail was in a different folder... Anyway, Tomcat
is good with the new JDK build !


>
> Regards,
> Martin
>
> On Fri, Oct 2, 2020 at 12:04 PM Rory O'Donnell 
> wrote:
>
>> Hi Mark & Gavin,
>>
>> OpenJDK 16 Early Access build 18**is now available at
>> http://jdk.java.net/16
>>
>>   * These early-access , open-source builds are provided under the
>>   o GNU General Public License, version 2, with the Classpath
>> Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>>
>>   * Features:
>>   o JEPs proposed to target JDK 16
>>   + JEP 376: ZGC: Concurrent Thread-Stack Processing
>> <https://openjdk.java.net/jeps/376>
>>   + JEP 386: Alpine Linux Port <https://openjdk.java.net/jeps/386
>> >
>>   + JEP 388: Windows/AArch64 Port
>> <https://openjdk.java.net/jeps/388>
>>   o JEPs targeted to JDK 16, so far:
>>   + JEP 338: Vector API (Incubator)
>> <https://openjdk.java.net/jeps/338>
>>   + JEP 347: Enable C++14 Language Features
>> <https://openjdk.java.net/jeps/347>
>>   + JEP 357: Migrate from Mercurial to Git
>> <https://openjdk.java.net/jeps/357>
>>   + JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369
>> >
>>   + JEP 387: Elastic Metaspace <https://openjdk.java.net/jeps/387
>> >
>>
>>   * Release Notes are available at http://jdk.java.net/16/release-notes
>>
>> **
>>
>>   * Changes in recent builds that maybe of interest:
>>   o Build 17
>>   + JDK-8247281: Object monitors no longer keep strong
>> references to their associated object
>>   + JDK-8202473: A type variable with multiple bounds does not
>> correctly place type annotation
>>   # Reported by ByteBuddy
>>   + JDK-8234808: jdb quoted option parsing broken
>>   # Reported by Apache Tomcat
>>   o Build 16
>>   + JDK-8172366: SUN, SunRsaSign, and SunEC Providers Supports
>> SHA-3 Based Signature Algorithms
>>   + JDK-8244706: GZIPOutputStream now sets the GZIP OS Header
>> Field to the correct default value
>>
>>   * Quality Report for September 2020 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+September+2020
>>
>> --
>> Rgds, Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA, Dublin, Ireland
>>
>>

Re: JDK 16 EA build 18 is now available

[Martin Grigorov]

Hi Rory,

Before you ask: I've just tested JDK 16-ea+18-901 (x86_64 and aarch64) with
Apache Tomcat - build and tests are OK!

Regards,
Martin

On Fri, Oct 2, 2020 at 12:04 PM Rory O'Donnell 
wrote:

> Hi Mark & Gavin,
>
> OpenJDK 16 Early Access build 18**is now available at
> http://jdk.java.net/16
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception .
>
>   * Features:
>   o JEPs proposed to target JDK 16
>   + JEP 376: ZGC: Concurrent Thread-Stack Processing
> 
>   + JEP 386: Alpine Linux Port 
>   + JEP 388: Windows/AArch64 Port
> 
>   o JEPs targeted to JDK 16, so far:
>   + 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 387: Elastic Metaspace 
>
>   * Release Notes are available at http://jdk.java.net/16/release-notes
>
> **
>
>   * Changes in recent builds that maybe of interest:
>   o Build 17
>   + JDK-8247281: Object monitors no longer keep strong
> references to their associated object
>   + JDK-8202473: A type variable with multiple bounds does not
> correctly place type annotation
>   # Reported by ByteBuddy
>   + JDK-8234808: jdb quoted option parsing broken
>   # Reported by Apache Tomcat
>   o Build 16
>   + JDK-8172366: SUN, SunRsaSign, and SunEC Providers Supports
> SHA-3 Based Signature Algorithms
>   + JDK-8244706: GZIPOutputStream now sets the GZIP OS Header
> Field to the correct default value
>
>   * Quality Report for September 2020 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+September+2020
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: svn/git for website

[Martin Grigorov]

On Fri, Oct 2, 2020 at 12:09 AM Mark Thomas  wrote:

> Hi all,
>
> The topic came up at the BoF session at the end of the Tomcat track of
> migrating the website from svn to git. There were strong opinions both
> for migrating and for sticking with svn.
>
> As a middle ground I'd like to propose we ask Infra to create a git
> mirror of the svn repo.
>
> For those who favour git:
> The git mirror would be read-only but it would be possible to:
> - clone the git mirror
> - make changes in git
> - use git-svn to commit those changes back to svn
> - then the mirror automatically replicates them back to git
>
> For those who favour svn there would be no change.
>
> If there is agreement on this approach, I volunteer to contact infra to
> get it set up.
>
> Thoughts?
>

My personal preference is to move to Git!

Martin


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

Re: Removing the APR connector

[Martin Grigorov]

On Tue, Sep 29, 2020 at 2:31 PM Mark Thomas  wrote:

> All,
>
> Removing the APR connector (HTTP and AJP) is currently on the TODO list
> for Tomcat 10.0.x (i.e. the current development branch).
>
> I am wondering whether we are still happy with this plan as we have had
> a few 10.0.x milestone releases and we haven't made any efforts to
> remove the APR connector.
>
> I'm happy to remove APR from 10.0.x but I am equally happy postponing
> this to a later release if necessary.
>
> We'd still need Tomcat Native support to enable the use of OpenSSL with
> NIO and NIO2. I am only thinking of removing the APR based HTTP and AJP
> connectors (with associated plumbing) and possibly some of the
> org.apache.tomcat.jni package.
>
> Thoughts?
>

+1 to remove!


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

Re: ApacheCon @ Home Tomcat Track Schedule

[Martin Grigorov]

Hi,

A friendly reminder: the conference already started and the Tomcat sessions
will start in less than 6 hours from now!

On Fri, Aug 14, 2020 at 6:49 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm happy to announce that the Apache Tomcat track schedule has been
> posted for ApacheCon @ Home, our virtual conference to replace
> "ApacheCon North America 2020". If you use social media to discuss
> this event, please use #ACAH2020 and tag @apachecon.
>
> You can find the schedule here, as well as links to the other 27 (!)
> tracks that will be held at the conference:
> https://www.apachecon.com/acah2020/tracks/tomcat.html
>
> If you'd like to register (zero cost!), you can do that here:
> https://hopin.to/events/apachecon-home
>
> Note that some tracks are happening at different times; please check
> the times for each presentation in each track for your timezone.
>
> I hope to "see" many of you at the conference this year.
>
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl82sk4ACgkQHPApP6U8
> pFiypw/+M6Sz1wUtXk6A1CO5Lbz0jMU6/Ky53+zCb3skp4wNSVXaUuJ4xCb2hWg/
> cl8KkgP6N0e4stwB9M/XbL403Ic6NGYBvS2ZcMmm2rJqO99t5UvTpUY/DzzNwaXf
> d5z2h8p+aSU4ph6UZavi/Tydxa83WxQSRDuRww61xs6yHv7myELicv+fATJGY4fb
> slMLJt2Hzmh9C7t7+xkQDTpEUNz+oIV2yyQwuvkAS6WMHJbrqAkuqgQq6eAYm5Qc
> 79pb4e/G+E71Sr2AzeuFSpLQCUzYIyOkXFoLfr9L6Wb7iwwiu5bFP7+WAbJvI200
> tYjokn9NdZOwf4P3uY0xfCk3aq2jI9DZAcYjh7n0nhHCN+8vrqodQ/CZtoBYNQR5
> /HwMgszCyimfkegwb3CcuayFUko/Oa+klSOuh9XqFM8jb9XobyXx7dprZk3Ly0Kq
> oL/7h3+uBvz4rzR6FVdcuJ7stY4JpBhG+ZsjkiMktYcZovD9IP20RIE+omvqc0/S
> L1d/3XyRk3fM6JuQq2Y9yqTcgsbBrzEtcwIAOv2r9TQaRrwSbO2nTUiPVx8RTwQ4
> dtE60qVUvZ933I8aV4akqGkeUSBbxiv0WSfpV3T2F1latoqfEmlzueJNWrdgwXFC
> 8hSVyx29AsTiDGAXAswzxQDyNFlaY9zZZKi467doMvhJBGzTYfk=
> =pleB
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [tomcat] branch master updated (519f6f8 -> 18e0e3f)

[Martin Grigorov]

On Mon, Sep 28, 2020 at 11:59 AM Mark Thomas  wrote:

> On 28/09/2020 09:13, Martin Grigorov wrote:
>
> 
>
> > Good news: there are no regressions!
>
> So far, so good.
>
> > Neutral news: there are no performance improvements according to my
> tests.
> > I use
> >
> https://github.com/martin-g/http2-server-perf-tests/blob/128f24e27ef96ee31740db4130855bea2c021793/java/tomcat/src/main/java/info/mgsolutions/tomcat/Main.java
> > to test HTTP2, h2c, HTTP and HTTPS
> > HTTP: 28K reqs/s
> > H2C: 14K reqs/s
> > HTTP2: 11K req/s
> >
> > I still use Vegeta as a test client + my patch to ignore CANCEL errors
>
> You might want to try without that CANCEL error patch. The Tomcat code
> should be more robust against that sort of error now as it retains state
> for at least 5x max concurrent streams now.
>

Confirmed!
Now Tomcat does not complain about the late CANCEL!


>
> I see slightly different figures when testing locally with Vegeta:
>
> HTTP:   30.5k req/s
> HTTPS:  18.0k req/s
> h2c:20.7k req/s
> h2: 17.2k req/s
>
> There are a couple of unexpected things there:
> - large drop from HTTP to HTTPS
> - similar HTTP figures for your test and mine but very different h2/h2c
>   figures
>
> Given how unrepresentative local testing is I'm not entirely surprised.
>
> I'm not planning on spending any time digging into these differences.
>

Thank you for the improvements !


>
> Running load tests with a profiler shows the biggest bottleneck is
> around I/O. There might be some small gains to be made with better
> buffering to reduce the number of network writes but implementing that
> change is more complex for the async HTTP/2 implementation.
>

Yes, I also see only network IO operations in the profiler now.


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

Re: [tomcat] branch master updated (519f6f8 -> 18e0e3f)

[Martin Grigorov]

On Mon, Sep 28, 2020 at 9:28 AM Martin Grigorov 
wrote:

> Hi,
>
> On Fri, Sep 25, 2020 at 4:40 PM Mark Thomas  wrote:
>
>> On 25/09/2020 14:34, ma...@apache.org wrote:
>> > This is an automated email from the ASF dual-hosted git repository.
>> >
>> > markt pushed a change to branch master
>> > in repository https://gitbox.apache.org/repos/asf/tomcat.git.
>> >
>> >
>> > from 519f6f8  Fix a typo in changelog
>> >  new ee25710  Reduce memory footprint of closed http/2 streams
>> >  new f6e656e  Reduce memory footprint of closed http/2 streams
>> >  new 0f66705  Reduce memory footprint of closed http/2 streams
>> >  new fa6df26  Reduce memory footprint of closed http/2 streams
>> >  new 9ee7d6a  Reduce memory footprint of closed http/2 streams
>> >  new 30df6a0  Reduce memory footprint of closed http/2 streams
>> >  new 0a78ae9  Fully replace Stream with RecycledStream
>> >  new 954cbff  Refactor the pruning so more stream info is retained
>> for longer
>> >  new 18e0e3f  Update changelog
>>
>> All,
>>
>> This set of changes provided multiple improvements to the HTTP/2
>> implementation:
>>
>> 1. The memory used by closed streams is significantly reduced (hopefully
>>without the NPEs triggered by my previous attempt).
>> 2. We retain information on more streams in the priority tree. This
>>enables greater latitude for clients that send frames for streams
>>that have been closed (while not increasing memory).
>> 3. We no longer aggressively prune the priority tree to just active
>>streams (this was causing problems in some usage patterns).
>>
>> My plan is to let this run on the CI for a few days and then - assuming
>> no issues - back-port it early next week.
>>
>
> I will cherry-pick these commits to a branch [1] that I use for testing
> and profiling.
> I'll report back with the results!
>

Good news: there are no regressions!
Neutral news: there are no performance improvements according to my tests.
I use
https://github.com/martin-g/http2-server-perf-tests/blob/128f24e27ef96ee31740db4130855bea2c021793/java/tomcat/src/main/java/info/mgsolutions/tomcat/Main.java
to test HTTP2, h2c, HTTP and HTTPS
HTTP: 28K reqs/s
H2C: 14K reqs/s
HTTP2: 11K req/s

I still use Vegeta as a test client + my patch to ignore CANCEL errors
because I haven't found a better load client.
I've reported a bug against Golang net package:
https://github.com/golang/go/issues/41570


>
> 1.
> https://github.com/martin-g/tomcat/tree/http2/use-navigateable-map-for-http2-streams
>
>
>
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

Re: [tomcat] 08/09: Refactor the pruning so more stream info is retained for longer

[Martin Grigorov]

Hi Mark,

On Fri, Sep 25, 2020 at 4:35 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.git
>
> commit 954cbffa73efe6e546a07c84ade97a3b9b38a893
> Author: Mark Thomas 
> AuthorDate: Fri Sep 25 14:14:06 2020 +0100
>
> Refactor the pruning so more stream info is retained for longer
>
> The memory impact of this is mitigated by the previous changes to
> replace closed Stream instances with RecycledStream instances.
> ---
>  .../apache/coyote/http2/Http2UpgradeHandler.java   | 89
> --
>  1 file changed, 49 insertions(+), 40 deletions(-)
>
> diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> index a023fe0..49115d3 100644
> --- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> +++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
> @@ -30,6 +30,7 @@ import java.util.TreeSet;
>  import java.util.concurrent.ConcurrentHashMap;
>  import java.util.concurrent.ConcurrentLinkedQueue;
>  import java.util.concurrent.ConcurrentMap;
> +import java.util.concurrent.ConcurrentSkipListMap;
>  import java.util.concurrent.atomic.AtomicInteger;
>  import java.util.concurrent.atomic.AtomicLong;
>  import java.util.concurrent.atomic.AtomicReference;
> @@ -123,7 +124,7 @@ class Http2UpgradeHandler extends AbstractStream
> implements InternalHttpUpgradeH
>  private HpackDecoder hpackDecoder;
>  private HpackEncoder hpackEncoder;
>
> -private final ConcurrentMap streams =
> new ConcurrentHashMap<>();
> +private final ConcurrentMap streams =
> new ConcurrentSkipListMap<>();
>

In my branch I also moved to ConcurrentSkipListMap:
https://github.com/martin-g/tomcat/commit/08cca44fbb9bd05e35c5655ff7d6ea9781bc28fa
I did it because #closeIdleStreams() was appearing in the profiler. With
this change it is no more in the profiler results!
Now the only drawback is that streams.size() (called
in org.apache.coyote.http2.Http2UpgradeHandler#pruneClosedStreams()) is no
longer a constant-time operation.


>  protected final AtomicInteger activeRemoteStreamCount = new
> AtomicInteger(0);
>  // Start at -1 so the 'add 2' logic in closeIdleStreams() works
>  private volatile int maxActiveRemoteStreamId = -1;
> @@ -1207,78 +1208,86 @@ class Http2UpgradeHandler extends AbstractStream
> implements InternalHttpUpgradeH
>  // 2. Completed streams used for a request with children
>  // 3. Closed final streams
>  //
> -// Steps 1 and 2 will always be completed.
> -// Step 3 will be completed to the minimum extent necessary to
> bring the
> -// total number of streams under the limit.
> +// The pruning halts as soon as enough streams have been pruned.
>
>  // Use these sets to track the different classes of streams
> -TreeSet candidatesStepOne = new TreeSet<>();
>  TreeSet candidatesStepTwo = new TreeSet<>();
>  TreeSet candidatesStepThree = new TreeSet<>();
>
> -for (Entry entry :
> streams.entrySet()) {
> -AbstractNonZeroStream stream = entry.getValue();
> +// Step 1
> +// Iterator is in key order so we automatically have the oldest
> streams
> +// first
> +for (AbstractNonZeroStream stream : streams.values()) {
>  // Never remove active streams
>  if (stream instanceof Stream && ((Stream) stream).isActive())
> {
>  continue;
>  }
>
> -final Integer streamIdentifier = entry.getKey();
>  if (stream.isClosedFinal()) {
>  // This stream went from IDLE to CLOSED and is likely to
> have
>  // been created by the client as part of the priority
> tree.
> -candidatesStepThree.add(streamIdentifier);
> +// Candidate for steo 3.
> +candidatesStepThree.add(stream.getIdentifier());
>  } else if (stream.getChildStreams().size() == 0) {
> -// Closed, no children
> -candidatesStepOne.add(streamIdentifier);
> -} else {
> -// Closed, with children
> -candidatesStepTwo.add(streamIdentifier);
> -}
> -}
> -
> -// Process the step one list
> -for (Integer streamIdToRemove : candidatesStepOne) {
> -// Remove this childless stream
> -AbstractNonZeroStream removedStream =
> streams.remove(streamIdToRemove);
> -removedStream.detachFromParent();
> -toClose--;
> -if (log.isDebugEnabled()) {
> -log.debug(sm.getString("upgradeHandler.pruned",
> connectionId, streamIdToRemove));
> -}
> -
> -// Did this make the parent childless?
> -AbstractStream parent = removedStream.getParentStream();

Re: [tomcat] branch master updated (519f6f8 -> 18e0e3f)

[Martin Grigorov]

Hi,

On Fri, Sep 25, 2020 at 4:40 PM Mark Thomas  wrote:

> On 25/09/2020 14:34, ma...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a change to branch master
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git.
> >
> >
> > from 519f6f8  Fix a typo in changelog
> >  new ee25710  Reduce memory footprint of closed http/2 streams
> >  new f6e656e  Reduce memory footprint of closed http/2 streams
> >  new 0f66705  Reduce memory footprint of closed http/2 streams
> >  new fa6df26  Reduce memory footprint of closed http/2 streams
> >  new 9ee7d6a  Reduce memory footprint of closed http/2 streams
> >  new 30df6a0  Reduce memory footprint of closed http/2 streams
> >  new 0a78ae9  Fully replace Stream with RecycledStream
> >  new 954cbff  Refactor the pruning so more stream info is retained
> for longer
> >  new 18e0e3f  Update changelog
>
> All,
>
> This set of changes provided multiple improvements to the HTTP/2
> implementation:
>
> 1. The memory used by closed streams is significantly reduced (hopefully
>without the NPEs triggered by my previous attempt).
> 2. We retain information on more streams in the priority tree. This
>enables greater latitude for clients that send frames for streams
>that have been closed (while not increasing memory).
> 3. We no longer aggressively prune the priority tree to just active
>streams (this was causing problems in some usage patterns).
>
> My plan is to let this run on the CI for a few days and then - assuming
> no issues - back-port it early next week.
>

I will cherry-pick these commits to a branch [1] that I use for testing and
profiling.
I'll report back with the results!

1.
https://github.com/martin-g/tomcat/tree/http2/use-navigateable-map-for-http2-streams



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

Re: [tomcat] 01/02: Small optimizations in HpackEncoder

[Martin Grigorov]

On Thu, Sep 24, 2020 at 1:50 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> mgrigorov pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
> commit d2ed8ffc75c5e3b425888b456ffc51036d94ac39
> Author: Martin Tzvetanov Grigorov 
> AuthorDate: Thu Sep 24 13:42:18 2020 +0300
>
> Small optimizations in HpackEncoder
>
> 1) Use switch(String) instead of series of String.equals() calls. The
> switch uses String.hashCode() and falls back to .equals() only if there are
> cases with the same hash code.
> 2) Reduce memory allocations: no need to Map.Entry since the key is
> never used
>

this should read: ... no need to *create* Map.Entry


> ---
>  java/org/apache/coyote/http2/HpackEncoder.java | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/java/org/apache/coyote/http2/HpackEncoder.java
> b/java/org/apache/coyote/http2/HpackEncoder.java
> index dda5714..ae81033 100644
> --- a/java/org/apache/coyote/http2/HpackEncoder.java
> +++ b/java/org/apache/coyote/http2/HpackEncoder.java
> @@ -44,7 +44,13 @@ class HpackEncoder {
>  public boolean shouldUseIndexing(String headerName, String value)
> {
>  //content length and date change all the time
>  //no need to index them, or they will churn the table
> -return !headerName.equals("content-length") &&
> !headerName.equals("date");
> +switch (headerName) {
> +case "content-length":
> +case "date":
> +return false;
> +default:
> +return true;
> +}
>  }
>
>  @Override
> @@ -258,8 +264,8 @@ class HpackEncoder {
>  private void preventPositionRollover() {
>  //if the position counter is about to roll over we iterate all
> the table entries
>  //and set their position to their actual position
> -for (Map.Entry> entry :
> dynamicTable.entrySet()) {
> -for (TableEntry t : entry.getValue()) {
> +for (List tableEntries : dynamicTable.values()) {
> +for (TableEntry t : tableEntries) {
>  t.position = t.getPosition();
>  }
>  }
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Application-accesible Executors

[Martin Grigorov]

Hi Chris,

On Fri, Sep 18, 2020 at 7:10 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I've recently been thinking about application uses of servlet-async and
> Websocket for long-running operations, or really for any interactions
> where you want to allow the request-processing thread to go back into
> the pool, but the application is still doing useful things and therefore
> needs its own thread.
>
> I'm thinking of something like SwingUtilities.invokeLater, though that
> does something very specific that is AWT-related, of course.
>
> I don't believe there is a (JavaEE/JakartaEE) standard for this, so I'm
> interested in what others think might be a good idea from a Tomcat
> standpoint.
>

I haven't used Java EE since version 5 but I do remember it having such
utilities:
https://docs.oracle.com/javaee/7/tutorial/concurrency-utilities.htm


>
>
> It's fairly easy to do something like this in one's own web application,
> maybe using a ServletContextListener:
>
> public class ExecutorProvider
>   implements ServletContextListener
> {
>   public static final EXECUTOR_SERVICE_KEY = "executor-service";
>
>   private ExecutorService _svc;
>
>   public void contextInitialized(ServletContext ctx) {
> _svc = Executors.newFixedThreadPool(10); // ?
>
> ctx.setAttribute(EXECUTOR_SERVICE_KEY, _svc);
>   }
>
>   public void contextDestroyed(ServletContext ctx) {
> ctx.removeAttribute(EXECUTOR_SERVICE_KEY);
> _svc.shutdown();
>   }
> }
>
> Then in a servlet, etc. you could:
>
>
> ((ExecutorService)ctx.getAttribute(ExecutorProvider.EXECUTOR_SERVICE_KEY)).submit(new
> Runnable() {
> public void run() {
> // your code goes here
> }
> });
>
> I'm wondering if there is scope here for Tomcat to provide this kind of
> service for applications that want to opt-into one. Maybe the above is
> so trivial as to not be worth it at all. But maybe it would be a nice
>

I agree - it is trivial.
But also: does it work for everyone's use case ?
Some will need a fixed pool for CPU bound tasks, others will need a cached
pool for IO bound tasks, and others may need a scheduled pool ... And then
you'll need to provide a way to name the threads ...
Of course you can introduce pools of all types but is it easier to define
them in XML (server.xml, context.xml) or in Java code (as you did above) ?

My 2c
Martin


> service to provide to web applications, or maybe across multiple web
> applications in some kind of group. Or it might survive context restarts
> for some reason.
>
> Having this provided by Tomcat would allow admins to maybe override the
> sizes of the thread pools and other details that the application then
> wouldn't need to worry about.
>
> It might even tie-into Tomcat's utility-executor if that makes any sense
> 0-- though we'd have to make sure it executes in the right ClassLoader
> and/or security context.
>
> Any thoughts on this? Or is it really such a trivial thing as to not
> really be useful to anyone. Maybe simply providing a
> ServletContextListener class like the one above (with obvious robustness
> improvements) that anyone could configure for their own application
> would be sufficient/useful to users.
>
> -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 7.0.106

[Martin Grigorov]

On Wed, Sep 16, 2020 at 2:26 PM Violeta Georgieva 
wrote:

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

Tested with Apache Wicket 9.x examples.

Regards,
Martin


>
> Regards,
> Violeta
>

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

[Martin Grigorov]

Hi Rory,

I've just run the build and tests of Tomcat 9.0.x with JDK 15+36-1562
and 16-ea+15-631 on x86_64 and aarch64. No regressions found!

Regards,
Martin

On Tue, Sep 15, 2020 at 5:52 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> **Release Announcement: General Availability of Java 15 / JDK 15 [1]
> **
>
>   * JDK 15, the reference implementation of Java 15, is now Generally
> Available.
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> http://jdk.java.net/15/
>   * JDK 15 Release notes
> <
> https://www.oracle.com/java/technologies/javase/15-relnote-issues.html>
>
> JDK 15 includes fourteen features [2]:
>
>   * JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
> 
>   * JEP 360: Sealed Classes (Preview) 
>   * JEP 371: Hidden Classes 
>   * JEP 372: Remove the Nashorn JavaScript Engine
> 
>   * JEP 373: Reimplement the Legacy DatagramSocket API
> 
>   * JEP 374: Disable and Deprecate Biased Locking
> 
>   * JEP 375: Pattern Matching for instanceof (Second Preview)
> 
>   * JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
> 
>   * JEP 378: Text Blocks 
>   * JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
> 
>   * JEP 381: Remove the Solaris and SPARC Ports
> 
>   * JEP 383: Foreign-Memory Access API (Second Incubator)
> 
>   * JEP 384: Records (Second Preview) 
>   * JEP 385: Deprecate RMI Activation for Removal
> 
>
> Thanks to everyone who contributed to JDK 15, whether by creating
> features or enhancements, logging  bugs, or downloading and testing the
> early-access builds.
>
> OpenJDK 16 Early Access build 15**is now available at
> http://jdk.java.net/16
>
>   * JEPs integrated to JDK 16:
>   o JEP 347: Enable C++14 Language Features
> 
>   o JEP 357: Migrate from Mercurial to Git
> 
>   o JEP 369: Migrate to GitHub 
>
>   * Release Notes are available at http://jdk.java.net/16/release-notes
>
> **
>
>   * Significant changes since the last availability email:
>   o Build 15
>   + JDK-8244090: public lookup should find public members of
> public exported types (Reported by Eclipse Jetty)
>   + JDK-8250968: Symlinks attributes not preserved when using
> jarsigner on zip files
>   o Build 14
>   + JDK-8189744: Deprecate the JDK-specific API for setting
> socket options, jdk.net.Sockets
>   + JDK-8241003: Deprecate "denigrated" java.security.cert APIs
> that represent DNs as Principal or String objects
>   + JDK-8245462: The default HttpClient implementation returns
> cancelable futures
>
>
> *__*
> Rgds,Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004733.html
> [2] https://openjdk.java.net/projects/jdk/15/
> --
>
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [tomcat] branch master updated: Replace "".equals(a) with a.isEmpty()

[Martin Grigorov]

On Tue, Sep 15, 2020 at 1:52 PM Mark Thomas  wrote:

> On 15/09/2020 10:21, mgrigo...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > mgrigorov 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 f550254  Replace "".equals(a) with a.isEmpty()
> >  new 6053839  Merge pull request #356 from
> martin-g/improvement/use-string-isempty
> > f550254 is described below
> >
> > commit f550254bb15e1b0cc50225aee1c3fb1ed034f552
> > Author: Martin Tzvetanov Grigorov 
> > AuthorDate: Thu Sep 10 12:52:11 2020 +0300
> >
> > Replace "".equals(a) with a.isEmpty()
>
> How sure are you that none of these will introduce the possibility of a
> NullPointerException?
>

Most of them have explicit checks for null/non-null.
For the others I have checked whether null is possible. If it was possible
then it'd have failed a few lines later even with the old code.
But yes, it is still possible that a regression is introduced somewhere.
That's the reason why I suggested this PR in the beginning of the new
release cycle - now we have 1 month to fix such regressions. And still, the
unit tests and our test apps do not cover all possible cases ...
If you have concerns about some part of the change let me know and I will
either improve it or revert the change!

Martin


>
> Mark
>
> >
> >
> https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416
> > Proposal for JDK: https://github.com/openjdk/jdk/pull/29
> > ---
> >  .../apache/catalina/ant/jmx/JMXAccessorCondition.java  |  2 +-
> >  .../apache/catalina/ant/jmx/JMXAccessorCreateTask.java |  2 +-
> >  java/org/apache/catalina/ant/jmx/JMXAccessorTask.java  |  2 +-
> >  java/org/apache/catalina/core/ApplicationContext.java  |  2 +-
> >  java/org/apache/catalina/core/StandardContext.java |  2 +-
> >  java/org/apache/catalina/core/StandardEngine.java  |  2 +-
> >  java/org/apache/catalina/filters/WebdavFixFilter.java  |  2 +-
> >  java/org/apache/catalina/ha/backend/TcpSender.java |  2 +-
> >  .../catalina/ha/session/JvmRouteBinderValve.java   |  2 +-
> >  .../apache/catalina/manager/HTMLManagerServlet.java|  9 +
> >  java/org/apache/catalina/manager/ManagerServlet.java   |  2 +-
> >  .../catalina/manager/host/HostManagerServlet.java  |  2 +-
> >  java/org/apache/catalina/realm/RealmBase.java  |  2 +-
> >  java/org/apache/catalina/servlets/CGIServlet.java  |  8 
> >  java/org/apache/catalina/session/JDBCStore.java|  2 +-
> >  .../org/apache/catalina/storeconfig/StoreRegistry.java |  2 +-
> >  java/org/apache/catalina/util/ContextName.java | 18
> +-
> >  java/org/apache/el/MethodExpressionImpl.java   |  2 +-
> >  java/org/apache/el/MethodExpressionLiteral.java|  2 +-
> >  java/org/apache/el/ValueExpressionImpl.java|  2 +-
> >  java/org/apache/el/ValueExpressionLiteral.java |  2 +-
> >  java/org/apache/el/lang/ELSupport.java |  7 ---
> >  java/org/apache/el/lang/FunctionMapperImpl.java|  2 +-
> >  java/org/apache/el/util/ReflectionUtil.java|  2 +-
> >  java/org/apache/jasper/JspC.java   |  2 +-
> >  java/org/apache/jasper/compiler/Generator.java |  2 +-
> >  java/org/apache/jasper/compiler/Validator.java |  2 +-
> >  .../apache/tomcat/util/digester/SetPropertiesRule.java |  2 +-
> >  java/org/apache/tomcat/util/net/SSLUtilBase.java   |  2 +-
> >  .../apache/tomcat/websocket/WsWebSocketContainer.java  |  3 ++-
> >  30 files changed, 49 insertions(+), 46 deletions(-)
> >
> > diff --git a/java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
> b/java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
> > index b009684..4ac07c3 100644
> > --- a/java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
> > +++ b/java/org/apache/catalina/ant/jmx/JMXAccessorCondition.java
> > @@ -149,7 +149,7 @@ public class JMXAccessorCondition extends
> JMXAccessorConditionBase {
> >   * @return true if there is no if condition, or the named property
> exists
> >   */
> >  protected boolean testIfCondition() {
> > -if (ifCondition == null || "".equals(ifCondition)) {
> > +if (ifCondition == null || ifCondition.isEmpty()) {
> >  return true;
> >  }
> >  return getProject().getProperty(ifCondition) != null;
> > diff --git a/java/org/apache/catalina/ant/jmx/JMXAccessorCreateTask.java
> b/java/org/apache/catalina/ant/jmx/JMXAccessorCreateTask.java
> > index 28aab6c..558a258 100644
> > --- a/java/org/apache/catalina/ant/jmx/JMXAccessorCreateTask.java
> > +++ b/java/org/apache/catalina/ant/jmx/JMXAccessorCreateTask.java
> > @@ -154,7 +154,7 @@ public class JMXAccessorCreateTask extends
> JMXAccessorTask {
> > }
> > 

Re: Deprecated JDBCRealm

[Martin Grigorov]

On Mon, Sep 14, 2020 at 9:53 PM Mark Thomas  wrote:

> All,
>
> I'd like to proposed the following:
> - Deprecated the JDBCRealm in 7.0.x, 8.5.x and 9.0.x
> - Remove the JDBCRealm in 10.0.x
>
> The reasons for this are:
> - The JDBCRealm is single threaded
> - The DataSourceRealm is a better solution
>
> Thoughts?
>

+1


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

Re: [tomcat] branch master updated: Improve the quality of the health check

[Martin Grigorov]

Hi Remy,

I'm not sure whether GitHub notified you about my comment on this commit:
https://github.com/apache/tomcat/commit/2ff7bba79946a3716b136b0752c9fe7126b50499#r42227542

On Fri, Sep 11, 2020 at 2:27 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 2ff7bba  Improve the quality of the health check
> 2ff7bba is described below
>
> commit 2ff7bba79946a3716b136b0752c9fe7126b50499
> Author: remm 
> AuthorDate: Fri Sep 11 13:26:44 2020 +0200
>
> Improve the quality of the health check
>
> The valve will check if its associated container and all its children
> are available. Will return down if any is not available.
> ---
>  .../apache/catalina/valves/HealthCheckValve.java   | 43
> +-
>  webapps/docs/changelog.xml |  8 
>  webapps/docs/config/valve.xml  | 15 +---
>  3 files changed, 60 insertions(+), 6 deletions(-)
>
> diff --git a/java/org/apache/catalina/valves/HealthCheckValve.java
> b/java/org/apache/catalina/valves/HealthCheckValve.java
> index be9c487..c111b3b 100644
> --- a/java/org/apache/catalina/valves/HealthCheckValve.java
> +++ b/java/org/apache/catalina/valves/HealthCheckValve.java
> @@ -19,11 +19,14 @@ package org.apache.catalina.valves;
>  import java.io.IOException;
>
>  import jakarta.servlet.ServletException;
> +import jakarta.servlet.http.HttpServletResponse;
>
> +import org.apache.catalina.Container;
>  import org.apache.catalina.Context;
>  import org.apache.catalina.LifecycleException;
>  import org.apache.catalina.connector.Request;
>  import org.apache.catalina.connector.Response;
> +import org.apache.catalina.util.LifecycleBase;
>  import org.apache.tomcat.util.buf.MessageBytes;
>
>
> @@ -38,6 +41,12 @@ public class HealthCheckValve extends ValveBase {
>  "  \"checks\": []\n" +
>  "}";
>
> +private static final String DOWN =
> +"{\n" +
> +"  \"status\": \"DOWN\",\n" +
> +"  \"checks\": []\n" +
> +"}";
> +
>  private String path = "/health";
>
>  /**
> @@ -45,6 +54,11 @@ public class HealthCheckValve extends ValveBase {
>   */
>  protected boolean context = false;
>
> +/**
> + * Check if all child containers are available.
> + */
> +protected boolean checkContainersAvailable = true;
> +
>  public HealthCheckValve() {
>  super(true);
>  }
> @@ -57,6 +71,14 @@ public class HealthCheckValve extends ValveBase {
>  this.path = path;
>  }
>
> +public boolean getCheckContainersAvailable() {
> +return this.checkContainersAvailable;
> +}
> +
> +public void setCheckContainersAvailable(boolean
> checkContainersAvailable) {
> +this.checkContainersAvailable = checkContainersAvailable;
> +}
> +
>  @Override
>  protected synchronized void startInternal() throws LifecycleException
> {
>  super.startInternal();
> @@ -74,9 +96,28 @@ public class HealthCheckValve extends ValveBase {
>  context ? request.getRequestPathMB() :
> request.getDecodedRequestURIMB();
>  if (urlMB.equals(path)) {
>  response.setContentType("application/json");
> -response.getOutputStream().print(UP);
> +if (isAvailable(getContainer())) {
> +response.getOutputStream().print(UP);
> +} else {
> +
> response.setStatus(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
> +response.getOutputStream().print(DOWN);
> +}
>  } else {
>  getNext().invoke(request, response);
>  }
>  }
> +
> +protected boolean isAvailable(Container container) {
> +for (Container child : container.findChildren()) {
> +if (!isAvailable(child)) {
> +return false;
> +}
> +}
> +if (container instanceof LifecycleBase) {
> +return ((LifecycleBase) container).getState().isAvailable();
> +} else {
> +return true;
> +}
> +}
> +
>  }
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 737bf79..d8695c1 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -45,6 +45,14 @@
>issues do not "pop up" wrt. others).
>  -->
>  
> +  
> +
> +  
> +The health check valve will now check the state of its associated
> +containers to report availability. (remm)
> +  
> +
> +  
>  
>  
>
> diff --git a/webapps/docs/config/valve.xml b/webapps/docs/config/valve.xml
> index 557ee32..3111fce 100644
> --- a/webapps/docs/config/valve.xml
> +++ b/webapps/docs/config/valve.xml
> @@ -2236,10 +2236,7 @@
>
>
>  The Health Check Valve responds to
> -cloud orche

Re: [VOTE] Release Apache Tomcat 8.5.58

[Martin Grigorov]

On Fri, Sep 11, 2020 at 1:10 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.58 release is now available for voting.
>
> The notable changes compared to the 8.5.57 release are:
>
> - For requests containing the Expect: 100-continue header, optional
>   support has been added to delay sending an intermediate 100 status
>   response until the servlet reads the request body, allowing the
>   servlet the opportunity to respond without asking for the request
>   body. Based on a pull request by malaysf.
>
> - Add support for a read idle timeout and a write idle timeout to the
>   WebSocket session via custom properties in the user properties
>   instance associated with the session. Based on a pull request by
>   sakshamverma.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.25
>
> 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.58/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1278/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.58
> 2fe65bc24e48ee5ea079937e6a73576339f871ce
>
> The proposed 8.5.58 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.58
>

Tested with Apache Wicket 9.x examples app.

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

[Martin Grigorov]

On Thu, Sep 10, 2020 at 12:03 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.38 release is now available for voting.
>
> The notable changes compared to the 9.0.37 release are:
>
> - For requests containing the Expect: 100-continue header, optional
>   support has been added to delay sending an intermediate 100 status
>   response until the servlet reads the request body, allowing the
>   servlet the opportunity to respond without asking for the request
>   body. Based on a pull request by malaysf.
>
> - Add support for a read idle timeout and a write idle timeout to the
>   WebSocket session via custom properties in the user properties
>   instance associated with the session. Based on a pull request by
>   sakshamverma.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.25
>
> 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.38/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1277/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.38
> 48b6a87171e502cc0becbb4c96e2266de4e805e7
>
> The proposed 9.0.38 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.38
>

Tested with Apache Wicket 9.x examples app.

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

[Martin Grigorov]

On Wed, Sep 9, 2020 at 5:57 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M8 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-M7 are:
>
> - For requests containing the Expect: 100-continue header, optional
>   support has been added to delay sending an intermediate 100 status
>   response until the servlet reads the request body, allowing the
>   servlet the opportunity to respond without asking for the request
>   body. Based on a pull request by malaysf.
>
> - Add support for a read idle timeout and a write idle timeout to the
>   WebSocket session via custom properties in the user properties
>   instance associated with the session. Based on a pull request by
>   sakshamverma.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.25
>
> 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.0-M8/
> The Maven staging repo is:
>
> https://repository.apache.org/content/repositories/orgapachetomcatrepo-1276/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M8
> b3f5e0d88336d81a61a767fc10ab06930c9587ee
>
> The proposed 10.0.0-M8 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M8
>

Tested with Apache Wicket examples app (migrated
with tomcat-jakartaee-migration tool).

Regards,
Martin


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

Re: Plans for Servlet 5.1

[Martin Grigorov]

Hi,

On Thu, Sep 10, 2020 at 11:17 AM Mark Thomas  wrote:

> Hi all,
>
> It looks like at least one of the specs Tomcat implements, Servlets, is
> going to have at least one release between Jakarta EE 9 / Servlet 5.0 /
> Tomcat 10.0 and Jakarta EE 10/ Servlet 6.0 / Tomcat 10.1
>
> The current plan is for Servlet 5.1 to add same site cookie
> configuration and pick up any other low hanging fruit (mostly clean-up &
> clarification) from the issues list.
>
> I'm currently trying to figure out what this means in terms of Tomcat
> releases. It may be that other specs do something similar. If enough
> specs do that, it may turn into a relatively quick Jakarta EE 10.
>
> My current thinking is treat such releases the way we used to treat
> maintenance releases of the specs. That would mean updating Tomcat to
> the 5.1 release once available but not change in major or minor version.
> Another way of looking at it is that Tomcat 10.0.x will support the
> latest released version of Servlet 5.x and Tomcat 10.1.x will support
> the latest released version of Servlet 6.x.
>
>
Sounds good!


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

Re: [tomcat] branch master updated: Change forcedRemainingCapacity from Integer to int

[Martin Grigorov]

Hi Chris,

On Thu, Aug 27, 2020 at 8:51 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 8/27/20 07:55, mgrigo...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git
> > repository.
> >
> > mgrigorov 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 2cef8f1  Change forcedRemainingCapacity from Integer to
> > int 2cef8f1 is described below
> >
> > commit 2cef8f18dee7b7bca3d03b3301fbe8e733e728fa Author: Martin
> > Tzvetanov Grigorov  AuthorDate: Tue Aug 25
> > 14:36:23 2020 +0300
> >
> > Change forcedRemainingCapacity from Integer to int
> >
> > No need to create object (or use Integer cache) and cast it to
> > primitive int. 'forcedRemainingCapacity' can do its job with a
> > primitive int, since Queue's capacity cannot be negative value ---
> > java/org/apache/tomcat/util/threads/TaskQueue.java| 15
> > ++-
> > .../apache/tomcat/util/threads/ThreadPoolExecutor.java|  4
> > ++-- 2 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/java/org/apache/tomcat/util/threads/TaskQueue.java
> > b/java/org/apache/tomcat/util/threads/TaskQueue.java index
> > 87c93a9..35f1d89 100644 ---
> > a/java/org/apache/tomcat/util/threads/TaskQueue.java +++
> > b/java/org/apache/tomcat/util/threads/TaskQueue.java @@ -35,12
> > +35,13 @@ public class TaskQueue extends
> > LinkedBlockingQueue { private static final long
> > serialVersionUID = 1L; protected static final StringManager sm =
> > StringManager .getManager("org.apache.tomcat.util.threads.res"); +
> > private static final int DEFAULT_FORCED_REMAINING_CAPACITY = -1;
> >
> > private transient volatile ThreadPoolExecutor parent = null;
> >
> > // No need to be volatile. This is written and read in a single
> > thread -// (when stopping a context and firing the  listeners)
> > -private Integer forcedRemainingCapacity = null; +// (when
> > stopping a context and firing the listeners) +private int
> > forcedRemainingCapacity = -1;
> >
> > public TaskQueue() { super(); @@ -109,18 +110,22 @@ public class
> > TaskQueue extends LinkedBlockingQueue {
> >
> > @Override public int remainingCapacity() { -if
> > (forcedRemainingCapacity != null) { +if
> > (forcedRemainingCapacity > DEFAULT_FORCED_REMAINING_CAPACITY) { //
> > ThreadPoolExecutor.setCorePoolSize checks that //
> > remainingCapacity==0 to allow to interrupt idle threads // I don't
> > see why, but this hack allows to conform to this // "requirement" -
> > return forcedRemainingCapacity.intValue(); +return
> > forcedRemainingCapacity; } return super.remainingCapacity(); }
> >
> > -public void setForcedRemainingCapacity(Integer
> > forcedRemainingCapacity) { +public void
> > setForcedRemainingCapacity(int forcedRemainingCapacity) {
> > this.forcedRemainingCapacity = forcedRemainingCapacity; }
>
> Technically, this could cause a problem for anyone who has binaries
> built against the current code. My guess is that it's very unlikely
> for anyone to be using this code directly so it's not really a big deal.
>

Mark had the same comment in the PR:
https://github.com/apache/tomcat/pull/344#discussion_r476517292
I also think this API is too low level for anyone, even for Spring Boot
people.


>
> But in general, it would be better to add a new set(Integer) method
> which calls the old one and deprecate the old one to be as consistent
> as possible for a point-release.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H8m4ACgkQHPApP6U8
> pFhVwQ/+MyrOmzl8+ragnuyamOlDkGSzhULnJpAnF43OScVBkCfjIbfO3S6ZxZSA
> N/uzXg4c2/zXO/qN1BMCRRHi8/bbb02y54h4jT8h/2OyIdbmlFJhOWAGPpkA7A8D
> GwgSpG5YbEtnpEg0nodtrbWzF1VqKw1x1Wa65tx2wFeSJCVVTlECGlQc1w3sewuV
> o3rpLuupamg/3gOzHlPHaBNYOFY8IEeXtTGmdpTeKmpsh2tbkNvsctcH5IiPvaox
> 8M1mz3IJpK0xb/epBADf7N+hNe+4dT7r+jsDcMyuvRD5CIsLvuKDa2Az8MgamNLQ
> Jd4J1LpxY8PmWsF3EV51DIJmyijxeHEvPu9YXZQ+eR7k4vxFn7CLdfDe3p0SdhKO
> z2m3Sr3BW23tKJBBRQmHLgT7N3ZlnVdoMmQ9jy+vzbb+QWYEQGO3Oc8P1tZbKEjK
> CBKOYmfkBlfB6vcsX/n8pC4gFU6R/V2qKhYG6KiHGjviEoRy0gWLi+5OpD9y+dYS
> u7FjQcB1NrT/kVghOSAkUcvKaIXtB/dM1Se2t/77DnVb7YrjDk97/1Jjbk7rrS6T
> myaXIzsZMgI2d26wtBQSTr+AyyFvNw2h/LnooAc4bIlDJiFju6nSoVqcBPHHZ1mt
> FaIwTzmRSGsSu2EX+S0HEOhHI/kHl5gCP4OVsvZDfBMZN3tKTog=
> =GjCI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Security concern about Tomcat's default value for HSTS MaxAge

[Martin Grigorov]

Hi,

On Tue, Aug 25, 2020 at 9:05 PM Dave Wichers  wrote:

> Per:
> https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#HTTP_Header_Security_Filter
> and
> https://tomcat.apache.org/tomcat-8.5-doc/config/filter.html#HTTP_Header_Security_Filter
>
> they both say:
>
> hstsMaxAgeSeconds  - The max age value that should be used in the HSTS
> header. Negative values will be treated as zero. If not specified, the
> default value of 0 will be used.
>
> So, if a Tomcat user (like I did at first), configures hstsEnabled=true,
> the HSTS response header is set by Tomcat, but with a max age of zero
> (since that is the default).
>
> However, per the HSTS RFC:
> https://tools.ietf.org/html/rfc6797#section-6.1.1 it says:
>
> NOTE:  A max-age value of zero (i.e., "max-age=0") signals the UA to cease
> regarding the host as a Known HSTS Host, including the includeSubDomains
> directive (if asserted for that HSTS Host).
>
> I noticed this problem when I first enabled HSTS on my Tomcat dev
> instance, and then passively scanned my web app with OWASP ZAP (
> https://owasp.org/www-project-zap/). ZAP, correctly I believe, pointed
> out that enabling HSTS with a MaxAge of zero is effectively a no-op. (i.e.,
> does nothing).
>
> If I'm correct, then I think having a default of zero is dangerous and
> should instead default to something useful and effective. Such as one year
> (in seconds) which is what many developers set/configure this value.
> Otherwise, I think turning HSTS ON in Tomcat might be giving people a false
> sense of security because it really doesn't doing anything unless you also
> set MaxAge (which to me isn't intuitive that you should have to do that).
>
> Do you agree with me that this is a problem that should be fixed?
>

I agree that either a better default should be set or Tomcat should report
this misconfiguration somehow to the user!


>
> -Dave
>
>

Re: [VOTE] Release Apache Tomcat Native 1.2.25

[Martin Grigorov]

On Fri, Aug 21, 2020 at 9:22 PM Mark Thomas  wrote:

> Version 1.2.25 includes the following changes compared to 1.2.24
>
> - Improvements to LibreSSL support
>
> - Improvements to HP_UX support
>
> Various other fixes and improvements. See the changelog for details.
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.25 release is
>  [ X ] Stable, go ahead and release
>  [ ] Broken because of ...
>

Everything works fine in my daily builds on x86_64 and aarch64!

Just one minor issue/question:

$ ls -la /home/ubuntu/git/apache/tomcat-native-build/lib
total 3.4M
-rw-r--r-- 1 ubuntu ubuntu 2.2M Aug 25 02:30 libtcnative-1.a
-rwxr-xr-x 1 ubuntu ubuntu 1.1K Aug 25 02:30 libtcnative-1.la*
lrwxrwxrwx 1 ubuntu ubuntu   23 Aug 25 02:30 libtcnative-1.so ->
libtcnative-1.so.0.2.26*
lrwxrwxrwx 1 ubuntu ubuntu   23 Aug 25 02:30 libtcnative-1.so.0 ->
libtcnative-1.so.0.2.26*
-rwxr-xr-x 1 ubuntu ubuntu 1.3M Aug 25 02:30 libtcnative-1.so.0.2.26*

Why .so.0.2.26 ? Shouldn't it be 1.2.26 ?


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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Martin Grigorov]

On Mon, Aug 10, 2020 at 6:46 PM Mark Thomas  wrote:

> Hi all,
>
> I'd like to propose removing all the functional spec pages from the
> documentation web application.
>
> My reasoning for this proposal is, in short, that we aren't using or
> maintaining these pages.
>
> I don't recall any discussion of these docs on the dev list, proposals
> to change them, proposals for additions etc.
>
> There have been changes but going back over the changes from the last 10
> years (and there are very few of them) they each appear to be part of a
> wider global change that is updating something or removing references to
> a feature that has been removed.
>
> Should someone want to revive these pages, or more likely a subset of
> them, they'll always be in the history.
>
> Thoughts?
>

+1


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

Re: Use of "constants" in Manager to generate HTML/CSS content

[Martin Grigorov]

On Tue, Jul 28, 2020, 16:48 Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I was looking at this PR[1] and wondering why we have huge swaths of
> CSS and HTML in a Java source file, instead of using e.g. JSP or some
> other content-generation framework.
>
> I know, I hate JSP, too, but having large blocks of HTML and CSS in
> Java strings is just ... awful.
>
> Also, is there a particular reason we are using embedded CSS in the
> pages instead of an external CSS file?
>
> Ultimately, it would be a good idea to move all CSS and even styles
> into a separate CSS file so we can tighten-up the Content Security
> Policy on the manager app. This can help prevent attacks if there
> happens to be some kind of XSS vulnerability hiding in there somewhere.
>
> Any objections to evicting the CSS to begin with?
>

+1


> Thanks,
> - -chris
>
> [1] https://github.com/apache/tomcat/pull/327
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8gLJsACgkQHPApP6U8
> pFgKCw//WY8p/EBS7sxDYgnV6W4pjeuAuhXv6ierajPH28NfdokIRlU4IfFIUVIE
> Ck98rK9uH98o6QFkWC70MVYV+NbEi4CwrjPhuFV/rEplyqfA+Ijs5g069a1g15On
> fw5V44CK2JBj0AjT4ZtMVWOSxDElHZc3SjZmyaie0pk2zDVxYwSwhoRPtqzms5rH
> zTlu48R14t1O9PLsWGthwdVStAn9WlE7hBLI3yLag/QKUqlOR/a8Fy75mbMma5a9
> cmG8Lh5Jo8a6YzD0q37sdOmKN5d9lZxZkz3x21Cy3v2qcKcaGUcAttAEe9hFKEzh
> I0hOMKYc/2n2aNpMTjIkG86fXzAYB1IIsfiGxlwP/nY6HzJ9XRolD9+kT7LZ/tP3
> 7SKL8rVoKi5SWiH+g3jGifVkxfiHlMhvZikAbC75ngP7mNXZFHPdnF3rvai/cbum
> FWUpLDoW/oTs87v9l071hs+hf2PffvqL/v5AeoMbGf/VDpf/zcuNy0wlB2w6Nxo9
> K8sBVHQGJzIlaR9fqLyYJkJ8kmSb37t7BxPXLuGSCr98uUD8bSy2IwC2IxessXQc
> E+oIyJ0mlPdKU1dh5yFtMzCp4S9olUg4diqOxpToGm2hnmdnkRY3OarC1OU839NC
> Yd5uYA9XoYxBro2oNfB1gCNB5Ve4aLVOV0Q3iKcW83b8jLiNgzY=
> =Z+cI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: JDK 15 is now in the Initial Release Candidate Phase

[Martin Grigorov]

Hi Rory,

The Apache Tomcat build and tests are fine with JDK 15+35-1559 and JDK
16-ea+9-365 both on x86_64 and aarch64 architectures!

Regards,
Martin

On Fri, Aug 7, 2020 at 12:01 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
>
> *Per the JDK 15 schedule  , we are now in the Initial Release Candidate
> Phase *
>
>
> *Please advise if you have any open high priority issues.*
>
>- Schedule for JDK 15
>   - *2020/08/06 Initial Release Candidate*
>   - 2020/08/20 Final Release Candidate
>   - 2020/09/15 General Availability
>
>
>- The overall feature set is frozen.
>   - Per the JDK Release Process [1] we now turn our focus to P1 bugs.
>- Features included in JDK 15:
>   - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
>   
>   - JEP 360: Sealed Classes (Preview)
>   
>   - JEP 371: Hidden Classes 
>   - JEP 372: Remove the Nashorn JavaScript Engine
>   
>   - JEP 373: Reimplement the Legacy DatagramSocket API
>   
>   - JEP 374: Disable and Deprecate Biased Locking
>   
>   - JEP 375: Pattern Matching for instanceof (Second Preview)
>   
>   - JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
>   
>   - JEP 378: Text Blocks 
>   - JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
>   
>   - JEP 381: Remove the Solaris and SPARC Ports
>   
>   - JEP 383: Foreign-Memory Access API (Second Incubator)
>   
>   - JEP 384: Records (Second Preview)
>   
>   - JEP 385: Deprecate RMI Activation for Removal
>   
>
> *JDK 15 **Early Access build 35 *is now available at
> http://jdk.java.net/15
>
>- Release notes
>- http://jdk.java.net/15/release-notes
>- Recent fixes that might be of interest
>   - Build 34
>   - JDK-8246094: [macos] Sound Recording and playback is not working
>
> *JDK 16 Early Access build 9 *is now available at http://jdk.java.net/16
>
>- JEP Candidate
>   - JEP 388: Windows/AArch64 Port 
>- JEPs targeted to JDK 16, so far:
>   - JEP 369: Migrate to GitHub 
>   - JEP 357: Migrate from Mercurial to Git
>   
>   - JEP 347: Enable C++14 Language Features
>   
>
>
>- Recent fixes that might be of interest
>   -
>
>   Build 9
>   - JDK-8243320: Add SSL root certificates to Oracle Root CA program
>  - JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program
>   - Build 8
>   - JDK-8246094: [macos] Sound Recording and playback is not working
>  - JDK-8248655: Support supplementary characters in String case
>  insensitive operations
>   - Build 7
>  - JDK-8246032: Implementation of JEP 347: Enable C++14 Language
>  Features
>
>
> Rgds,Rory
>
> [1] http://openjdk.java.net/jeps/3
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: Failing Travis CI build and Smoke Test / JDK8 ubuntu-latest

[Martin Grigorov]

Hi,

On Wed, Aug 5, 2020 at 10:22 AM jean-frederic clere 
wrote:

> Hi,
>
> The Travis CI build seems to fail on timout regularly should we increase
> the timeout? Or investigate the problem?
>
> Smoke Test / JDK8 ubuntu-latest fails on tls3 tests should we make the
> test conditional?
>

TravisCI or GitHub Actions ?

TravisCI is used for non-x86_64 architectures and they are known to run
slow because those architectures are experimental on Travis and run on less
powerful VMs. So, timeouts happen more often :-/


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

Re: Jakarta EE APIs

[Martin Grigorov]

On Wed, Jul 22, 2020, 18:10 Mark Thomas  wrote:

> Hi all,
>
> We currently have implementations for all of the Jakarta APIs that ship
> with Tomcat and partial implementations for 5 additional Jakarta APIs that
> are compile time only dependencies.
>
> I was checking those partial implementations earlier today when I noticed
> the Jakarta Mail API needed updating to use generics. I started on that but
> paused when it looked like a number of new (dummy) classes would be
> required.
>
> Considering alternative options, I wondered about depending on the Jakarta
> API JARs directly. This would be a return to the 5.5.x era approach
> without  hopefully, the issue that JARs could be difficult to obtain.
>
> I have this implemented locally. It removes about 1000 lines of .java
> files (although just under 10% of them are actual code) and adds about 100
> lines of build file config and anither 50 of IDE configuration.
>
> With the Jakarta JARs being readily available in Maven Central I think the
> primary issue that led to the current approach is no longer a concern.
>
> Thoughts on switching to using the JARs directly? I can provide a


+1

PR if that is helpful.


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

Re: [tomcat] 02/02: Avoid reflection for default instantiation

[Martin Grigorov]

Hi,

On Wed, Jul 22, 2020 at 2:18 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> fhanik pushed a commit to branch 9.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
> commit f4dac6846c548144799b1c3f33aba4eb320a3413
> Author: Filip Hanik 
> AuthorDate: Mon Jul 13 12:43:55 2020 -0700
>
> Avoid reflection for default instantiation
>
> (Most commonly used codepath)
>
> Avoid having to load APR classes in the Connector
>
> Ensure that IntrospectionUtils can call setProperty on
> PersistentProviderRegistrations
> ---
>  .../auth/message/config/AuthConfigFactory.java |  8 ++-
>  .../jaspic/PersistentProviderRegistrations.java|  5 +-
>  java/org/apache/catalina/connector/Connector.java  | 14 ++---
>  .../apache/catalina/core/AprLifecycleListener.java | 43 ++
>  java/org/apache/catalina/core/AprStatus.java   | 69
> ++
>  java/org/apache/catalina/core/StandardHost.java|  4 +-
>  java/org/apache/catalina/loader/WebappLoader.java  |  4 ++
>  java/org/apache/catalina/startup/Tomcat.java   |  8 ++-
>  8 files changed, 119 insertions(+), 36 deletions(-)
>
> diff --git
> a/java/javax/security/auth/message/config/AuthConfigFactory.java
> b/java/javax/security/auth/message/config/AuthConfigFactory.java
> index d98b2f2..b27235b 100644
> --- a/java/javax/security/auth/message/config/AuthConfigFactory.java
> +++ b/java/javax/security/auth/message/config/AuthConfigFactory.java
> @@ -72,8 +72,12 @@ public abstract class AuthConfigFactory {
>  // this class. Note that the Thread context
> class loader
>  // should not be used since that would
> trigger a memory leak
>  // in container environments.
> -Class clazz = Class.forName(className);
> -return (AuthConfigFactory)
> clazz.getConstructor().newInstance();
> +if
> (className.equals("org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl"))
> {
> +return new
> org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl();
> +} else {
> +Class clazz = Class.forName(className);
> +return (AuthConfigFactory)
> clazz.getConstructor().newInstance();
> +}
>  }
>  });
>  } catch (PrivilegedActionException e) {
> diff --git
> a/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> b/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> index a1ba60c..cd75799 100644
> ---
> a/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> +++
> b/java/org/apache/catalina/authenticator/jaspic/PersistentProviderRegistrations.java
> @@ -41,7 +41,7 @@ import org.xml.sax.SAXException;
>   * Utility class for the loading and saving of JASPIC persistent provider
>   * registrations.
>   */
> -final class PersistentProviderRegistrations {
> +public final class PersistentProviderRegistrations {
>
>  private static final StringManager sm =
>
>  StringManager.getManager(PersistentProviderRegistrations.class);
> @@ -233,6 +233,9 @@ final class PersistentProviderRegistrations {
>  public void addProperty(Property property) {
>  properties.put(property.getName(), property.getValue());
>  }
> +public void setProperty(String name, String value) {
> +addProperty(name, value);
> +}
>  void addProperty(String name, String value) {
>  properties.put(name, value);
>  }
> diff --git a/java/org/apache/catalina/connector/Connector.java
> b/java/org/apache/catalina/connector/Connector.java
> index b22ce95..1cc1580 100644
> --- a/java/org/apache/catalina/connector/Connector.java
> +++ b/java/org/apache/catalina/connector/Connector.java
> @@ -29,7 +29,7 @@ import org.apache.catalina.Globals;
>  import org.apache.catalina.LifecycleException;
>  import org.apache.catalina.LifecycleState;
>  import org.apache.catalina.Service;
> -import org.apache.catalina.core.AprLifecycleListener;
> +import org.apache.catalina.core.AprStatus;
>  import org.apache.catalina.util.LifecycleMBeanBase;
>  import org.apache.coyote.AbstractProtocol;
>  import org.apache.coyote.Adapter;
> @@ -80,8 +80,8 @@ public class Connector extends LifecycleMBeanBase  {
>
>
>  public Connector(String protocol) {
> -boolean apr = AprLifecycleListener.isAprAvailable() &&
> -AprLifecycleListener.getUseAprConnector();
> +boolean apr = AprStatus.isAprAvailable() &&
> +AprStatus.getUseAprConnector();
>  ProtocolHandler p = null;
>  try {
>  p = ProtocolHandler.create(protocol, apr);
> @@ -625,7 +625,7 @

Re: JDK 15 is now in Rampdown Phase Two

[Martin Grigorov]

Hi Rory,

Apache Tomcat build and tests are fine with JDK 15 b32 and JDK 16 b06 on
x86_64 and aarch64 CPU architectures!

Regards,
Martin

On Fri, Jul 17, 2020 at 12:03 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Per the JDK 15 schedule, we are in Rampdown Phase Two* *[1]*
> 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 [4], but the bar is
> now extraordinarily high.
>
> *Please advise if you have any open high priority issues. *
>
>- Schedule for JDK 15
>   - 2*020/07/16 Rampdown Phase Two*
>   - 2020/08/06 Initial Release Candidate
>   - 2020/08/20 Final Release Candidate
>   - 2020/09/15 General Availability
>
>
>- Features included in JDK 15:
>   - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
>   
>   - JEP 360: Sealed Classes (Preview)
>   
>   - JEP 371: Hidden Classes 
>   - JEP 372: Remove the Nashorn JavaScript Engine
>   
>   - JEP 373: Reimplement the Legacy DatagramSocket API
>   
>   - JEP 374: Disable and Deprecate Biased Locking
>   
>   - JEP 375: Pattern Matching for instanceof (Second Preview)
>   
>   - JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
>   
>   - JEP 378: Text Blocks 
>   - JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
>   
>   - JEP 381: Remove the Solaris and SPARC Ports
>   
>   - JEP 383: Foreign-Memory Access API (Second Incubator)
>   
>   - JEP 384: Records (Second Preview)
>   
>   - JEP 385: Deprecate RMI Activation for Removal
>   
>
> *JDK 15 **Early Access build 32 **is available** at : - jdk.java.net/15/
> *
>
> These early-access, open-source builds are provided under the GNU General
> Public License, version 2, with the Classpath Exception.
>
>- Release notes
>- http://jdk.java.net/15/release-notes
>- Recent fixes that might be of interest
>   -
>
>   Build 32
>   - 8231800: Better listing of arrays
>  - 8234836: Improve serialization handling
>   - Build 31
>   - JDK-8248505: Unexpected NoSuchAlgorithmException when using
>  secure random impl from BCFIPS provider
>   - Build 29
>  - JDK-8233014: Enable ShowCodeDetailsInExceptionMessages by
>  default
>
> *JDK 16 Early Access build 6 **is available** at : - jdk.java.net/16/
> *
> These early-access, open-source builds are provided under the GNU General
> Public License, version 2, with the Classpath Exception.
>
>- JEP Candidate
>   - JEP 388: Windows/AArch64 Port 
>- JEPs proposed to target
>   - JEP 347: Enable C++14 Language Features
>   
>- JEPs targeted to JDK 16, so far:
>   - JEP 369: Migrate to GitHub 
>   - JEP 357: Migrate from Mercurial to Git
>   
>
>
>- Recent fixes that might be of interest
>   -
>
>   Build 32
>   - 8231800: Better listing of arrays
>  - 8234836: Improve serialization handling
>   - Build 5
>   - JDK-8218021: Have jarsigner preserve posix permission attributes
>  - JDK-8245302: Upgrade LogRecord to support long thread ids and
>  remove its usage of ThreadLocal
>  - JDK-8248505: Unexpected NoSuchAlgorithmException when using
>  secure random impl from BCFIPS provider
>
> *Cryptoroadmap updated *
>
>- https://www.java.com/en/jre-jdk-cryptoroadmap.html
>
>
>
> *The "Best of the JDK" feature face-off tournament: Result!*
>
>- *JDK Mission Control *is the winner based on the Twitter poll
>.
>
> *The Quality Outreach Report for *June 2020 is available via the Quality
> Wiki page*: *
> *June 2020
> 
> *
>
> Rgds,Rory
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004536.html
> [2] https://openjdk.java.net/jeps/3
> [3] https://openjdk.java.net/jeps/3#Fix-Request-Process
> [4] https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [tomcat] branch 9.0.x updated: Fix BZ 64548 - generate JPMS metadata

[Martin Grigorov]

On Mon, Jul 13, 2020 at 1:02 PM Mark Thomas  wrote:

> There are some Java EE / Jakarta EE issues here.
>
> Tomcat 10 is Jakarta EE.
> Tomcat 9 is Java EE.
>
> There should not be any references to Jakarta in Tomcat 9. This needs to
> be fixed before the next Tomcat 9 release.
>
> I don't think there are definitive JPMS names for the Java EE 8 modules
> as Java EE 8 pre-dates Java 9 where JPMS was introduced. I'm not sure of
> the best way to handle this. Options that come to mind are:
> a) no JPMS info at all
> b) align it with the JAR file names (i.e. replicate what would happen by
>default)
> c) Use the Jakarta EE 9 names but with javax.* rather than jakarta.*
>

c) sounds the best to me
Many people use Tomcat 9 (as the current stable version) with newer JDKs.


>
> Mark
>
>
> On 11/07/2020 03:42, rotty3...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rotty3000 pushed a commit to branch 9.0.x
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/9.0.x by this push:
> >  new 39e7478  Fix BZ 64548 - generate JPMS metadata
> > 39e7478 is described below
> >
> > commit 39e74780c4292d51b544620e59124c2dfb1b9ab8
> > Author: Raymond Augé 
> > AuthorDate: Fri Jun 19 22:25:54 2020 -0400
> >
> > Fix BZ 64548 - generate JPMS metadata
> >
> > Signed-off-by: Raymond Augé 
> > ---
> >  res/bnd/annotations-api.jar.tmp.bnd| 10 +-
> >  res/bnd/build-defaults.bnd |  4 +++-
> >  res/bnd/catalina-ha.jar.tmp.bnd| 10 +-
> >  res/bnd/catalina-ssi.jar.tmp.bnd   |  8 
> >  res/bnd/catalina-storeconfig.jar.tmp.bnd   | 10 +-
> >  res/bnd/catalina-tribes.jar.tmp.bnd| 10 +-
> >  res/bnd/catalina.jar.tmp.bnd   | 20 +++-
> >  res/bnd/el-api.jar.tmp.bnd |  8 
> >  res/bnd/jasper-el.jar.tmp.bnd  | 10 +-
> >  res/bnd/jasper.jar.tmp.bnd | 11 ++-
> >  res/bnd/jaspic-api.jar.tmp.bnd | 10 +-
> >  res/bnd/jsp-api.jar.tmp.bnd|  8 
> >  res/bnd/servlet-api.jar.tmp.bnd|  8 
> >  res/bnd/tomcat-api.jar.tmp.bnd |  8 
> >  res/bnd/tomcat-coyote.jar.tmp.bnd  | 10 +-
> >  res/bnd/tomcat-dbcp.jar.tmp.bnd|  9 -
> >  res/bnd/tomcat-embed-core.jar.tmp.bnd  | 19 ++-
> >  res/bnd/tomcat-embed-el.jar.tmp.bnd|  9 -
> >  res/bnd/tomcat-embed-jasper.jar.tmp.bnd|  9 -
> >  res/bnd/tomcat-embed-websocket.jar.tmp.bnd | 11 +--
> >  res/bnd/tomcat-jni.jar.tmp.bnd | 10 +-
> >  res/bnd/tomcat-juli.jar.tmp.bnd| 10 +-
> >  res/bnd/tomcat-util-scan.jar.tmp.bnd   | 10 +-
> >  res/bnd/tomcat-util.jar.tmp.bnd| 10 +-
> >  res/bnd/tomcat-websocket.jar.tmp.bnd   | 10 +-
> >  res/bnd/websocket-api.jar.tmp.bnd  | 10 +-
> >  webapps/docs/changelog.xml |  3 +++
> >  27 files changed, 243 insertions(+), 22 deletions(-)
> >
> > diff --git a/res/bnd/annotations-api.jar.tmp.bnd
> b/res/bnd/annotations-api.jar.tmp.bnd
> > index 19db9f4..09151bf 100644
> > --- a/res/bnd/annotations-api.jar.tmp.bnd
> > +++ b/res/bnd/annotations-api.jar.tmp.bnd
> > @@ -32,4 +32,12 @@ Provide-Capability: \
> >  Implementation-Version=1.3.${annotation.revision};\
> >  Specification-Title='Common Annotations';\
> >  Specification-Vendor='Oracle Corporation';\
> > -Specification-Version=1.3
> > \ No newline at end of file
> > +Specification-Version=1.3
> > +
> > +-jpms-module-info: \
> > +jakarta.annotation;\
> > +access=32;\
> > +version=${annotation.spec.version}
> > +-jpms-module-info-options: \
> > + jakarta.annotation;\
> > + substitute=annotations-api
>
> Should not reference Jakarta
>
> > diff --git a/res/bnd/catalina.jar.tmp.bnd b/res/bnd/catalina.jar.tmp.bnd
> > index dc94c42..972745c 100644
> > --- a/res/bnd/catalina.jar.tmp.bnd
> > +++ b/res/bnd/catalina.jar.tmp.bnd
> > @@ -48,4 +48,22 @@ Export-Package: \
> >  org.apache.catalina
> >
> >  -includepackage: \
> > -org.apache.naming.factory.webservices
> > \ No newline at end of file
> > +org.apache.naming.factory.webservices
> > +
> > +-jpms-module-info: \
> > +${module.name};\
> > +access=32;\
> > +version=${Bundle-Version};\
> > +modules='\
> > +jakarta.ejb-api,\
> > +jakarta.mail,\
> > +jakarta.persistence-api,\
> > +jakarta.xml.rpc-api,\
> > +java.xml.ws'
> > +-jpms-module-info-options: \
> > +${module.name};substitute=catalina,\
> > +jakarta.ejb-api;static=true,\
> > +jakarta.mail;static=true,\
> > +jakarta.persistence-api;static=true,\
> > +jakarta.xml.rpc-api;

Re: [tomcat] branch master updated: Use StringBuilder instead of StringBuffer

[Martin Grigorov]

Hi Chris,

On Mon, Jul 6, 2020 at 5:12 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 7/6/20 03:09, mgrigo...@apache.org wrote:
> > diff --git
> > a/java/org/apache/catalina/connector/CoyotePrincipal.java
> > b/java/org/apache/catalina/connector/CoyotePrincipal.java index
> > 1ae5608..93d7c02 100644 ---
> > a/java/org/apache/catalina/connector/CoyotePrincipal.java +++
> > b/java/org/apache/catalina/connector/CoyotePrincipal.java @@ -64,7
> > +64,7 @@ public class CoyotePrincipal implements Principal,
> > Serializable { public String toString() { StringBuilder sb = new
> > StringBuilder("CoyotePrincipal["); sb.append(this.name); -
> > sb.append("]"); +sb.append(']'); return sb.toString(); }
>
> Might I suggest further improvements?
>
> Step 1:
>
>   public String toString() {
>   return new StringBuilder("CoyotePrincipal[")
>   .append(this.name);
>   .append(']');
>   .toString();
>
> It turns out that the generated bytecode is something like 2/3 as long
> as the sb.append(); sb.append(); sb.append(); code. JIT probably does
> the same thing eventually, but why not help it out?
>
> Step 2:
>
>   public String toString() {
>   return "CoyotePrincipal[" + this.name + ']';
>   }
>
> This has a few advantages:
>
> 1. It's dead easy to read
>
> 2. The compiler makes the best decision as to how to perform the
> concatenation
>
> In very old versions of Java, you'll get StringBuffer concatenation as
> the pre-commit version. Later versions get you StringBuilder as
> post-commit version. Post 9.x-versions get you a call to
> StringConcatFactory.makeConcatWithConstants which is presumably even
> more efficient.
>
> I understand that this was supposed to be a small patch, but I think
> further improvements are possible in many cases like this one.
>

Agreed!
https://github.com/apache/tomcat/pull/321

Martin


>
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DMT8ACgkQHPApP6U8
> pFgUtA/+OoHnIgHBLoIOXqP5t10g/dBFxGrIpOUOe1MvIhWMdObcNIlZmnM1vv0Z
> xCRYXxGCj20xm4P/NEzvRlEPWfd0uvoZczr34JVPlgOWUBJeRHmLQ+KlGdCeuuKk
> cmxV4ZXZSt8bzVMufQ+N2RPOCGUvti2kin0CSj9BlygKuTAMuXgwVcyEo7XvLf3z
> 153dHylBL3ka5jo2lR4vYlj8U6PvzoZuLj3NAnrRZP3YttbQKimhXDcOg7zkeVP+
> GFINDBE+fux+s5P38vqRLqzA4JEDFfjsKzT4JV21BrSbxhdUbXyYE4RMhW+izKB8
> B/SJhBtEN1huED3GkZbg/DN0nYgY4vVeoHz4kdal1E5uVybG5SLj6xoz6tkRsayB
> pOHguW1ds8NLPJwHBEATq6YQOXGfqECbW+iWuP54F7eBzo57CiZWsnQPalpSo9pn
> mdBRbcfyI7z9vJFaiGCpudKGKK5+F1VFj6KELxZP7nAO0Lyhwapsai9TzLXLOTk1
> 8ReS5GENoZDrzrb3Gn/YCmdYAxdED9ejjkiY5qVjX3ZXWXaeytcz1h3bY2opV4Ks
> a+tahArWqI1t44cemejJuiXFZB0xrDjji6pnd3ZqZ4vG1TREKxK2hdLjuwP3vaw9
> fqt4d3E596rPtqF2e0aJLGfW+3iJ2r67c7DP9ARHMAdadMIi23U=
> =N+0c
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [ANN] New committer: Raymond Augé

[Martin Grigorov]

Welcome Raymond!

On Thu, Jul 2, 2020, 17:40 Mark Thomas  wrote:

> On behalf of the Tomcat committers I am pleased to announce that
> Raymond Augé (rotty3000) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 8.5.57

[Martin Grigorov]

On Wed, Jul 1, 2020, 23:48 George Stanchev 
wrote:

> I ran ant ide-eclipse and the generated project contains a reference to
>
>
>
>  path="TOMCAT_LIBS_BASE/cglib-3.3.0/cglib-nodep-2.2.2.jar"/>
>
>
>
> But D:\work\My
> Projects\java\Tomcat\8.5.57-src\libraries-download\cglib-3.3.0 contains
> only cglib-nodep-3.3.0.jar not cglib-nodep-2.2.2.jar. Not sure if I did
> something wrong…The resulting eclipse project of course complains from
> unsatisfied dependencies…
>

Sorry for the trouble!
I've just fixed it!
You'll have to replace 2.2.2 with 3.3.0 in
res/ide-support/eclipse/eclipse.classpath and re-run "ant ide-eclipse".

Regards,
Martin


>
> George
>
>
>
> *From:* Coty Sutherland 
> *Sent:* Wednesday, July 01, 2020 1:48 PM
> *To:* Tomcat Developers List 
> *Subject:* Re: [VOTE] Release Apache Tomcat 8.5.57
>
>
>
> On Tue, Jun 30, 2020 at 6:14 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 8.5.57 release is now available for voting.
>
> The notable changes compared to the 8.5.56 release are:
>
> - Implement a significant portion of the TLS environment variables
>   for the rewrite valve.
>
> - Reduce memory footprint of closed HTTP/2 streams
>
> - Improve parsing of RFC 2109 cookies
>
> 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.57/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1274/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.57
> 9c649984ef92c2534a734c6584220a9a0c0c3462
>
> The proposed 8.5.57 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 8.5.57
>
>
>
> +1
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 10.0.0-M7

[Martin Grigorov]

On Tue, Jun 30, 2020 at 9:16 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M7 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-M6 are:
>
> - Implement a significant portion of the TLS environment variables
>   for the rewrite valve.
>
> - Add the Jakarta EE 9 schema.
>
> - Improvements to the creatio of OSGi manifests.
>
> 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.0-M7/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1272/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M7
> c549413165721180b15f62033c1be6c5970028fd
>
> The proposed 10.0.0-M7 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M7
>


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

[Martin Grigorov]

On Wed, Jul 1, 2020 at 1:14 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.57 release is now available for voting.
>
> The notable changes compared to the 8.5.56 release are:
>
> - Implement a significant portion of the TLS environment variables
>   for the rewrite valve.
>
> - Reduce memory footprint of closed HTTP/2 streams
>
> - Improve parsing of RFC 2109 cookies
>
> 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.57/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1274/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.57
> 9c649984ef92c2534a734c6584220a9a0c0c3462
>
> The proposed 8.5.57 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.57
>

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

[Martin Grigorov]

On Tue, Jun 30, 2020 at 11:41 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.37 release is now available for voting.
>
> The notable changes compared to the 9.0.36 release are:
>
> - Implement a significant portion of the TLS environment variables
>   for the rewrite valve.
>
> - Improvements to the creation of OSGi manifests.
>
> - Reduce memory footprint of closed HTTP/2 streams
>
> 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.37/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1273/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.37
> bd68c421ea32fea08263db73cd5b987ab606a0bb
>
> The proposed 9.0.37 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.37
>


Regards,
Martin


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

Re: JDK 15 is in Rampdown Phase One

[Martin Grigorov]

Hi Rory,

I've built Tomcat 9.0.x and ran its tests with JDK 15 b28 on both x86_64
and aarch64.
No issues found!

Regards,
Martin

On Mon, Jun 22, 2020 at 7:25 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *Per the JDK 15 schedule , we are in Rampdown Phase One* *[1]  *
>
>
> *Please advise if you find any issues while testing the latest Early
> Access builds. *
>
>- Schedule for JDK 15
>   - *2020/06/11 Rampdown Phase One*
>   - 2020/07/16 Rampdown Phase Two
>   - 2020/08/06 Initial Release Candidate
>   - 2020/08/20 Final Release Candidate
>   - 2020/09/15 General Availability
>
>
>
>
>- Features included in JDK 15:
>   - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
>   
>   - JEP 360: Sealed Classes (Preview)
>   
>   - JEP 371: Hidden Classes 
>   - JEP 372: Remove the Nashorn JavaScript Engine
>   
>   - JEP 373: Reimplement the Legacy DatagramSocket API
>   
>   - JEP 374: Disable and Deprecate Biased Locking
>   
>   - JEP 375: Pattern Matching for instanceof (Second Preview)
>   
>   - JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
>   
>   - JEP 378: Text Blocks 
>   - JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
>   
>   - JEP 381: Remove the Solaris and SPARC Ports
>   
>   - JEP 383: Foreign-Memory Access API (Second Incubator)
>   
>   - JEP 384: Records (Second Preview)
>   
>   - JEP 385: Deprecate RMI Activation for Removal
>   
>
> *JDK 15 **Early Access build 28 **is available** at : - jdk.java.net/15/
> *
>
>
> These early-access, open-source builds are provided under the GNU General
> Public License, version 2, with the Classpath ExceptionRelease notes
>
>- Release notes
>- http://jdk.java.net/15/release-notes
>- Recent fixes that might be of interest
>   - Build 27
>  - JDK-8233215: jpackage doesn't allow enough flexibility for
>  file type binding
>  - JDK-8244582: Remove terminally deprecated Solaris-specific
>  SO_FLOW_SLA socket option
>  - JDK-8245068: Implement Deprecation of RMI Activation
>  - JDK-8246770: Atomic::add() with 64 bit value fails to link on
>  32-bit platforms
> - Reported by JaCoCo
>  - Build 26
>  - JDK-8240871: SSLEngine handshake status immediately after the
>  handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3
>  - Reported by Apache Tomcat
> - Build 25
>  - JDK-8206925: Support the certificate_authorities extension
>   - JDK-8239480: Support for CLDR version 37
>  - JDK-8243925: Toolkit#getScreenInsets() returns wrong value on
>  HiDPI screens (Windows)
>
>
>
>
>
> *JDK 16 Early Access build 2 **is available** at : - jdk.java.net/16/
> *
> These early-access, open-source builds are provided under the GNU General
> Public License, version 2, with the Classpath Exception.
>
>
>
>
>
> *Survey on **jinfo, jmap, jstack serviceability tools in JDK: *
>
>- Oracle is considering deprecation and (eventual) removal of 3 JDK
>tools - jinfo, jmap, jstack.
>- The Survey Link
> will
>remain open through July 15 2020.
>
>
> Rgds, Rory
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004401.html
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: Changing the name of the default branch in our git repos

[Martin Grigorov]

Hi,

On Tue, Jun 16, 2020 at 11:02 AM Mark Thomas  wrote:

> All,
>
> You may have seen the recent discussions both inside and outside the ASF
> about the user of "master" as the name of the default git branch. If you
> haven't, the short version is that the name can be traced back to
> master/slave and its associations with human slavery.
>
> I'd like to propose that the Apache Tomcat project renames the master
> branch in all of the project repositories.
>
> I think there are two front runners for the new name:
>
> - main - this looks to be the name GitHub and a number of OSS projects
>  will be switching to
>
> - trunk - reflects the Subversion heritage of both the project and the
>   ASF
>
> Other options I have seen suggested include "default", "dev", "develop".
> Other suggestions welcome.
>
> Personally, I am leaning towards main as that looks to be the choice of
> the majority and using the majority choice will make it (a little bit)
> easier for new community members to find their way around the project.
>
> In terms of impact, changing the name is going to break stuff. It is
> really creating a new branch and deleting the old one.
>
> Deleting a branch triggers the automatic closure of github PRs against
> that branch. However if we create "$new_branch" we can edit the PRs to
> use "$new_branch" before we delete master. Given the small number of
> open PRs that is easily done.
>
> CI systems will need to be updated (buildbot, gump). That should be
> relatively simple.
>
> Docs will need to be updated (relatively simple).
>
> Committers and contributors will rebase any local branches to $new_branch
>
> Having thought about what is involved, renaming the default branch
> doesn't look as problematic as I thought it might be. This looks like
> something that could be done in around an hour for all our repos.
>
> Thoughts?
>

I, personally, do not see any relation between technical nomenclature and
social problems in real life.
I have many colored skin friends and colleagues and I've never heard anyone
making such associations.
I am Bulgarian. Until not so long ago we were ruled for 5 centuries by
Ottomans but I do not feel like a slave and I don't find 'master' branch
name anyhow related to slavery.
I am -0 on such change and any other change that comes from politics.

But if we are going to change the branch name then I suggest '10.0.x'. This
way it will be consistent with all other branches.

Martin


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

Re: buildbot failure in on tomcat-85-trunk

[Martin Grigorov]

On Wed, Jun 10, 2020 at 3:08 PM Mark Thomas  wrote:

> On 10/06/2020 13:01, Martin Grigorov wrote:
> > Hi,
> >
> > The build of 8.5.x passes here but it failed
> > at https://ci.apache.org/builders/tomcat-85-trunk/builds/2349.
> > But without access to the file system I cannot find what is the reason.
> > How do you investigate such problems at Buildbot machines ?
>
> https://ci.apache.org/projects/tomcat/tomcat85/
>
> In logs there is a dir for each build with all the individual output files.
>

Thanks!


>
> Mark
>
>
> >
> > [concat] Testsuites with failed tests:
> >[concat] TEST-org.apache.catalina.realm.TestJNDIRealm.APR.txt
> >[concat] TEST-org.apache.catalina.realm.TestJNDIRealm.NIO.txt
> >[concat] TEST-org.apache.catalina.realm.TestJNDIRealm.NIO2.txt
> >[concat]
> TEST-org.apache.catalina.startup.TestWebappServiceLoader.APR.txt
> >[concat]
> TEST-org.apache.catalina.startup.TestWebappServiceLoader.NIO.txt
> >[concat]
> > TEST-org.apache.catalina.startup.TestWebappServiceLoader.NIO2.txt
> >[concat]
> > TEST-org.apache.catalina.valves.TestCrawlerSessionManagerValve.APR.txt
> >[concat]
> > TEST-org.apache.catalina.valves.TestCrawlerSessionManagerValve.NIO.txt
> >[concat]
> > TEST-org.apache.catalina.valves.TestCrawlerSessionManagerValve.NIO2.txt
> >[concat]
> > TEST-org.apache.catalina.valves.TestLoadBalancerDrainingValve.APR.txt
> >[concat]
> > TEST-org.apache.catalina.valves.TestLoadBalancerDrainingValve.NIO.txt
> >[concat]
> > TEST-org.apache.catalina.valves.TestLoadBalancerDrainingValve.NIO2.txt
> >[concat] TEST-org.apache.catalina.valves.TestSSLValve.APR.txt
> >[concat] TEST-org.apache.catalina.valves.TestSSLValve.NIO.txt
> >[concat] TEST-org.apache.catalina.valves.TestSSLValve.NIO2.txt
> >[concat] TEST-org.apache.jasper.servlet.TestTldScanner.APR.txt
> >[concat] TEST-org.apache.jasper.servlet.TestTldScanner.NIO.txt
> >[concat] TEST-org.apache.jasper.servlet.TestTldScanner.NIO2.txt
> >
> > BUILD FAILED
> > /home/buildslave/slave/tomcat-85-trunk/build/build.xml:1467: Some tests
> > completed with an Error. See
> > /home/buildslave/slave/tomcat-85-trunk/build/output/build/logs for
> > details, search for "ERROR".
> >
> > Total time: 15 minutes 27 seconds
> >
> >
> >
> > On Tue, Jun 9, 2020 at 11:31 PM  > <mailto:build...@apache.org>> wrote:
> >
> > The Buildbot has detected a new failure on builder tomcat-85-trunk
> > while building tomcat. Full details are available at:
> > https://ci.apache.org/builders/tomcat-85-trunk/builds/2347
> >
> > Buildbot URL: https://ci.apache.org/
> >
> > Buildslave for this Build: asf946_ubuntu
> >
> > Build Reason: The AnyBranchScheduler scheduler named
> > 'on-tomcat-85-commit' triggered this build
> > Build Source Stamp: [branch 8.5.x]
> > 1cb2595861be406faf224417bb3dd874f9254bc0
> > Blamelist: Mark Thomas  > <mailto:ma...@apache.org>>,Martin Tzvetanov Grigorov
> > mailto:mgrigo...@apache.org>>
> >
> > BUILD FAILED: failed compile_1
> >
> > Sincerely,
> >  -The Buildbot
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > <mailto:dev-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > <mailto:dev-h...@tomcat.apache.org>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: buildbot failure in on tomcat-85-trunk

[Martin Grigorov]

Hi,

The build of 8.5.x passes here but it failed at
https://ci.apache.org/builders/tomcat-85-trunk/builds/2349.
But without access to the file system I cannot find what is the reason.
How do you investigate such problems at Buildbot machines ?

[concat] Testsuites with failed tests:
   [concat] TEST-org.apache.catalina.realm.TestJNDIRealm.APR.txt
   [concat] TEST-org.apache.catalina.realm.TestJNDIRealm.NIO.txt
   [concat] TEST-org.apache.catalina.realm.TestJNDIRealm.NIO2.txt
   [concat] TEST-org.apache.catalina.startup.TestWebappServiceLoader.APR.txt
   [concat] TEST-org.apache.catalina.startup.TestWebappServiceLoader.NIO.txt
   [concat]
TEST-org.apache.catalina.startup.TestWebappServiceLoader.NIO2.txt
   [concat]
TEST-org.apache.catalina.valves.TestCrawlerSessionManagerValve.APR.txt
   [concat]
TEST-org.apache.catalina.valves.TestCrawlerSessionManagerValve.NIO.txt
   [concat]
TEST-org.apache.catalina.valves.TestCrawlerSessionManagerValve.NIO2.txt
   [concat]
TEST-org.apache.catalina.valves.TestLoadBalancerDrainingValve.APR.txt
   [concat]
TEST-org.apache.catalina.valves.TestLoadBalancerDrainingValve.NIO.txt
   [concat]
TEST-org.apache.catalina.valves.TestLoadBalancerDrainingValve.NIO2.txt
   [concat] TEST-org.apache.catalina.valves.TestSSLValve.APR.txt
   [concat] TEST-org.apache.catalina.valves.TestSSLValve.NIO.txt
   [concat] TEST-org.apache.catalina.valves.TestSSLValve.NIO2.txt
   [concat] TEST-org.apache.jasper.servlet.TestTldScanner.APR.txt
   [concat] TEST-org.apache.jasper.servlet.TestTldScanner.NIO.txt
   [concat] TEST-org.apache.jasper.servlet.TestTldScanner.NIO2.txt

BUILD FAILED
/home/buildslave/slave/tomcat-85-trunk/build/build.xml:1467: Some tests
completed with an Error. See
/home/buildslave/slave/tomcat-85-trunk/build/output/build/logs for details,
search for "ERROR".

Total time: 15 minutes 27 seconds



On Tue, Jun 9, 2020 at 11:31 PM  wrote:

> The Buildbot has detected a new failure on builder tomcat-85-trunk while
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-85-trunk/builds/2347
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: asf946_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit'
> triggered this build
> Build Source Stamp: [branch 8.5.x] 1cb2595861be406faf224417bb3dd874f9254bc0
> Blamelist: Mark Thomas ,Martin Tzvetanov Grigorov <
> mgrigo...@apache.org>
>
> BUILD FAILED: failed compile_1
>
> Sincerely,
>  -The Buildbot
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [tomcat] branch master updated (01e46e0 -> e461544)

[Martin Grigorov]

I am going to downport these updates to 9.0.x and 8.5.x once I'm done with
the planned changes and I see that BuildBot is happy.
It is my first time doing this and I still miss some of the places where I
have to update the versions.

On Tue, Jun 9, 2020 at 3:32 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> mgrigorov pushed a change to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
>
>
> from 01e46e0  Update some more occurrences of hamcrest-core-1.3 to
> hamcrest-2.2
>  add e461544  Update Easymock to 4.2
>
> No new revisions were added by this update.
>
> Summary of changes:
>  build.properties.default|  6 +++---
>  res/ide-support/eclipse/eclipse.classpath   |  2 +-
>  res/ide-support/idea/tomcat.iml | 18
> --
>  res/ide-support/netbeans/nb-tomcat-build.properties |  2 +-
>  res/ide-support/netbeans/project.xml|  2 +-
>  5 files changed, 14 insertions(+), 16 deletions(-)
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: ide-intellij path variables ?!

[Martin Grigorov]

On Tue, Jun 9, 2020 at 11:22 AM Violeta Georgieva 
wrote:

>
>
> На вт, 9.06.2020 г. в 10:47 Martin Grigorov  написа:
> >
> > Hi,
> >
> > `ant ide-intellij` prints the following:
> >
> > ide-intellij:
> >  [copy] Copying 10 files to
> /home/martin/git/apache/tomcat/tomcat-server/.idea
> >  [echo] IntelliJ IDEA project directory created. Please create PATH
> VARIABLES for
> >  [echo]
> >  [echo]   ANT_HOME  = /home/martin/devel/apache-ant
> >  [echo]   TOMCAT_BUILD_LIBS = /home/martin/tomcat-build-libs
> >  [echo]
> >
> >
> > I guess this should be ENVIRONMENT VARIABLES instead ?
> > There is nothing related to $PATH in these entries.
>
> When you generate files for IntelliJ IDEA and open the project you will
> see an error message like this
>
> `Load error: undefined path variables
> ANT_HOME, TOMCAT_BUILD_LIBS are undefined. Fix it
> Path variables are used to substitute absolute paths in IDEA project files
> and allow project file sharing in version control systems.
> Some of the files describing the current project settings contain unknown
> path variables and IDEA cannot restore those paths.`
>
> When you click this `Fix it`, a window will open and you will be able to
> specify the paths.
>

Yes, I've done this already.
It is confusing but it seems this is the correct name.

Thanks!



>
> Regards,
> Violeta
>

ide-intellij path variables ?!

[Martin Grigorov]

Hi,

`ant ide-intellij` prints the following:

ide-intellij:
 [copy] Copying 10 files to
/home/martin/git/apache/tomcat/tomcat-server/.idea
 [echo] IntelliJ IDEA project directory created. Please create PATH
VARIABLES for
 [echo]
 [echo]   ANT_HOME  = /home/martin/devel/apache-ant
 [echo]   TOMCAT_BUILD_LIBS = /home/martin/tomcat-build-libs
 [echo]


I guess this should be ENVIRONMENT VARIABLES instead ?
There is nothing related to $PATH in these entries.

Regards,
Martin

Re: Usage of SynchronizedStack/Queue

[Martin Grigorov]

On Fri, Jun 5, 2020 at 6:29 PM Mark Thomas  wrote:

> On 05/06/2020 14:08, Martin Grigorov wrote:
> > For load testing it I use wrk: wrk -c96 -t8 -d60s https://host:port/test
> > The GC JVM arguments are: -Xloggc:./gc.log -XX:+PrintGCDetails
> -verbose:gc
> > JDK 1.8.0 b252
> >
> > The GC logs are:
> > - Tomcat 9.0.x (uses
> > SynchronizedQueue/Stack):
> https://gist.github.com/martin-g/d2570e7a6896e4d094ce548ceea3adb6
> > - Tomcat 9.0.x with my
> > changes:
> https://gist.github.com/martin-g/52c7d3a883b37e9bcd11ad6430800852
> > I've uploaded them to https://gceasy.io/ and the charts are similar.
>
> lock-free has marginally higher throughput.
>
> It has a longer GC pause but that might be a result of running longer
> (~x2 longer).
>
> Average creation rate and average promotion rate are lower.
>
> Given this was with Java 8 I'm +1 to switching Tomcat 10 and also +1 to
> switching Tomcat 9 if we can do it without impacting the API.
>

I've
noticed org.apache.tomcat.util.collections.TesterPerformanceSynchronizedStack
and org.apache.tomcat.util.collections.TesterPerformanceSynchronizedQueue
in test/ folder.
Those give 1.5-3 times better results for SynchronizedQueue/Stack than Java
Collections impls.
I am not so sure my proposal is a good one anymore.


>
> I'm neutral on making the change in Tomcat 8.5 and -0.5 on Tomcat 7.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Usage of SynchronizedStack/Queue

[Martin Grigorov]

Hi,

On Thu, Jun 4, 2020 at 9:28 PM Rémy Maucherat  wrote:

> On Thu, Jun 4, 2020 at 6:16 PM Mark Thomas  wrote:
>
>> On 04/06/2020 16:33, Martin Grigorov wrote:
>> > Hi team,
>> >
>> > I am profiling our application and I've found that Tomcat uses its own
>> > Synchronized Queue/Stack implementations which synchronize on instance
>> > level, i.e. their methods are 'synchronized'.
>>
>
> Can you work off 10 (master) first ?
>

The application is based on Spring Boot and my attempts to
"jakartaee migrate it" were not successful.

But I've created a very simple Servlet and I will try it on Tomcat 10.x
soon:

@WebServlet(urlPatterns = "/test")
public class PlainTextServlet extends HttpServlet {

public static final String CONTENT = "Hello world!";
public static final int CONTENT_LENGTH = CONTENT.length();

@Override
protected void doGet(final HttpServletRequest req, final
HttpServletResponse resp) throws IOException {
 resp.setContentType("text/plain");
 resp.setContentLength(CONTENT_LENGTH);
 resp.getWriter().println(CONTENT);
}
}

For load testing it I use wrk: wrk -c96 -t8 -d60s https://host:port/test
The GC JVM arguments are: -Xloggc:./gc.log -XX:+PrintGCDetails -verbose:gc
JDK 1.8.0 b252

The GC logs are:
- Tomcat 9.0.x (uses SynchronizedQueue/Stack):
https://gist.github.com/martin-g/d2570e7a6896e4d094ce548ceea3adb6
- Tomcat 9.0.x with my changes:
https://gist.github.com/martin-g/52c7d3a883b37e9bcd11ad6430800852
I've uploaded them to https://gceasy.io/ and the charts are similar.

The summary from wrk with SynchronizedQueue/Stack is:

Running 1m test @ http://192.168.0.206:8080
  8 threads and 96 connections
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 1.24ms  788.15us  19.46ms   91.44%
Req/Sec10.04k 1.64k   12.45k79.48%
  4797193 requests in 1.00m, 600.19MB read
Requests/sec:  79834.45
Transfer/sec:  9.99MB

I didn't preserve the summary from the lock-free run but it was similar -
the throughput is around 80K/sec +- few thousands.
I.e. the throughput does not improve after my changes!
Only the locking profiling results become better (Async Profiler:
./profile.sh -e lock -d50s -f lock-results.txt PID)

Martin


>
>>
>> ~8 years ago when I was profiling Tomcat and wrote those having
>> something targetted to Tomcat's specific use case made a measurable
>> improvement.
>>
>
> Yes, the SyncStack was the go to structure for all reuse. Not sure if it's
> the best.
>
> I already removed some of the usage in 10:
> - No more block poller and its pooling/recycling [I had to pull its
> removal out of 9 due to an unfortunate regression, this could be brought
> back now that it seems to work]
> - No recycling of trivial objects
>
> The main use should now be the recycled processors and the recycled
> channels (it would be bad to not reuse them since they may use direct
> buffers ...).
>
>
>>
>> I am more than prepared to believe that things have moved on since then
>> but I'd be interested in seeing the same numbers with the latest Java 8
>> from Adopt OpenJDK rather than Java 14.
>>
>
> +1, firnally there could be some differences between JDK, like now they
> started to actually improve NIO 1 again.
>
> Rémy
>
>
>>
>> I'd also like to see overall throughput numbers and the GC frequency for
>> each test scenario.
>>
>> Mark
>>
>>
>>
>> >
>> > The javadoc for those two classes say that they are preferred because
>> > they are GC-friendlier than
>> > java.uti.concurrent.ConcurrentLinkedQueue.
>> >
>> > I use Async Profiler
>> > (https://github.com/jvm-profiling-tools/async-profiler) to profile CPU,
>> > memory,
>> > locks and few lower level types (from perf).
>> > Issuing "./profiler.sh -e lock -d 60 PID" against 9.0.x shows such
>> reports:
>> >
>> > Started [lock] profiling
>> >
>> >  --- Execution profile ---
>> >
>> >  Total samples   : 713834
>> >
>> >
>> >
>> >   Frame buffer usage  : 0.0288%
>> >
>> >
>> > ---
>> > 1106165618177 ns (58.97%), 395609 samples
>> >
>> >  [ 0]
>> > org.apache.tomcat.util.collections.SynchronizedStack
>> >
>> >  [ 1]
>> > org.apache.tomcat.util.collections.Synchr

Usage of SynchronizedStack/Queue

[Martin Grigorov]

Hi team,

I am profiling our application and I've found that Tomcat uses its own
Synchronized Queue/Stack implementations which synchronize on instance
level, i.e. their methods are 'synchronized'.

The javadoc for those two classes say that they are preferred because they
are GC-friendlier than
java.uti.concurrent.ConcurrentLinkedQueue.

I use Async Profiler (https://github.com/jvm-profiling-tools/async-profiler)
to profile CPU, memory,
locks and few lower level types (from perf).
Issuing "./profiler.sh -e lock -d 60 PID" against 9.0.x shows such reports:

Started [lock] profiling
   ---
Execution profile ---
   Total
samples   : 713834


Frame buffer usage
 : 0.0288%


--- 1106165618177 ns (58.97%), 395609
samples

   [ 0]
org.apache.tomcat.util.collections.SynchronizedStack

   [ 1]
org.apache.tomcat.util.collections.SynchronizedStack.push

  [ 2]
org.apache.tomcat.util.net.NioBlockingSelector.write

   [ 3]
org.apache.tomcat.util.net.NioSelectorPool.write

   [ 4]
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite

  [ 5]
org.apache.tomcat.util.net.SocketWrapperBase.doWrite

   [ 6]
org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking

   [ 7]
org.apache.tomcat.util.net.SocketWrapperBase.flush

   [ 8]
org.apache.coyote.http11.Http11OutputBuffer$SocketOutputBuffer.end
  [ 9] org.apache.coyote.http11.filters.IdentityOutputFilter.end

  [10] org.apache.coyote.http11.Http11OutputBuffer.end
  [11] org.apache.coyote.http11.Http11Processor.finishResponse
  [12] org.apache.coyote.AbstractProcessor.action
  [13] org.apache.coyote.Response.action
  [14] org.apache.catalina.connector.OutputBuffer.close
  [15] org.apache.catalina.connector.Response.finishResponse
  [16] org.apache.catalina.connector.CoyoteAdapter.service
  [17] org.apache.coyote.http11.Http11Processor.service
  [18] org.apache.coyote.AbstractProcessorLight.process
  [19] org.apache.coyote.AbstractProtocol$ConnectionHandler.process
  [20] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
  [21] org.apache.tomcat.util.net.SocketProcessorBase.run
  [22] java.util.concurrent.ThreadPoolExecutor.runWorker
  [23] java.util.concurrent.ThreadPoolExecutor$Worker.run
  [24] org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run
  [25] java.lang.Thread.run

--- 769519847169 ns (41.03%), 314384 samples
  [ 0] org.apache.tomcat.util.collections.SynchronizedStack
  [ 1] org.apache.tomcat.util.collections.SynchronizedStack.pop
  [ 2] org.apache.tomcat.util.net.NioBlockingSelector.write
  [ 3] org.apache.tomcat.util.net.NioSelectorPool.write
  [ 4] org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite
  [ 5] org.apache.tomcat.util.net.SocketWrapperBase.doWrite
  [ 6] org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking
  [ 7] org.apache.tomcat.util.net.SocketWrapperBase.flush
  [ 8] org.apache.coyote.http11.Http11OutputBuffer$SocketOutputBuffer.end
  [ 9] org.apache.coyote.http11.filters.IdentityOutputFilter.end
  [10] org.apache.coyote.http11.Http11OutputBuffer.end
  [11] org.apache.coyote.http11.Http11Processor.finishResponse
   


I've made the following changes -
https://github.com/apache/tomcat/compare/9.0.x...martin-g:feature/lock-free-queue-and-stack
and ran the test suite - all green!

Now the output from the locks profiling looks like:


--- 72354435197 ns (47.98%), 4008 samples
  [ 0] java.util.concurrent.locks.ReentrantLock$NonfairSync
  [ 1] jdk.internal.misc.Unsafe.park
  [ 2] java.util.concurrent.locks.LockSupport.park
  [ 3] java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire
  [ 4]
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly
  [ 5] java.util.concurrent.locks.ReentrantLock$Sync.lockInterruptibly
  [ 6] java.util.concurrent.locks.ReentrantLock.lockInterruptibly
  [ 7] java.util.concurrent.LinkedBlockingQueue.poll
  [ 8] org.apache.tomcat.util.threads.TaskQueue.poll
  [ 9] org.apache.tomcat.util.threads.TaskQueue.poll
  [10] java.util.concurrent.ThreadPoolExecutor.getTask
  [11] java.util.concurrent.ThreadPoolExecutor.runWorker
  [12] java.util.concurrent.ThreadPoolExecutor$Worker.run
  [13] org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run
  [14] java.lang.Thread.run

--- 58413748017 ns (38.74%), 10179 samples
  [ 0] java.lang.Object
  [ 1] org.apache.catalina.core.StandardContext$ContextFilterMaps.asArray
  [ 2] org.apache.catalin

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

[Martin Grigorov]

On Thu, Jun 4, 2020 at 4:08 PM Emmanuel Bourg  wrote:

> I'd like to call for a vote to release the version 0.0.2 of the
> Jakarta EE migration tool.
>
> This will be a "tag only" release with no distribution of the binaries
> (neither from Apache nor from Maven Central).
>
> The notable changes compared to 0.0.1 are:
>
> - An Ant task has been added
>
> - Inplace file migration is now supported
>
> - EC signatures are now removed from the migrated jar files
>
> - Better log formatting when running from the command line
>
> - New '-verbose' option for the command line
>
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git;a=commit;h=45d354c1835a1583baf0be02ae77e70fd290f2da
>
> Source:
> https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git
>
>
> The proposed 0.0.2 release is:
> [ ] Broken - do not release
> [ X ] Beta   - go ahead and release as 0.0.2
>

I've used latest master today to test Apache Tomcat 10.0.0-M6. Successfully
migrated Apache Wicket examples application from master branch (9.x)

Regards,
Martin

Re: [VOTE] Release Apache Tomcat 10.0.0-M6

[Martin Grigorov]

On Wed, Jun 3, 2020 at 6:14 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M6 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-M5 are:
>
> - Add support for ALPN on recent OpenJDK 8 releases.
>
> - Add support for the CATALINA_OUT_CMD environment variable that defines
>   a command to which captured stdout and stderr will be redirected. For
>   use with, for example, rotatelogs. Patch provided by Harald Dunkel.
>
> - Be more flexible with respect to the ordering of groups, roles and
>   users in the tomcat-users.xml file
>
> 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.0-M6/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1269/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M6
> 27f7ef8cd0c637b700d564ec20f6ff92901f6b5c
>
> The proposed 10.0.0-M6 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M6
>

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

[Martin Grigorov]

On Wed, Jun 3, 2020 at 11:51 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.56 release is now available for voting.
>
> The notable changes compared to the 8.5.55 release are:
>
> - Add support for ALPN on recent OpenJDK 8 releases.
>
> - Add support for the CATALINA_OUT_CMD environment variable that defines
>   a command to which captured stdout and stderr will be redirected. For
>   use with, for example, rotatelogs. Patch provided by Harald Dunkel.
>
> - Be more flexible with respect to the ordering of groups, roles and
>   users in the tomcat-users.xml file
>
> 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.56/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1271/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.56
> 4560d2f5a49965f73ed07cb879f17d9c096c9d13
>
> The proposed 8.5.56 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.56
>
>
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.36

[Martin Grigorov]

On Wed, Jun 3, 2020 at 9:06 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.36 release is now available for voting.
>
> The notable changes compared to the 9.0.35 release are:
>
> - Add support for ALPN on recent OpenJDK 8 releases.
>
> - Add support for the CATALINA_OUT_CMD environment variable that defines
>   a command to which captured stdout and stderr will be redirected. For
>   use with, for example, rotatelogs. Patch provided by Harald Dunkel.
>
> - Be more flexible with respect to the ordering of groups, roles and
>   users in the tomcat-users.xml file
>
> 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.36/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1270/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.36
> 247c8e5ad08cdcd829a0bfc6374ecb3da0e5838e
>
> The proposed 9.0.36 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.36
>


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: Update BND

[Martin Grigorov]

On Tue, Jun 2, 2020 at 5:12 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.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new a0ad185  Update BND
> a0ad185 is described below
>
> commit a0ad1855c276a3ad145f1cbe0ce4ab4bbb7ad6ab
> Author: Mark Thomas 
> AuthorDate: Tue Jun 2 15:12:03 2020 +0100
>
> Update BND
> ---
>  build.properties.default   | 9 +
>  webapps/docs/changelog.xml | 3 +++
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/build.properties.default b/build.properties.default
> index 85bb862..12af31c 100644
> --- a/build.properties.default
> +++ b/build.properties.default
> @@ -288,16 +288,17 @@
> saaj-api.loc=${base-maven.loc}/javax/xml/soap/saaj-api/${saaj-api.version}/saaj-
>
>  # - bnd & bndlib, version 4.0.0 or later  -
>  # - provides OSGI metadata for JARs   -
> -bnd.version=5.0.1
> +bnd.version=5.1.0
>
> -# checksums for biz.aQute.bnd-5.0.1.jar, biz.aQute.bndlib-5.0.1.jar
> +# checksums for biz.aQute.bnd-5.1.0.jar
>  bnd.checksum.enabled=true
>  bnd.checksum.algorithm=MD5|SHA-1
>
> -bnd.checksum.value=42cb2f3bbb5556f0182131c6543f1579|67d8bb4f274e8ecfd8ebfcdeed3b328f7078b13b
>
> +bnd.checksum.value=477684fd83707666cc84a766b147ed0c|9069bc1afad9201e3dc2efe62c0d5193777d16ae
>
> +# checksums for biz.aQute.bndlib-5.1.0.jar
>  bndlib.checksum.enabled=true
>  bndlib.checksum.algorithm=MD5|SHA-1
>
> -bndlib.checksum.value=9d29031f80e3b94e3578fea75b45c8e6|aa13aef49a74fe0bd8bbcb016df124bab5d4064e
>
> +bndlib.checksum.value=59dfe87f09e3f03be891327a91430182|30e119e5b3ae63dbb86532490855707b009e1b2e
>
>  bnd.home=${base.path}/bnd-${bnd.version}
>  bnd.jar=${bnd.home}/biz.aQute.bnd-${bnd.version}.jar
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index fe75def..67c061d 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -141,6 +141,9 @@
>  Resolver Ant Tasks to upload artifacts to the ASF Maven
> repository (and
>  from there to Maven Central). (markt)
>
> +  
> +Update dependency on bnd to 5.1.0. (markt)
> +  
>

I've just tested building Tomcat with JDK 15 b24 on x86_64 and aarch64 and
the build + test suite passed successfully!
Great!

Martin


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

Re: Tomcat Docker using AdoptOpenJDK-OpenJ9

[Martin Grigorov]

On Mon, May 18, 2020 at 2:45 PM kusuma chalasani 
wrote:

> Hi all,
>
> I'm a Performance Analyst for JVM runtime. I recently tried out some
> experiments to compare Tomcat startup performance in Docker using
> AdoptOpenJDK-OpenJ9
>
> I found I was able to get ~30% faster startup time with very minimal
> change in footprint when I enable SharedClass Cache when I compared to the
> default(which is No Shareclasses). I wrote a detailed blog post here
> https://blog.openj9.org/2020/05/18/startup-performance-of-tomcat-in-docker/   
> where
> I outlined what and how I measured.
>
> I also did raise a PR for the same -
> https://github.com/docker-library/tomcat/pull/202
>
> We figured we'd reach out to you guys so you can take a look, and maybe
> try it out and let us know if you have any comments/questions.
>

Thank you for sharing your findings with us, Kusuma!


>
>
> Thanks,
> Kusuma.
>

Re: Session serialization uses wrapper objects instead of primitives

[Martin Grigorov]

On Fri, May 15, 2020 at 1:00 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 5/14/20 14:21, Mark Thomas wrote:
> > On 14/05/2020 18:41, Christopher Schultz wrote:
> >> Mark,
> >>
> >> On 5/14/20 12:53, Mark Thomas wrote:
> >>> On 14/05/2020 17:46, Mark Thomas wrote:
>  On 14/05/2020 16:48, Christopher Schultz wrote:
> > All,
> >
> > I'm interested in the history of the
> > StandardSession.writeObjectData method. I've been looking
> > at it lately because I'm interested in possibly
> > (optionally) encrypting the sessions in the backend session
> > store. But this isn't about encryption at all.
> >
> > The code for
> > StandardSession.doWriteObject(ObjectOutputStream stream)
> > looks like this:
> >
> >
> > // Write the scalar instance variables (except Manager)
> > stream.writeObject(Long.valueOf(creationTime));
> > stream.writeObject(Long.valueOf(lastAccessedTime));
> > stream.writeObject(Integer.valueOf(maxInactiveInterval));
> > stream.writeObject(Boolean.valueOf(isNew));
> > stream.writeObject(Boolean.valueOf(isValid));
> > stream.writeObject(Long.valueOf(thisAccessedTime));
> >
> >
> > Is there any reason we are writing object wrappers for
> > these primitive members instead of just writing the
> > primitives directly?
> 
>  That code goes all the way back to at least Tomcat 3.1.x
>  (20+ years ago).
> 
> > It turns out that the byte stream is identical whether one
> > uses objects or primitives,
> 
>  That surprises me. Looking at the JRE source code it really
>  surprises me. So much that I am going to go and try it for
>  myself.
> >>
> >>> My testing shows the opposite. There is a significant
> >>> difference between writing primitives and writing objects.
> >>
> >> Hmm. I did a micro-test with just writing a single
> >> Long.valueOf() value and a (primitive) long alone to an
> >> ObjectOutputStream. I didn't test the StandardSession itself.
> >
> > I performed the same micro-test.
> >
> >>> Given backwards compatibility requirements we can't change this
> >>> in 9.0.x and earlier.
> >>
> >> Agreed.
> >>
>  One reason we might want to stick with writing objects is to
>  support sessionAttributeValueClassNameFilter. I'm only going
>  from reading the source so I could easily have missed
>  something but it looks like that will only work if we
>  write/read objects.
> >>
> >>> We only care about this for session attributes. We know our
> >>> internal attributes are safe so we could switch to primitives
> >>> in 10.0.x.
> >>
> >> I'll have to play-around a bit to see what was wrong with my
> >> initial tes t.
>
> So my test was bunk, the data on-the-wire (so to speak) is very
> different, and there is no way at all to make them compatible. :/
>
> Perhaps a rewindable input stream would work, but it's just not really
> that important.
>
> I think it's okay to make a breaking change at 10.0, but only if
> anyone really cares. It saves a couple of bytes which can add up.
>
> In my microtest, I wrote a java.lang.Long value and a (primitive) long
> to two separate files. The object-file was 82 bytes and the
> primitive-file was 14 bytes. It looks like after the 2-byte header and
> 2-byte version identifier, the primitive long is written as "block
> data" with a 1-byte length (8) and then the 8 bytes of the long. The
> object flavor is ... more verbose.
>
> So we get almost 90% savings for a single long value. On the other
> hand, the primitive only values going into sessions are the metadata
> and not the attributes, which will dominate the bulk of the data (or
> should, anyway).
>
> I still think this is worth doing.
>
> Any objections?
>

No objections!


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69sXYACgkQHPApP6U8
> pFi6pg/9ExBQhRRlUv4QPUVDJEhJ8pN6KfBIoHgd/UWw2zYxjeifhDrN+biK2lLG
> GHWmJuF+wEAFz9xtYqN46q1QqSKIQcWTAqI05NchNlqFd29JHwj+9QZV00VTd0eK
> My4MTCVY4dSObJrePyw14tEHyRVcFl539bDhtez7fnjOGkq4EGNXvr7ep9L3w5GB
> ckwKAp1OuFYz5/0ZCCDEVdRiSpoXAac06B5v0FUQb3TBn06gdavUJb9q0HM57RjI
> 0FkQHPyZ1ibfWOOLldBrCgA+7SygGiD6LO2nMo5Fgy1A4l5W/uekkhW96FXBKHng
> /ocXJRQSkeDoanpQmu5pC/Ru1S0bNjZCIo9OMS0de6iEMEO3wPtvuLYhINYydk6E
> 3ZNx+EPZEFPoZuB1K0peWNDgFsE3ar5gL+y6cvztNoZtT1WymoDS6uQ4OvGXcXNL
> 61SOSe3CmqHF0dQTlD/Xikakumz4Kefny5QGw/XlchPVNCqUmvgxUwYPb965kwz3
> Vt/3nib0QgKxbR0j54InFIRkG7gPuGyUaL0kwtMbFEdOTw+PqAEyIPSqIRtmkhVG
> Mzf6ikh+TOToYi+OIJXUMloaVL8xafAo6hKTc7lbu2hAUv9bE47X6uVyQmD7Yxqu
> R3LQGo3OYX9+GBdKBhgvbZB9bEkUImMbsgIXKIUScGaMH4RdtBE=
> =AZle
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tom

Re: [VOTE] Release Apache Tomcat 7.0.104

[Martin Grigorov]

On Thu, May 7, 2020 at 11:17 PM Violeta Georgieva 
wrote:

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

Tested the .tar.gz binary with Apache Wicket 7.x examples.

Regards,
Martin



>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 10.0.0-M5

[Martin Grigorov]

On Tue, May 5, 2020 at 10:34 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M5 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 major changes compared to 10.0.0-M4 are:
>
> - Remove useAprConnector flag from AprLifecycleListener so that the
>   only way to use the APR connectors is to set the full class name.
>
> - Change default value separator for property replacement to ":-"
>   due to possible conflicts. The syntax is now "${name:-default}".
>
> - Update the packaged version of the Tomcat Native Library to 1.2.24.
>
> 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.0-M5/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1265/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M5
> b3a208c6d6d01c553178c5e718e750b0eb318151
>
> The proposed 10.0.0-M5 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M5
>


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

[Martin Grigorov]

On Wed, May 6, 2020 at 1:38 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.55 release is now available for voting.
>
> The major changes compared to the 8.5.54 release are:
>
> - Improve the handling of requests that use an expectation. Do not
>   disable keep-alive where the response has a non-2xx status code
>   but the request body has been fully read.
>
> - Change default value separator for property replacement to ":-"
>   due to possible conflicts. The syntax is now "${name:-default}".
>
> - Update the packaged version of the Tomcat Native Library to 1.2.24.
>
> 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.55/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1267/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.55
> c8a57e4a2db8e5af314bae48123fb5990da5b7a5
>
> The proposed 8.5.55 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.55
>

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

[Martin Grigorov]

On Wed, May 6, 2020 at 12:41 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.35 release is now available for voting.
>
> The major changes compared to the 9.0.34 release are:
>
> - Improve the handling of requests that use an expectation. Do not
>   disable keep-alive where the response has a non-2xx status code
>   but the request body has been fully read.
>
> - Change default value separator for property replacement to ":-"
>   due to possible conflicts. The syntax is now "${name:-default}".
>
> - Update the packaged version of the Tomcat Native Library to 1.2.24.
>
> 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.35/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1266/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.35
> fc2c65d390444d75412855ad0de8b878018d02dc
>
> The proposed 9.0.35 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.35
>

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: Fix BZ 64403 Compressed h2 responses should not have C-L header

[Martin Grigorov]

On Mon, May 4, 2020 at 11:06 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.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 956d9f7  Fix BZ 64403 Compressed h2 responses should not have C-L
> header
> 956d9f7 is described below
>
> commit 956d9f70279f35da45d63922607b328f44a5f776
> Author: Mark Thomas 
> AuthorDate: Mon May 4 21:06:16 2020 +0100
>
> Fix BZ 64403 Compressed h2 responses should not have C-L header
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64403
> ---
>  java/org/apache/coyote/http2/StreamProcessor.java  | 19 ++---
>  .../apache/coyote/http2/TestStreamProcessor.java   | 81
> ++
>  webapps/docs/changelog.xml |  5 ++
>  3 files changed, 97 insertions(+), 8 deletions(-)
>
> diff --git a/java/org/apache/coyote/http2/StreamProcessor.java
> b/java/org/apache/coyote/http2/StreamProcessor.java
> index 15bfcab..e03f307 100644
> --- a/java/org/apache/coyote/http2/StreamProcessor.java
> +++ b/java/org/apache/coyote/http2/StreamProcessor.java
> @@ -147,6 +147,17 @@ class StreamProcessor extends AbstractProcessor {
>  // Add the pseudo header for status
>
>  headers.addValue(":status").setString(Integer.toString(statusCode));
>
> +
> +// Compression can't be used with sendfile
> +// Need to check for compression (and set headers appropriately)
> before
> +// adding headers below
> +if (noSendfile && protocol != null &&
> +protocol.useCompression(coyoteRequest, coyoteResponse)) {
> +// Enable compression. Headers will have been set. Need to
> configure
> +// output filter at this point.
> +stream.addOutputFilter(new GzipOutputFilter());
> +}
> +
>  // Check to see if a response body is present
>  if (!(statusCode < 200 || statusCode == 204 || statusCode == 205
> || statusCode == 304)) {
>  String contentType = coyoteResponse.getContentType();
> @@ -178,14 +189,6 @@ class StreamProcessor extends AbstractProcessor {
>  if (statusCode >= 200 && headers.getValue("date") == null) {
>
>  headers.addValue("date").setString(FastHttpDateFormat.getCurrentDate());
>  }
> -
> -// Compression can't be used with sendfile
> -if (noSendfile && protocol != null &&
> -protocol.useCompression(coyoteRequest, coyoteResponse)) {
> -// Enable compression. Headers will have been set. Need to
> configure
> -// output filter at this point.
> -stream.addOutputFilter(new GzipOutputFilter());
> -}
>  }
>
>
> diff --git a/test/org/apache/coyote/http2/TestStreamProcessor.java
> b/test/org/apache/coyote/http2/TestStreamProcessor.java
> index 214a65e..e72be5f 100644
> --- a/test/org/apache/coyote/http2/TestStreamProcessor.java
> +++ b/test/org/apache/coyote/http2/TestStreamProcessor.java
> @@ -18,6 +18,7 @@ package org.apache.coyote.http2;
>
>  import java.io.File;
>  import java.io.IOException;
> +import java.io.OutputStream;
>  import java.io.PrintWriter;
>  import java.nio.ByteBuffer;
>  import java.util.ArrayList;
> @@ -34,6 +35,7 @@ import org.junit.Test;
>
>  import org.apache.catalina.Context;
>  import org.apache.catalina.Wrapper;
> +import org.apache.catalina.connector.Connector;
>  import org.apache.catalina.startup.Tomcat;
>  import org.apache.tomcat.util.compat.JrePlatform;
>  import org.apache.tomcat.util.http.FastHttpDateFormat;
> @@ -223,4 +225,83 @@ public class TestStreamProcessor extends
> Http2TestBase {
>  });
>  }
>  }
> +
> +
> +@Test
> +public void testCompression() throws Exception {
> +enableHttp2();
> +
> +Tomcat tomcat = getTomcatInstance();
> +
> +Context ctxt = tomcat.addContext("", null);
> +Tomcat.addServlet(ctxt, "simple", new SimpleServlet());
> +ctxt.addServletMappingDecoded("/simple", "simple");
> +Tomcat.addServlet(ctxt, "compression", new CompressionServlet());
> +ctxt.addServletMappingDecoded("/compression", "compression");
> +
>




> +// Enable compression for the LargeServlet
>

What is LargeServlet ?
There are only SimpleServlet and CompressionServlet in this test.


> +Connector connector = tomcat.getConnector();
> +Assert.assertTrue(connector.setProperty("compression", "on"));
> +
> +tomcat.start();
> +
> +enableHttp2();
> +openClientConnection();
> +doHttpUpgrade();
> +sendClientPreface();
> +validateHttp2InitialResponse();
> +
> +
> +byte[] frameHeader = new byte[9];
> +ByteBuffer headersPayload = ByteBuffer.allocate(128);
> +
> +List headers = new ArrayList<>(3);
> +headers.add(new Header(":method", "GET"));
> +headers.add(new Header(":schem

Re: OpenJDK 15 EA build 21 is now available

[Martin Grigorov]

Hi,

On Fri, May 1, 2020 at 9:41 PM Martin Grigorov  wrote:

> Hi,
>
> I think this is the same issue I had in Apache Wicket with the last two
> builds of JDK 15.
> I'll send more details tomorrow.
> But I worked it around by using aQute 5.1-SNAPSHOT.
>

The problem is not exactly the same as in Wicket:

Caused by: java.util.ConcurrentModificationException
at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
at java.util.TreeMap.computeIfAbsent (TreeMap.java:596)
at aQute.bnd.osgi.Jar.putResource (Jar.java:337)
at aQute.bnd.osgi.Jar$2.visitFile (Jar.java:252)
at aQute.bnd.osgi.Jar$2.visitFile (Jar.java:227)
at java.nio.file.Files.walkFileTree (Files.java:2804)
at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:226)
at aQute.bnd.osgi.Jar. (Jar.java:128)
at aQute.bnd.osgi.Jar. (Jar.java:198)
at aQute.bnd.osgi.Analyzer.addClasspath (Analyzer.java:2471)
at aQute.bnd.maven.plugin.AbstractBndMavenPlugin.execute
(AbstractBndMavenPlugin.java:190)


It has been fixed with:
https://github.com/bndtools/bnd/issues/3903
https://github.com/bndtools/bnd/commit/97eb299a8b4b3d1b199b30d98769136494e2469d#diff-8dd8393f6487d4e378e923003227cf57

I don't see any recent improvements around
aQute.bnd.ant.WrapTask.execute(WrapTask.java:122) (
https://github.com/bndtools/bnd/commits/master/biz.aQute.bnd/src/aQute/bnd/ant/WrapTask.java
)

Martin


> Regards,
> Martin
>
> On Fri, May 1, 2020, 19:53 Rory O'Donnell 
> wrote:
>
>> Thanks for the headsup Mark, let's us know the bugid when you get a
>> chance.
>>
>> Rgds,Rory
>>
>> On 01/05/2020 17:10, Mark Thomas wrote:
>> > On 01/05/2020 10:28, Rory O'Donnell wrote:
>> >> Hi Mark,
>> >>
>> >> OpenJDK 15 EA build 21 is now available at http://jdk.java.net/15 *
>> > Heads up all. There appears to be a regression in this build compared to
>> > EA build 13.
>> >
>> > It appears to be related to JAR file manipulation when the OSGi
>> > information is added.
>> >
>> > I haven't had a chance to dig into this further but I wanted to give
>> > folks a heads up.
>> >
>> > This is the full stack trace:
>> >
>> > /home/mark/repos/asf-tomcat-master/build.xml:790: The following error
>> > occurred while executing this line:
>> > /home/mark/repos/asf-tomcat-master/build.xml:3389: The following error
>> > occurred while executing this line:
>> > /home/mark/repos/asf-tomcat-master/build.xml:3404: Failed to build jar
>> > file: java.util.ConcurrentModificationException
>> >   at aQute.bnd.ant.WrapTask.execute(WrapTask.java:122)
>> >   at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
>> >   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
>> Source)
>> >   at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>> >   at
>> >
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>> >   at org.apache.tools.ant.Task.perform(Task.java:352)
>> >   at org.apache.tools.ant.Target.execute(Target.java:437)
>> >   at org.apache.tools.ant.Target.performTasks(Target.java:458)
>> >   at
>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1406)
>> >   at
>> >
>> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
>> >   at org.apache.tools.ant.Project.executeTargets(Project.java:1261)
>> >   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
>> >   at
>> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
>> >   at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
>> >   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
>> Source)
>> >   at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>> >   at
>> >
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>> >   at org.apache.tools.ant.Task.perform(Task.java:352)
>> >   at
>> org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:67)
>> >   at
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
>> >   

Re: OpenJDK 15 EA build 21 is now available

[Martin Grigorov]

Hi,

I think this is the same issue I had in Apache Wicket with the last two
builds of JDK 15.
I'll send more details tomorrow.
But I worked it around by using aQute 5.1-SNAPSHOT.

Regards,
Martin

On Fri, May 1, 2020, 19:53 Rory O'Donnell  wrote:

> Thanks for the headsup Mark, let's us know the bugid when you get a chance.
>
> Rgds,Rory
>
> On 01/05/2020 17:10, Mark Thomas wrote:
> > On 01/05/2020 10:28, Rory O'Donnell wrote:
> >> Hi Mark,
> >>
> >> OpenJDK 15 EA build 21 is now available at http://jdk.java.net/15 *
> > Heads up all. There appears to be a regression in this build compared to
> > EA build 13.
> >
> > It appears to be related to JAR file manipulation when the OSGi
> > information is added.
> >
> > I haven't had a chance to dig into this further but I wanted to give
> > folks a heads up.
> >
> > This is the full stack trace:
> >
> > /home/mark/repos/asf-tomcat-master/build.xml:790: The following error
> > occurred while executing this line:
> > /home/mark/repos/asf-tomcat-master/build.xml:3389: The following error
> > occurred while executing this line:
> > /home/mark/repos/asf-tomcat-master/build.xml:3404: Failed to build jar
> > file: java.util.ConcurrentModificationException
> >   at aQute.bnd.ant.WrapTask.execute(WrapTask.java:122)
> >   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
> >   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
> >   at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> >   at
> >
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> >   at org.apache.tools.ant.Task.perform(Task.java:352)
> >   at org.apache.tools.ant.Target.execute(Target.java:437)
> >   at org.apache.tools.ant.Target.performTasks(Target.java:458)
> >   at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1406)
> >   at
> >
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
> >   at org.apache.tools.ant.Project.executeTargets(Project.java:1261)
> >   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> >   at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> >   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
> >   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
> >   at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> >   at
> >
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> >   at org.apache.tools.ant.Task.perform(Task.java:352)
> >   at
> org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:67)
> >   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
> >   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
> >   at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> >   at
> >
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> >   at org.apache.tools.ant.Task.perform(Task.java:352)
> >   at
> >
> org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:401)
> >   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
> >   at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown
> Source)
> >   at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> >   at
> >
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> >   at org.apache.tools.ant.Task.perform(Task.java:352)
> >   at org.apache.tools.ant.Target.execute(Target.java:437)
> >   at org.apache.tools.ant.Target.performTasks(Target.java:458)
> >   at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1406)
> >   at org.apache.tools.ant.Project.executeTarget(Project.java:1377)
> >   at
> >
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> >   at org.apache.tools.ant.Project.executeTargets(Project.java:1261)
> >   at org.apache.tools.ant.Main.runBuild(Main.java:857)
> >   at org.apache.tools.ant.Main.startAnt(Main.java:236)
> >   at org.apache.tools.ant.launch.Launcher.run(Launcher.java:287)
> >   at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
> >
> >
> >
> > Mark
> >
> >
> >> *
> >>
> >>* These early-access , open-source builds are provided under the
> >>o GNU General Public Lic

Re: git-fu is (still) weak

[Martin Grigorov]

Hi Chris,

On Tue, Apr 28, 2020 at 5:58 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Coty,
>
> On 4/28/20 10:45, Coty Sutherland wrote:
> >
> >
> > On Tue, Apr 28, 2020 at 10:21 AM Christopher Schultz
> >  > >
> wrote:
> >
> > Rémy,
> >
> > On 4/27/20 18:41, Rémy Maucherat wrote:
> >> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz
> >>  >> 
> >>  > >> wrote:
> >
> >> All,
> >
> >> I tried again to commit to tc10 branch, got commit id
> >> 8dddc11512fbd3b91ed9d737a42e4b8415458ddf.
> >
> >> Moving to tc9 branch:
> >
> >> $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
> >> fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
> >
> >> - From tc10:
> >
> >> $ git remote -v origin  https://github.com/apache/tomcat (fetch)
> >> origin  https://github.com/apache/tomcat (push)
> >
> >> - From tc9.0.x:
> >
> >> $ git remote -v origin  https://github.com/apache/tomcat (fetch)
> >> origin  https://github.com/apache/tomcat (push)
> >
> >> My 9.0.x local is all up-to-date with github, and github can see
> >> the commit in tc10.
> >
> >> Other than manually handing the diffs myself, I have no idea
> >> what to do, next. :(
> >
> >
> >>> I tried and it looked "ok" to me.
> >
> > Okay, what did you do? When I try to cherry-pick from 10 -> 9 I
> > still get the "bad object" error.
> >
> > When cherry-picking your commits from 9.0.x -> 8.5.x, I get a
> > merge-conflict (of course) because you have already merged them.
> >
> > Did I do something weird with the first commit?
> >
> > Maybe I don't have my branches in order?
> >
> > - From my tomcat-trunk (10) directory:
> >
> > $ git branch -a 9.0.x * master remotes/origin/7.0.x
> > remotes/origin/8.5.x remotes/origin/9.0.x
> > remotes/origin/BZ-63636/tomcat-8.5.x
> > remotes/origin/BZ-63636/tomcat-9.0.x remotes/origin/BZ-63681/8.5.x
> > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/8.5.x
> > remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master
> > remotes/origin/master
> >
> > - From my tomcat-9.0.x directory:
> >
> > $ git branch -a * 9.0.x master remotes/origin/9.0.x
> >
> > - From my tomcat-8.5.x directory:
> >
> > $ git branch -a * 8.5.x remotes/origin/7.0.x remotes/origin/8.5.x
> > remotes/origin/9.0.x remotes/origin/BZ-63681/8.5.x
> > remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/9.0.x
> > remotes/origin/HEAD -> origin/master remotes/origin/master
> >
> > My 9.0.x checkout seems "light".
> >
> >
> >> Have you tried a `git fetch origin master` from your 9.0 dir?
> >> That'll update the gitdb with new objects and refs from master,
> >> which should include the one you're trying to pick. That's the
> >> only thing I can think of given that you know your object ID is
> >> correct and present in master on upstream :)
>
> That got 'er goin'!
>
> It definitely fetched a bunch of stuff, but no new files, etc.
> (because becasue I was "up-to-date"). How can I be "up-to-date"
> without being "up-to-date"? :(
>

I see these options for you:

1) don't use several directories for the different branches.
Use just one and switch between branches:
git checkout master / git checkout 9.0.x / git checkout 8.5.x

2) use https://git-scm.com/docs/git-worktree if you prefer to have separate
folder for each branch


>
> Maybe now I can go back and merge the original commits from this
> thread from February.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oRIAACgkQHPApP6U8
> pFhtsA/9HHIvXZSbOsJuiBSkc0mBLonbtnvu5SOGizvcHZwPymfQgv+SC4yxiam+
> oAXEcBOfXnFG+bdBeD80F16xQOXDOT1ndSwMASA2LzdG2iDqSVVD2DvoqX3Sna3N
> +5Rp40GpIpctVLaz6rp/xTey9pZhFGy+qAjV6lssykU2Dm0trh8JNsWW4qd5Dd14
> RjLSVPN3fmxJ71hXJ3s5X8AufJmxi/TnMfC5h883WpyCM6Wsd1S7E4joXLPXt3LT
> qt82OBCpG23TIAM3CWeBykuKtbpnQ7eSmvMUPiBf8mG/6YoiBoGwuswsZPpDnLj6
> 6j4ni9IjSbPbbt7n5DBFa+QDZ6huIWH5iKcrX27ytQxVDHgDK5J9evHaTK9DbdqW
> xdFdpJ5q2swC+EhZmzz524jQWWcXsUIR0kABtT8MRlW33/5Q23m9ImBu9u58Ep+m
> vGmg8wCezCXAybCYQ86yjVICIINCd4GErrqh5KPbzMfOmTrvi0CTiqiJl9bsLdXr
> MpgbLlKzuaOswFVeI/KbfkKquWZedQVB9Ult2fDNtpRPuqxpjeyJAgu4gTtuwXy4
> +Mr+YFO9zaS49wxBo92L7ZqVn2tYPiMdzxj+39xMKwt5lj+76gq9Iyn7leKxrEZM
> skqHJql7EgIwZ+xTVPlAdtERvbq6FkBHAnJxqAYDydkTVSC7CKY=
> =9c6q
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat Native 1.2.24

[Martin Grigorov]

On Fri, Apr 24, 2020 at 11:10 PM Mark Thomas  wrote:

> Version 1.2.24 includes the following changes compared to 1.2.23
>
> - Various improvements to the build process related to OpenSSL
>
> - Windows binaries built with OpenSSL 1.1.1g
>
> Various other fixes and improvements. See the changelog for details.
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.24 release is
>  [ X ] Stable, go ahead and release
>  [ ] Broken because of ...
>

Tested with OpenSSL 1.1.1 HEAD, Apr 1.6.x and Tomcat 9.x on Ubuntu 18.04
x86_64 and ARM64.

Regards,
Martin


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

Re: Time for Tomcat Native 1.2.24?

[Martin Grigorov]

Hi,

On Wed, Apr 22, 2020 at 1:34 PM Mark Thomas  wrote:

> Hi all,
>
> You have probably seen this:
> OpenSSL - CVE-2020-1967
> https://openssl.markmail.org/thread/nuamcatocap7rwrw
>
> I have reviewed the Tomcat Native code and confirmed that we do not call
> SSL_check_chain() at any point.
>
> I also looked at the OpenSSL code as I was concerned that we might hit
> the same problem via an internal code path. It appears I wasn't the only
> one with that concern and the OpenSSL team confirmed that the issue only
> occurs when calling SSL_check_chain():
> https://openssl.markmail.org/thread/okfaim5oqhh2egj6
>
> Therefore, it is not necessary to roll a new Tomcat Native release to
> pick up an updated OpenSSL version for the Windows binaries.
>
> That said, there are a few Tomcat Native fixes since 1.2.23 and it has
> been 9 months since the last release. We should have enough time to get
> a 1.2.24 release out if we want to.
>
> Thoughts?
>

+1
I use a build from master branch for my testing application and I didn't
have any problems with it!

Regards,
Martin


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

Re: [tomcat-jakartaee-migration] 02/02: Test the migration of signed jar files

[Martin Grigorov]

On Mon, Apr 20, 2020 at 10:58 AM Martin Grigorov 
wrote:

> Hi,
>
> On Mon, Apr 20, 2020 at 3:03 AM  wrote:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> ebourg pushed a commit to branch master
>> in repository
>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>>
>> commit f23a64982f793ebe43665466cf780f57979e63d4
>> Author: Emmanuel Bourg 
>> AuthorDate: Mon Apr 20 02:02:55 2020 +0200
>>
>> Test the migration of signed jar files
>> ---
>>  pom.xml|  15 +++
>>  .../org/apache/tomcat/jakartaee/MigrationTest.java |  29
>> +
>>  src/test/resources/keystore.p12| Bin 0 -> 3848 bytes
>>  3 files changed, 44 insertions(+)
>>
>> diff --git a/pom.xml b/pom.xml
>> index b66f833..3ddfc68 100644
>> --- a/pom.xml
>> +++ b/pom.xml
>> @@ -136,6 +136,21 @@
>>  > value="1.2.3"/>
>>
>>  
>> +
>> +
>> +  
>> +> tofile="target/test-classes/hellocgi-signed-rsa.jar"/>
>> +> jar="target/test-classes/hellocgi-signed-rsa.jar"
>> keystore="src/test/resources/keystore.p12" storepass="apache" alias="rsa"/>
>> +  
>> +  
>> +> tofile="target/test-classes/hellocgi-signed-dsa.jar"/>
>> +> jar="target/test-classes/hellocgi-signed-dsa.jar"
>> keystore="src/test/resources/keystore.p12" storepass="apache" alias="dsa"/>
>> +  
>> +  
>> +> tofile="target/test-classes/hellocgi-signed-ec.jar"/>
>> +> jar="target/test-classes/hellocgi-signed-ec.jar"
>> keystore="src/test/resources/keystore.p12" storepass="apache" alias="ec"/>
>> +  
>> +
>>
>>  
>>
>> diff --git a/src/test/java/org/apache/tomcat/jakartaee/MigrationTest.java
>> b/src/test/java/org/apache/tomcat/jakartaee/MigrationTest.java
>> index 9ba59b0..418b57f 100644
>> --- a/src/test/java/org/apache/tomcat/jakartaee/MigrationTest.java
>> +++ b/src/test/java/org/apache/tomcat/jakartaee/MigrationTest.java
>> @@ -163,4 +163,33 @@ public class MigrationTest {
>>  assertNotEquals("Implementation-Version manifest attribute not
>> changed", "1.2.3", implementationVersion);
>>  assertTrue("Implementation-Version manifest attribute doesn't
>> match the expected pattern",
>> implementationVersion.matches("1\\.2\\.3-migrated-[\\d\\.]+.*"));
>>  }
>> +
>> +@Test
>> +public void testMigrateSignedJarFileRSA() throws Exception {
>> +testMigrateSignedJarFile("rsa");
>> +}
>> +
>> +@Test
>> +public void testMigrateSignedJarFileDSA() throws Exception {
>> +testMigrateSignedJarFile("dsa");
>> +}
>> +
>> +@Test
>> +public void testMigrateSignedJarFileEC() throws Exception {
>> +testMigrateSignedJarFile("ec");
>> +}
>> +
>> +private void testMigrateSignedJarFile(String algorithm) throws
>> Exception {
>> +File jarFile = new File("target/test-classes/hellocgi-signed-" +
>> algorithm + ".jar");
>> +
>> +Migration migration = new Migration();
>> +migration.setSource(jarFile);
>> +migration.setDestination(jarFile);
>> +migration.execute();
>> +
>> +JarFile jar = new JarFile(jarFile);
>> +assertNull("Digest not removed from the manifest",
>> jar.getManifest().getAttributes("org/apache/tomcat/jakartaee/HelloCGI.class"));
>> +assertNull("Signature key not removed", jar.getEntry("META-INF/"
>> + algorithm.toUpperCase() + "." + algorithm.toUpperCase()));
>> +assertNull("Signed manifest not removed",
>> jar.getEntry("META-INF/" + algorithm.toUpperCase() + ".SF"));
>>
>
> assertNull ?!
> I'd expect those to be non-null, i,e. preserved, after the migration.
>
>
Maybe I didn't understand the test.
Recently there was a complaint that if the signing is not preserved then
crypto functionality does not work (bcrypt ?!).
I will re-check the history and the latest implementation and I'll come
back!


> Martin
>
>
>> +}
>>  }
>> diff --git a/src/test/resources/keystore.p12
>> b/src/test/resources/keystore.p12
>> new file mode 100644
>> index 000..6f1cf7a
>> Binary files /dev/null and b/src/test/resources/keystore.p12 differ
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>