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

2020-10-16 Thread 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

2020-10-07 Thread 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

2020-10-07 Thread 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

2020-10-07 Thread 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

2020-10-02 Thread 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

2020-10-02 Thread 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

2020-10-02 Thread 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

2020-09-29 Thread 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

2020-09-29 Thread 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)

2020-09-28 Thread 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)

2020-09-28 Thread 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

2020-09-28 Thread 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)

2020-09-28 Thread 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

2020-09-24 Thread 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

2020-09-22 Thread 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

2020-09-18 Thread 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

2020-09-15 Thread 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()

2020-09-15 Thread 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

2020-09-15 Thread 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

2020-09-11 Thread 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 

Re: [VOTE] Release Apache Tomcat 8.5.58

2020-09-11 Thread 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

2020-09-11 Thread 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

2020-09-11 Thread 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

2020-09-10 Thread 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

2020-08-28 Thread 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

2020-08-26 Thread 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

2020-08-25 Thread 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

2020-08-11 Thread 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

2020-08-10 Thread 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

2020-08-07 Thread 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

2020-08-05 Thread 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

2020-07-22 Thread 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

2020-07-22 Thread 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

2020-07-20 Thread 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

2020-07-13 Thread 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,\
> > +

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

2020-07-10 Thread 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é

2020-07-02 Thread 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

2020-07-02 Thread 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

2020-07-01 Thread 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

2020-07-01 Thread 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

2020-07-01 Thread 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

2020-06-22 Thread 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

2020-06-16 Thread 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

2020-06-10 Thread 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

2020-06-10 Thread 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)

2020-06-09 Thread 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 ?!

2020-06-09 Thread 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 ?!

2020-06-09 Thread 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

2020-06-08 Thread 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

2020-06-05 Thread 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.SynchronizedStack.push
>> >
>> >  

Usage of SynchronizedStack/Queue

2020-06-04 Thread 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] 

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

2020-06-04 Thread 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

2020-06-04 Thread 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

2020-06-04 Thread 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

2020-06-04 Thread 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

2020-06-03 Thread 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

2020-05-21 Thread 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

2020-05-15 Thread 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: 

Re: [VOTE] Release Apache Tomcat 7.0.104

2020-05-13 Thread 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

2020-05-07 Thread 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

2020-05-07 Thread 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

2020-05-07 Thread 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

2020-05-04 Thread 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 

Re: OpenJDK 15 EA build 21 is now available

2020-05-01 Thread 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)
>> >   at jdk.internal

Re: OpenJDK 15 EA build 21 is now available

2020-05-01 Thread 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 

Re: git-fu is (still) weak

2020-04-29 Thread 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

2020-04-27 Thread 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?

2020-04-22 Thread 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

2020-04-20 Thread 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
>>
>>


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

2020-04-20 Thread Martin Grigorov
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.

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


Re: [VOTE] Release Apache Tomcat 8.5.54

2020-04-05 Thread Martin Grigorov
On Fri, Apr 3, 2020 at 5:30 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.54 release is now available for voting.
>
> The major changes compared to the 8.5.53 release are:
>
> - Add support for default values when using ${...} property replacement
>   in configuration files. Based on a pull request provided by Bernd
>   Bohmann.
>
> - When configuring an HTTP Connector, warn if the encoding specified for
>   URIEncoding is not a superset of US-ASCII as required by RFC7230.
>
> - Replace the system property
>   org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH with the
>   Connector attribute encodedSolidusHandling that adds an additional
>   option to pass the %2f sequence through to the application without
>   decoding it in addition to rejecting such sequences and decoding such
>   sequences.
>
> 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.54/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1264/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.54
> 0b365bb7032a5e30b35fedc56e7def82a3e55f94
>
> The proposed 8.5.54 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.54
>

Tested with Apache Wicket examples application.

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

2020-04-05 Thread Martin Grigorov
On Fri, Apr 3, 2020 at 3:49 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.34 release is now available for voting.
>
> The major changes compared to the 9.0.34 release are:
>
> - Add support for default values when using ${...} property replacement
>   in configuration files. Based on a pull request provided by Bernd
>   Bohmann.
>
> - When configuring an HTTP Connector, warn if the encoding specified for
>   URIEncoding is not a superset of US-ASCII as required by RFC7230.
>
> - Replace the system property
>   org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH with the
>   Connector attribute encodedSolidusHandling that adds an additional
>   option to pass the %2f sequence through to the application without
>   decoding it in addition to rejecting such sequences and decoding such
>   sequences.
>
> 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.34/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1263/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.34
> 1031a8edb864ac001a8f172161aa8a13b7a4e712
>
> The proposed 9.0.34 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.34
>
>
Tested with Apache Wicket examples application.

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

2020-04-05 Thread Martin Grigorov
On Fri, Apr 3, 2020 at 2:28 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M4 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-M3  are:
>
> - Replace configuration via system property with configuration via an
>   attribute on the appropriate element where practical. A large number
>   of system properties have been replaced.
>
> - Add support for default values when using ${...} property replacement
>   in configuration files. Based on a pull request provided by Bernd
>   Bohmann.
>
> - Replace the system property
>   org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH with the
>   Connector attribute encodedSolidusHandling that adds an additional
>   option to pass the %2f sequence through to the application without
>   decoding it in addition to rejecting such sequences and decoding such
>   sequences.
>
>
> 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-M4/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1261/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M4
> 772df65db45cfccc2aad33b9b51ef9ab14c19626
>
> The proposed 10.0.0-M4 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M4
>

Tested with Apache Wicket examples application.

Regards,
Martin


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


Re: Tomcat Version 7.0.100: Service Loader no logging statements

2020-03-27 Thread Martin Grigorov
Hi,

On Thu, Mar 26, 2020 at 11:23 PM Rémy Maucherat  wrote:

> On Thu, Mar 26, 2020 at 9:16 PM Christopher O'Connell <
> coconnel...@gmail.com> wrote:
>
>> The Tomcat release version 7.0.100 introduced a bug that prevented
>> ServiceLoaders from being started. This was fixed by the ticket:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 (Thank you for
>> the fix)
>>
>> This problem ended up causing an application I was working on from
>> running correctly. In an attempt to resolve, I tried turning up
>> logging but there does not appear to be any logging in this section of
>> the code, error or otherwise.
>>
>> Would it be possible to add additional logging, specifically in the
>> WebappServiceLoader.java class? I'd be willing to submit code to
>> address this concern.
>>
>
> -1
> Adding useless verbose logging just to reassure you that there's no bug in
> the container is quite pointless. SCI processing is not something that is
> complex, and if your SCI is found you can log there.
>

The benefit of having the log statement (as DEBUG) in Tomcat's code base is
that the developer can see all SCI impls being used in the application, not
just "mine SCI".
And often "mine SCI" is not really mine but provided by some web framework
like Spring MVC, RestEasy, etc. If those have their own log statements then
I could enable them one by one. But it is possible that they won't have
such too.
Is there any harm of having such log statement in Tomcat ? It loads those
classes at application start time so it is not a hot path.

My 2c.
Martin


>
> Rémy
>
>
>>
>> Thanks,
>>
>> 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.103

2020-03-17 Thread Martin Grigorov
Hi,

On Mon, Mar 16, 2020 at 11:13 AM Violeta Georgieva 
wrote:

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

Tested with Apache Wicket 7.x examples.

Regards,
Martin


>
> Regards,
> Violeta
>


Re: [VOTE] Release Apache Tomcat 8.5.53

2020-03-14 Thread Martin Grigorov
On Wed, Mar 11, 2020 at 1:18 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.53 release is now available for voting.
>
> The major changes compared to the 8.5.51 release are:
>
> - Add new attribute persistAuthentication to both StandardManager and
>   PersistentManager to support authentication persistence.
>   Patch provided by Carsten Klein
>
> - A zero length AJP secret will now behave as if it has not been
>   specified.
>
> - Add the TLS request attributes used by IIS to the attributes that
>   an AJP Connector will always accept.
>
>
> 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.53/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1258/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.53
> 9babbd0b0560303fbe5cc5bf7e7c2a8e74e4d665
>
> The proposed 8.5.53 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.53
>


Regards,
Martin


>
> -
> 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: Add javax.(decorator|enterprise|inject) as ones which should be migrated

2020-03-13 Thread Martin Grigorov
Hi Rémy,

On Fri, Mar 13, 2020 at 12:27 PM Rémy Maucherat  wrote:

> On Fri, Mar 13, 2020 at 11:00 AM Martin Grigorov 
> wrote:
>
>> Hi Rémy,
>>
>> On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat  wrote:
>>
>>> On Thu, Mar 12, 2020 at 3:10 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-jakartaee-migration.git
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>  new 8dd0dde  Add javax.(decorator|enterprise|inject) as ones which
>>>> should be migrated
>>>> 8dd0dde is described below
>>>>
>>>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
>>>> Author: Martin Tzvetanov Grigorov 
>>>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200
>>>>
>>>> Add javax.(decorator|enterprise|inject) as ones which should be
>>>> migrated
>>>>
>>>> Those are needed for CDI applications
>>>>
>>>
>>> Well, it's needed if there is a jakarta implementation of CDI [do you
>>> have one ? ...]. Right now that's not the case and it will mess things up
>>> since it's possible to use Tomcat 10 with a javax CDI and a converted
>>> webapp.
>>> See the modules/owb wrapper for example.
>>>
>>
>>> So it's a bit messy and this would need to be configurable for now.
>>>
>>
>> Here is how I understand it:
>> 1) if you deploy in EE server, like Wildfly and Glassfish, then both
>> cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
>> server and they are not part of the application, so nothing will be migrated
>> 2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
>> and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
>> are migrated and everything works
>>
>> In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
>> jakarta packages are prefered than javax ones.
>>
>> Do you see a use case that is not supported at the moment ?
>>
>
> There's no point in migrating code that doesn't need to be migrated, so I
> don't understand what you are using this for. If the user is using a
> package like modules/owb, then it won't work.
>

You neither explain a breaking use case nor modules/owb has any
documentation :-/
But I will take your word and revert my change.

If we should follow Romain's suggestion then probably ejb, mail,
persistence and transaction should not be in this regexp as well.

Martin


>
> Rémy
>
>
>>
>> Martin
>>
>>
>>>
>>> Rémy
>>>
>>>
>>>> ---
>>>>  src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>>> index 21e0fbf..701134d 100644
>>>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern;
>>>>  public class Util {
>>>>
>>>>  private static Pattern PATTERN = Pattern.compile(
>>>> -
>>>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
>>>> +
>>>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
>>>> ++ ".]message|servlet|transaction|websocket))");
>>>>
>>>>  /**
>>>>   * Get the extension of a filename
>>>>
>>>>
>>>> -
>>>> 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: Add javax.(decorator|enterprise|inject) as ones which should be migrated

2020-03-13 Thread Martin Grigorov
Hi Rémy,

On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat  wrote:

> On Thu, Mar 12, 2020 at 3:10 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-jakartaee-migration.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 8dd0dde  Add javax.(decorator|enterprise|inject) as ones which
>> should be migrated
>> 8dd0dde is described below
>>
>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
>> Author: Martin Tzvetanov Grigorov 
>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200
>>
>> Add javax.(decorator|enterprise|inject) as ones which should be
>> migrated
>>
>> Those are needed for CDI applications
>>
>
> Well, it's needed if there is a jakarta implementation of CDI [do you have
> one ? ...]. Right now that's not the case and it will mess things up since
> it's possible to use Tomcat 10 with a javax CDI and a converted webapp.
> See the modules/owb wrapper for example.
>

> So it's a bit messy and this would need to be configurable for now.
>

Here is how I understand it:
1) if you deploy in EE server, like Wildfly and Glassfish, then both
cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
server and they are not part of the application, so nothing will be migrated
2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
are migrated and everything works

In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
jakarta packages are prefered than javax ones.

Do you see a use case that is not supported at the moment ?

Martin


>
> Rémy
>
>
>> ---
>>  src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> index 21e0fbf..701134d 100644
>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern;
>>  public class Util {
>>
>>  private static Pattern PATTERN = Pattern.compile(
>> -
>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
>> +
>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
>> ++ ".]message|servlet|transaction|websocket))");
>>
>>  /**
>>   * Get the extension of a filename
>>
>>
>> -
>> 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.33

2020-03-12 Thread Martin Grigorov
On Wed, Mar 11, 2020 at 11:51 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.33 release is now available for voting.
>
> The major changes compared to the 9.0.31 release are:
>
> - Add new attribute persistAuthentication to both StandardManager and
>   PersistentManager to support authentication persistence.
>   Patch provided by Carsten Klein
>
> - A zero length AJP secret will now behave as if it has not been
>   specified.
>
> - Add the TLS request attributes used by IIS to the attributes that
>   an AJP Connector will always accept.
>
> 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.33/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1257/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.33
> 100ca6fcaf5aceb8fecd5cff0c45e1d52f8baaed
>
> The proposed 9.0.33 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.33
>

Tested the distribution with Apache Wicket examples application and the
daily builds in my ARM64 based environment.

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

2020-03-12 Thread Martin Grigorov
On Wed, Mar 11, 2020 at 1:39 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M3 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-M1  are:
>
> - Disable session persistence by default (on restart)
>
> - Add new attribute persistAuthentication to both StandardManager and
>   PersistentManager to support authentication persistence.
>   Patch provided by Carsten Klein
>
> - A zero length AJP secret will now behave as if it has not been
>   specified.
>
> 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-M3/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1256/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M3
> eb684224706fe1d8ef5610c8d79dc403e1038393
>
> The proposed 10.0.0-M3 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M2
>

Tested with wicket-examples.war migrated with the Jakarta Migration Tool.

Regards,
Martin


>
> I opted to only include alpha here as there are still some potentially
> significant changes on the TOMCAT-NEXT list.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [Bug 64210] parsing request headers fail

2020-03-10 Thread Martin Grigorov
On Tue, Mar 10, 2020 at 2:52 PM Mark Thomas  wrote:

> On 10/03/2020 10:14, bugzi...@apache.org wrote:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=64210
> >
> > --- Comment #3 from Mark Thomas  ---
> > Thanks. I'm able to reproduce this. I'm working on some additional test
> cases
> > and a fix.
> >
>
> Moving to the dev@ list as this isn't really related to fixing this issue.
>
> This is a regression in the HTTP header parsing fixes fir CRLF added in
> the recent release round.
>
> I'm leaning towards cancelling the current set of releases to pick up
> this fix.
>
> Thoughts?
>

Agreed!


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


Re: [VOTE] Release Apache Tomcat 9.0.32

2020-03-09 Thread Martin Grigorov
On Fri, Mar 6, 2020 at 12:12 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.32 release is now available for voting.
>
> The major changes compared to the 9.0.31 release are:
>
> - Add new attribute persistAuthentication to both StandardManager and
>   PersistentManager to support authentication persistence.
>   Patch provided by Carsten Klein
>
> - A zero length AJP secret will now behave as if it has not been
>   specified.
>
> - Add the TLS request attributes used by IIS to the attributes that
>   an AJP Connector will always accept.
>
> 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.32/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1251/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.32
> 3a9578990e4e90bcc04bf7d5ef3bc47445e827e6
>
> The proposed 9.0.32 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.32
>

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

2020-03-09 Thread Martin Grigorov
On Fri, Mar 6, 2020 at 1:52 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.52 release is now available for voting.
>
> The major changes compared to the 8.5.51 release are:
>
> - Add new attribute persistAuthentication to both StandardManager and
>   PersistentManager to support authentication persistence.
>   Patch provided by Carsten Klein
>
> - A zero length AJP secret will now behave as if it has not been
>   specified.
>
> - Add the TLS request attributes used by IIS to the attributes that
>   an AJP Connector will always accept.
>
>
> 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.52/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1252/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.52
> c83fd06b3cd0c96ffd7dc660107a1283b714483b
>
> The proposed 8.5.51 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.52
>


Regards,
Martin


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


Re: Issue with tomcat-native.git

2020-03-09 Thread Martin Grigorov
On Mon, Mar 9, 2020 at 12:21 PM Mark Thomas  wrote:

> On 09/03/2020 10:12, Mark Thomas wrote:
> > On 09/03/2020 09:54, Martin Grigorov wrote:
> >
> > 
> >
> >>  > $ git --version
> >>  > git version 2.25.0
> >> > $ LC_ALL=C.UTF-8 git clone
> >> https://gitbox.apache.org/repos/asf/tomcat-native.git
> >> > Cloning into 'tomcat-native'...
> >> > remote: Counting objects: 65115, done.
> >> > remote: Compressing objects: 100% (13385/13385), done.
> >> > remote: Total 65115 (delta 45425), reused 64843 (delta 45265)
> >> > Receiving objects: 100% (65115/65115), 12.90 MiB | 209.00 KiB/s,
> done.
> >> > Resolving deltas: 100% (45425/45425), done.
> >> > warning: remote HEAD refers to nonexistent ref, unable to
> checkout.
> >>
> >> If this is persistent and can be reproduced elsewhere I'd open an
> INFRA
> >> ticket.
> >>
> >>
> >> I see the same on my Ubuntu dev machine.
> >>
> >> There is no such issue with the GitHub copy
> >> (https://github.com/apache/tomcat-native.git)
> >
> > I think I know what the issue is. Give me a few minutes...
>
> Should be fixed now.
>
> If you don't want to redo the clone, just cd into the directory the
> failed clone created and do "git checkout master".
>

Confirmed!
Now it is OK!


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


Re: Issue with tomcat-native.git

2020-03-09 Thread Martin Grigorov
Hi Michael,

On Mon, Mar 9, 2020 at 11:44 AM Michael Osipov  wrote:

> Folks,
>
> is it just me or is something wrong with tomcat-native.git on GitBox?
>
> > PS C:\Users\osipovmi> git --version
> > git version 2.25.0.windows.1
> > PS C:\Users\osipovmi> git clone
> https://gitbox.apache.org/repos/asf/tomcat-native.git
> > Cloning into 'tomcat-native'...
> > remote: Counting objects: 65115, done.
> > remote: Compressing objects: 100% (13385/13385), done.
> > remote: Total 65115 (delta 45424), reused 64843 (delta 45265)
> > Receiving objects: 100% (65115/65115), 12.90 MiB | 52.00 KiB/s, done.
> > Resolving deltas: 100% (45424/45424), done.
> > warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
>  > $ git --version
>  > git version 2.25.0
> > $ LC_ALL=C.UTF-8 git clone
> https://gitbox.apache.org/repos/asf/tomcat-native.git
> > Cloning into 'tomcat-native'...
> > remote: Counting objects: 65115, done.
> > remote: Compressing objects: 100% (13385/13385), done.
> > remote: Total 65115 (delta 45425), reused 64843 (delta 45265)
> > Receiving objects: 100% (65115/65115), 12.90 MiB | 209.00 KiB/s, done.
> > Resolving deltas: 100% (45425/45425), done.
> > warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> If this is persistent and can be reproduced elsewhere I'd open an INFRA
> ticket.
>

I see the same on my Ubuntu dev machine.

There is no such issue with the GitHub copy (
https://github.com/apache/tomcat-native.git)

Martin


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


Re: The future of Gump

2020-03-09 Thread Martin Grigorov
Hi Mark,

On Sat, Mar 7, 2020 at 10:11 PM Mark Thomas  wrote:

> Hi all,
>
> The Gump project has reached the point where Tomcat is the only ASF
> project using it. The Gump community is currently discussing options for
> the future.
>
> One of those options is status quo which would have no impact on us.
>
> Another option is the attic. If that were to happen, the vmgump service
> would potentially go away. vmgump has been very useful to the Tomcat
> community. It seems to have a knack of finding concurrency bugs. It
> also, recently, found a regression in OpenSSL master enabling us to get
> that fixed.
>
> If gump heads to the attic is the Tomcat community prepared to:
>
> a) take over the management of the vmgump service?
>
> b) take over the maintenance of the gump code (occasionally code changes
>are required like when Maven Central started to require https)
>
> In reality I do most of a) and b) already and I would continue doing so
> if they moved to Tomcat.
>
> Note that all of this is hypothetical at this point. The Gump PMC has
> not made a decision yet.
>
> Thoughts?
>

For testing ARM64 on TravisCI (
https://github.com/apache/tomcat/blob/34a855f844091bcdbac6205c6343f7bf6764806f/.travis.yml
 &
https://github.com/apache/tomcat-connectors/blob/9750da36d3c6a30d44d8374c7f6c5182e34fd5cf/.travis.yml
)
I've rolled custom scripts (YAML, actually) which build trunk/master of
APR, APR Util, libtcnative and HTTPD projects to be able to build and test
Tomcat and Tomcat Connectors projects.
I have zero experience with Gump and I've never seen its Tomcat build
configuration, but I guess it does something similar.
If the setup is similar then maybe we can extend the usage of TravisCI by
adding whatever is missing and enabling AMD64 (this is one line change) ?

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] branch master updated: Add Maven wrapper so that it is easier for non-Maven users to build the tool

2020-03-05 Thread Martin Grigorov
On Thu, Mar 5, 2020 at 4:13 PM Rémy Maucherat  wrote:

> On Thu, Mar 5, 2020 at 8:44 AM  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-jakartaee-migration.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 198e510  Add Maven wrapper so that it is easier for non-Maven
>> users to build the tool
>> 198e510 is described below
>>
>> commit 198e510a67cec569e91cc2cc87e4f4adb181f753
>> Author: Martin Tzvetanov Grigorov 
>> AuthorDate: Thu Mar 5 09:40:32 2020 +0200
>>
>> Add Maven wrapper so that it is easier for non-Maven users to build
>> the tool
>>
>> As mentioned at
>> https://lists.apache.org/thread.html/rc9e4d40c939bcc5d79e4f2a8fa0ff96853940aa20362b58b59af5973%40%3Cusers.tomcat.apache.org%3E
>> some Tomcat users are not huge fans of Maven and they hesitate to install
>> Maven just to build the migration tool. By having the Maven wrapper scripts
>> one can easily build the migration tool with: ./mvnw clean package
>>
>
> So horrible !
>

Welcome to 2020, Rémy!


>
> Rémy
>
>


Re: Tagging 10.0.x, 9.0.x, 8.5.x

2020-03-04 Thread Martin Grigorov
On Wed, Mar 4, 2020 at 2:27 PM Violeta Georgieva 
wrote:

>
>
> На ср, 4.03.2020 г. в 14:25 Martin Tzvetanov Grigorov <
> mgrigo...@apache.org> написа:
> >
> > The SCI regression seems to affect some users of 7.0.x. And staying with
> 7.0.99 is not a good option because of CVE-2020-1938.
> >
> > @Violeta: will you have time to cut 7.0.101 after the new releases of
> 10.0.x, 9.0.x and 8.5.x ?
>
> Yep I can do that
>

Cool!
Thanks!


>
> Regards,
> Violeta
>
> > Martin
> >
> > On 2020/02/28 20:30:50, Mark Thomas  wrote:
> > > Just a heads up that I'm aiming to do this early next week.
> > >
> > > Mark
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
>


Re: Trouble building and running Tomcat 10 unit tests

2020-03-04 Thread Martin Grigorov
Hi Chris,

Travis CI (ARM64 tests) uses Ant 1.10.7 and OpenJDK 8 b232 and the build
passes fine: https://travis-ci.org/apache/tomcat/jobs/65889/config
On my VM I use Ant 1.9.14 and OpenJDK 8 b242 and again everything is green.
BuildBot is also stable: https://ci.apache.org/builders/tomcat-trunk


Martin

On Tue, Mar 3, 2020 at 10:31 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm up-to-date with git master, using ant 1.9.13, JDK 13.
>
> $ ant test
>
> [...]
>
> test-compile:
> [javac] Compiling 1 source file to
> /Users/christopherschultz/git/tomcat-trunk/output/testclasses
> [javac] Ignoring source, target and bootclasspath as release has
> been set
> [javac]
> /Users/christopherschultz/git/tomcat-trunk/test/org/apache/catalina/ant/
> TestDeployTask.java:37:
> error: cannot access BuildException
> [javac] public void execute(String command,
> InputStream istream, String contentType, long contentLength)
> [javac] ^
> [javac]   class file for BuildException not found
> [javac] 1 error
>
> Ant has this class. Not sure why it can't access it. Okay, fine, I'll
> just delete the file and move on:
>
> $ rm test/org/apache/catalina/ant/TestDeployTask.java
> $ ant test
>
> [...]
>
> add-osgi:
>  [echo] add-osgi
> /Users/christopherschultz/git/tomcat-trunk/output/build/lib/catalina.jar
> true
>   [bndwrap] 1 ERRORS
>   [bndwrap]  The default package '.' is not permitted by the
> Import-Package syntax.
>   [bndwrap]  This can be caused by compile errors in Eclipse because
> Eclipse creates
>   [bndwrap] valid class files regardless of compile errors.
>   [bndwrap] The following package(s) import from the default package
> [org.apache.naming.factory.webservices, org.apache.catalina.startup]
>
> BUILD FAILED
> /Users/christopherschultz/git/tomcat-trunk/build.xml:852: The
> following error occurred while executing this line:
> /Users/christopherschultz/git/tomcat-trunk/build.xml:3372: The
> following error occurred while executing this line:
> /Users/christopherschultz/git/tomcat-trunk/build.xml:3381: Failed to
> wrap jar file
>
> Downgrading to Java 8 (as per Tomcat 10 build instructions) yields the
> same result.
>
> What am I missing?
>
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5evpsACgkQHPApP6U8
> pFiGcRAAkaGS2G+/DCXQbByimPYmCWbWWtq3pZPICjW4CpZA12Gx03Kr9Jo5jJTe
> 3ygSN8WxZTkfArtrcg0bop44FuYJZU7owPbP5ppDt38q7R3bI0einB+KKTsBuu4l
> tsfDipRV6ItzjbIY/UJNJho4/go0vaIcmkQU8KtQf5CI/zZiDWJq1RkQmxSQkc0r
> hMWy2YLAigsSikR1Aah8fOn8WICNEKYOylsUmFVr119Ps6SgkYQ+Vq0+UGSo1UWW
> +yP6hhCqJaK/WIyJBr3n4As8QRzZ9w+n+H6BZmUiH+iQMgURYkTvicTqkcewFOPE
> r6lh5AGDYKJiGRtA8k0uqweOT1mwtIEN7T2OeDG4axXAIVeW5PSAT6O5ZibWRL7p
> ZDITx8ZpZpNvzixOaGm1Nqy7xzd5c/vXwyckvM/phZp/UnLxnFYkZkjqtO14tYQc
> FcNjeBZjIJxP7lPhfLXpMRI1Lf5sQy1lnhZOg3dqVChJEWCabpz/wZscsUSV1LCa
> G05RbMj9JsrDo3Y9jI+9ixWy6t+C3HFGJ4WqayVwd+ErdDjanEIsUO48lTKwD+be
> iz07aP8LMUVSholwhu1kR1YsaWb6mL+Y3f5AeitCBnkiAW2ZvBSAX9knsAFkrhUq
> EkAm9brjvmz44QJ+eUdVJLEY1GXAIUt1rAELtdjt/n/3E1cdvPw=
> =N/et
> -END PGP SIGNATURE-
>
> -
> 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 request start time using nanoTime

2020-02-28 Thread Martin Grigorov
Chris,

On Fri, Feb 28, 2020 at 12:20 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rémy,
>
> On 2/27/20 10:49, r...@apache.org 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 22ad695  Update request start time using nanoTime 22ad695
> > is described below
> >
> > commit 22ad69571c019f4d84ccc522298dddb4f8fa8d70 Author: remm
> >  AuthorDate: Thu Feb 27 16:49:04 2020 +0100
> >
> > Update request start time using nanoTime
> >
> > get/setStartTime are still there, not sure about existing use.
> > Another patch round could deprecate them. Also change the access
> > log to be the start of the request (a small part of 63286). ---
> >
> > [snip]
> >
> > diff --git a/java/org/apache/coyote/AbstractProcessor.java
> > b/java/org/apache/coyote/AbstractProcessor.java index
> > 254950e..5af3710 100644 ---
> > a/java/org/apache/coyote/AbstractProcessor.java +++
> > b/java/org/apache/coyote/AbstractProcessor.java @@ -978,6 +978,7 @@
> > public abstract class AbstractProcessor extends
> > AbstractProcessorLight implement setSocketWrapper(socketWrapper);
> > // Setup the minimal request information
> > request.setStartTime(System.currentTimeMillis()); +
> > request.setStartTimeNanos(System.nanoTime()); // Setup the minimal
> > response information response.setStatus(400); response.setError();
>
> Since we are talking about nanoseconds, here, we ARE, by definition,
> splitting hairs :)
>
> System.currentTimeMillis() and System.nanoTime() may disagree when you
> capture them like this, because [a super-small amount of] time elapses
> between the two calls.
>
> Should we instead do:
>
> long nanos = System.nanoTime();
> request.setStartTimeNanos(nanos);
> request.setStartTime(nanos / 100l);
>
> Or maybe:
>
> long nanos = System.nanoTime();
> request.setStartTimeNanos(nanos);
> request.setStartTime(TimeUnit.NANOSECONDS.toMillis(nanos));
>
>
Those are not the same.
Request#startTime (System.currentTimeMillis) is the milliseconds since
Epoch, i.e. a complete timestamp.
System.nanoTime() is just a relative time that could be used to measure
duration between two calls but it doesn't tell you when exactly a call has
happened.


> ?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5YQJgACgkQHPApP6U8
> pFhTeBAAnSpEZcvd99nyNM8rjYaCuXvij+yaKjOWPq0TFoH7mhJGkWGzTeVS0RoX
> ONB23CqbhXv2lI9aOcCjlghW7cwvRXCiLU4I6WVZ8fDj2yjPVvEpccNrJLozmuof
> DgfCTx/Uc21s0UMkj6maCdxLUfZdGiBNcp7zwURLwanWhzqRfVzna1VwcQNPiws0
> eSK4R0YxrzS6Gt6i00+2e9FyqIe2tUL/hrF5/d3Zj9U4P/b17QOeC3FZfgZjdWMY
> splxjEBFx+YmgsAV56qx9uePHjtRnnO30WZEz7X8H+7AwENk6kp5qcA38q7WUkrm
> HS3EWYQC8W5dEsu7WcBqj3ZqDSpmwwJaZlSDFXh+bqL9AqEBnLutbBsl+49p6mHP
> NvvIQ/Q0sCXOhH7y8juB310yDDkKhHsqRbY2cUzK+eHrdSibESqwDLBDR59F5se/
> GQKw4J3icMdqxq69vOxfbXQ6R0PxiL984xW/bcvyH7xZt+d166+BtzyUWHX3knxH
> zv+0XUjErwIVrmXXTFDyJYNtjQUGULVdAtGqqSu6mQ+lw0Kr/6i9gqAR4/TUL202
> zr8drtkAv87UDQvJpEshmoLtq1tXIwBywtKf9XnXSA6Bgbz5kkMf4lbPWbMJdLQP
> BhoyiVA3Xcn8WN4RLCVeEqZHd28/6uWjLjvQXFmRIS8at3tYSeE=
> =WcID
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Download stats

2020-02-27 Thread Martin Grigorov
Hi,

On Wed, Feb 26, 2020 at 5:40 PM Mark Thomas  wrote:

> Hi all,
>
> I took a look a the download stats from downloads.apache.org.
>
> I didn't look at what was being downloaded (hashes, signatures or
> releases). I just compared number of requests for each version over a 24
> hour period (yesterday). The results were:
>
> Tomcat 30.01%
> Tomcat 40.03%
> Tomcat 50.11%
> Tomcat 60.39%
>


> Tomcat 7   26.5%
>

The percentage for Tomcat 7 is rather high at the moment.
If the number is similar for the regular runs, could it affect our desire
to EOL it next year ?


Martin


> Tomcat 8   29.9%
> Tomcat 9   39.0%
> Tomcat 10   4.1%
>
> I checked a couple of the IPs downloading Tomcat 10 at random. They did
> appear to be downloading specific files rather than scraping everything.
>
> Overall, there is (apparently) a higher than I expected take up of
> Tomcat 10.
>
> I'll try and redo these figures on a regular(ish) basis so we get an
> idea of trends.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Release Apache Tomcat Connectors (JK) 1.2.48

2020-02-24 Thread Martin Grigorov
On Thu, Feb 20, 2020 at 6:55 PM Mark Thomas  wrote:

> Tag:
>
> https://gitbox.apache.org/repos/asf?p=tomcat-connectors.git;a=commit;h=90b294ce8260ab2585dcb4071ede5d53e51fa354
>
> Source:
> https://gitbox.apache.org/repos/asf?p=tomcat-connectors.git;a=summary
>
> Dist:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/jk/
>
>
> This is a maintenance release with a handful of bug fixes (compared to
> 1.2.46) and some clean-up. It also includes Windows binaries for IIS.
>
>
> The proposed JK 1.2.48 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 1.2.48
>

Verified signatures & SHA512 sum, build it against APR[-UTIL] 1.7.x & HTTPD
2.4.x

One question:
At
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/jk/README.html
at
the bottom it talks about SHA1 but there is no .sha1 file in Dist.
I went to remove the mentioning of SHA1 at
https://github.com/apache/tomcat-connectors/blob/master/tools/dist/README.html
but
the text there is slightly different.
I guess
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/jk/README.html
is
generated somehow but the only mention of README in
https://github.com/apache/tomcat-connectors/blob/master/tools/jkrelease.sh#L36
is
about README.txt, not .html, and I don't see anything that would produce
this text: We offer SHA1 and SHA512 hashes as alternatives ...
At
https://github.com/apache/tomcat-connectors/blob/master/HOWTO-RELEASE.txt#L127
I see "Modify README.html and update it to the current version.",
so I guess you (Mark) have edited this manually.

Martin



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


Re: [VOTE] Tomcat 7.0.x EOL as 31 March 2021

2020-02-21 Thread Martin Grigorov
On Fri, Feb 21, 2020 at 11:52 AM Mark Thomas  wrote:

> All,
>
> This has been mentioned in various threads and I don't recall any
> objections. I think it is time for a vote so we can formally announce this.
>
> Announce the EOL date for 7.0.x as 31 March 2021
>
> [ X ] Yes
>

Regards,
Martin


> [ ] No, because...
>
> Thanks,
>
> 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 (81cfd2d -> 9ff6b12)

2020-02-20 Thread Martin Grigorov
On Thu, Feb 20, 2020 at 12:24 PM Mark Thomas  wrote:

> On 20/02/2020 08:54, Martin Grigorov wrote:
> > Hi Mark,
> >
> > On Wed, Feb 19, 2020 at 3:09 PM Mark Thomas  > <mailto:ma...@apache.org>> wrote:
> >
> > On 19/02/2020 12:37, mgrigo...@apache.org
> > <mailto:mgrigo...@apache.org> 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 81cfd2d  Disable session persistence by default on
> > StandardManager
> > >  add 9ff6b12  Check for non-null 'methods'
> >
> > Please revert. This check is unnecessary. methods cannot be null
> here.
> >
> >
> >
> https://github.com/apache/tomcat/blob/292b744994cf0cddf86b651dc1b1935dbe4fc83f/java/jakarta/servlet/http/HttpServlet.java#L514-L516
> > Here getAllDeclaredMethods() returns `null`.
> > Maybe it should return an empty array ?
>
> No. Null is appropriate there.
>
> This method only returns null for the abstract superclass HttpServlet.
> That call will always be a recursive call from line 518 just below. That
> null will never get returned to the original caller.
>
> The original caller will always see either a merged array from lines
> 521-530 or the result of line 519 both of which are guaranteed to be
> non-null.
>
> The null check is unnecessary. Please remove it.
>

Done!


>
> Mark
>
>
> >
> >
> >
> > Mark
> >
> > -
> > 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: [tomcat] branch master updated (81cfd2d -> 9ff6b12)

2020-02-20 Thread Martin Grigorov
Hi Mark,

On Wed, Feb 19, 2020 at 3:09 PM Mark Thomas  wrote:

> On 19/02/2020 12:37, mgrigo...@apache.org 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 81cfd2d  Disable session persistence by default on
> StandardManager
> >  add 9ff6b12  Check for non-null 'methods'
>
> Please revert. This check is unnecessary. methods cannot be null here.
>

https://github.com/apache/tomcat/blob/292b744994cf0cddf86b651dc1b1935dbe4fc83f/java/jakarta/servlet/http/HttpServlet.java#L514-L516
Here getAllDeclaredMethods() returns `null`.
Maybe it should return an empty array ?


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


Re: [VOTE] Release Apache Tomcat 10.0.0-M1

2020-02-17 Thread Martin Grigorov
On Fri, Feb 14, 2020 at 4:49 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M1 release is now available for
> voting. This is the first release of 10.0.x and is based on 9.0.31.
>
> The major changes compared to 9.0.31  are:
>
> - Complete the javax to jakarta package rename
>
> - Remove duplication of configuration between HTTP/1.1 and HTTP/2.
>   HTTP/2 will now inherit values from HTTP/1.1.
>
> - Remove deprecated code
>
> 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-M1/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1249/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M1
> b0b074b683ed2e09ff9e9755825bfce83d303a93
>
> The proposed 10.0.0-M1 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M1
>

Regards,
Martin


> I opted to only include alpha here as there are still some potentially
> significant changes on the TOMCAT-NEXT list.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [tomcat] branch master updated: 64141: Allow overriding JVM trust store

2020-02-17 Thread Martin Grigorov
On Sat, Feb 15, 2020 at 2:22 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 d14c5b4  64141: Allow overriding JVM trust store
> d14c5b4 is described below
>
> commit d14c5b409d08df88ab437f76334342b8f8094b44
> Author: remm 
> AuthorDate: Sat Feb 15 13:21:53 2020 +0100
>
> 64141: Allow overriding JVM trust store
>
> If using a CA certificate, remove a default value for the trust store
> file when not using a JSSE configuration.
> ---
>  java/org/apache/tomcat/util/net/SSLHostConfig.java | 26
> +++---
>  webapps/docs/changelog.xml |  4 
>  2 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/java/org/apache/tomcat/util/net/SSLHostConfig.java
> b/java/org/apache/tomcat/util/net/SSLHostConfig.java
> index 4a8549d..724497f 100644
> --- a/java/org/apache/tomcat/util/net/SSLHostConfig.java
> +++ b/java/org/apache/tomcat/util/net/SSLHostConfig.java
> @@ -151,15 +151,24 @@ public class SSLHostConfig implements Serializable {
>  }
>
>
> -void setProperty(String name, Type configType) {
> +/**
> + * Set property which belongs to the specified configuration type.
> + * @param name the property name
> + * @param configType the configuration type
> + * @return true if the property belongs to the current confuguration,
> + *   and false otherwise
> + */
> +boolean setProperty(String name, Type configType) {
>  if (this.configType == null) {
>  this.configType = configType;
>  } else {
>  if (configType != this.configType) {
>  log.warn(sm.getString("sslHostConfig.mismatch",
>  name, getHostName(), configType,
> this.configType));
> +return false;
>  }
>  }
> +return true;
>  }
>
>
> @@ -662,7 +671,13 @@ public class SSLHostConfig implements Serializable {
>
>
>  public void setCaCertificateFile(String caCertificateFile) {
> -setProperty("caCertificateFile", Type.OPENSSL);
> +if (setProperty("caCertificateFile", Type.OPENSSL)) {
> +// Reset default JSSE trust store if not a JSSE configuration
> +if (truststoreFile != null) {
> +System.out.println("RESET !");
>

Debug leftover.


> +truststoreFile = null;
> +}
> +}
>  this.caCertificateFile = caCertificateFile;
>  }
>
> @@ -673,7 +688,12 @@ public class SSLHostConfig implements Serializable {
>
>
>  public void setCaCertificatePath(String caCertificatePath) {
> -setProperty("caCertificatePath", Type.OPENSSL);
> +if (setProperty("caCertificatePath", Type.OPENSSL)) {
> +// Reset default JSSE trust store if not a JSSE configuration
> +if (truststoreFile != null) {
> +truststoreFile = null;
> +}
> +}
>  this.caCertificatePath = caCertificatePath;
>  }
>
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 753fb4c..e0673d1 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -51,6 +51,10 @@
>  Fix support of native jakarta servlet attributes in AJP connector.
>  (remm)
>
> +  
> +64141: If using a CA certificate, remove a default
> value
> +for the truststore file when not using a JSSE configuration.
> (remm)
> +  
>  
>
>  
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Report issues with Jakarta EE migration tool

2020-02-12 Thread Martin Grigorov
On Wed, Feb 12, 2020 at 3:20 PM Rémy Maucherat  wrote:

> On Tue, Feb 11, 2020 at 4:49 PM Mark Thomas  wrote:
>
>> On 11/02/2020 15:29, Martin Grigorov wrote:
>> >
>> >
>> > On Tue, Feb 11, 2020, 17:12 Mark Thomas > > <mailto:ma...@apache.org>> wrote:
>> >
>> > On 11/02/2020 14:49, Martin Grigorov wrote:
>> > > Hi,
>> > >
>> > > What is the proper place to report issues
>> > > with https://github.com/apache/tomcat-jakartaee-migration ?
>> > > Since it is under `apache` org there is no 'Issues' tab.
>> > > Bugzilla ?!
>> >
>> > We don't have anywhere yet.
>> >
>> > GitHub issues is an option. As is Jira and Bugzilla.
>> >
>> > This could be an opportunity to experiment with GitHUb issues if we
>> > want.
>> >
>> >
>> > For this we need to ask Infra team.
>>
>> Well, yes and no given that I am on the infra team...
>>
>> If we want to try it I can enable it.
>>
>>
>>  > Don't you want to do something like:
>> >
>> > destEntry.setMethod(jarEntry.getMethod);
>> >
>> >
>> > If the method is STORED then we also need to set the size and the CRC.
>> > And those are more complicated to get.
>>
>> Ah. I didn't see anything about that being required in the Javadoc for
>> setMethod().
>>
>> Looking at the source for ZipOutputStream it looks like we need 1 of
>> compressed size, size or CRC. Of those, I would have thought the size
>> was the easiest as we should be able to count the bytes written.
>>
>
> Setting the size sounds mundane but is rather horrible to implement, as
> the migration occurs after creating the entry. So it suddenly needs to be
> buffered, causing more problems. I don't think it should be supported.
>

Yes, I've tried a couple of different ways to implement it but it is not
working so far.

Martin


>
> Rémy
>
>


Re: Report issues with Jakarta EE migration tool

2020-02-11 Thread Martin Grigorov
On Tue, Feb 11, 2020, 17:12 Mark Thomas  wrote:

> On 11/02/2020 14:49, Martin Grigorov wrote:
> > Hi,
> >
> > What is the proper place to report issues
> > with https://github.com/apache/tomcat-jakartaee-migration ?
> > Since it is under `apache` org there is no 'Issues' tab.
> > Bugzilla ?!
>
> We don't have anywhere yet.
>
> GitHub issues is an option. As is Jira and Bugzilla.
>
> This could be an opportunity to experiment with GitHUb issues if we want.
>

For this we need to ask Infra team.


> > I've faced an issue with Spring Boot jars.
> > Once migrated trying to use it fails with:
>
> 
>
> > Caused by: java.lang.IllegalStateException: Unable to open nested entry
> > 'BOOT-INF/lib/spring-boot-starter-web-2.2.4.RELEASE.jar'. It has been
> > compressed and nested jar files must be stored without compression.
> > Please check the mechanism used to create your executable jar file
>
> Of course. That is a trick Spring Boot uses to provide better
> performance for nested JAR files.
>
> > i.e. it needs to use `destEntry.setMethod(ZipEntry.STORED);` (for jars
> > nested in /BOOT-INF/lib/**.jar)
> > in org.apache.tomcat.jakartaee.Migration#migrateArchive()
> > I am reworking it to return a Result object instead of a boolean
> > (isSuccess) that will contain: the
> > isSuccess boolean, the accumulated size and CRC for all entries in the
> > nested jar.
> >
> > If I am on the wrong track please share your ideas!
>
> The CRCs are always going to be different because the content has changed.
>
> The accumulated sizes are going to change for the same reason.
>
> In terms of being able to tell compressed / vs uncompressed I'm not sure
> you'll see enough difference (given that a JAR is already compressed
> with probably the exact same algorithm) to tell them apart.
>
> Don't you want to do something like:
>
> destEntry.setMethod(jarEntry.getMethod);
>

If the method is STORED then we also need to set the size and the CRC. And
those are more complicated to get.


> around line 119 of Migration.java ?
>
> Mark
>
>
> >
> > To reproduce it one can create a new application
> > at https://start.spring.io/, package it, migrate it and try to run it.
> >
> > Martin
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Report issues with Jakarta EE migration tool

2020-02-11 Thread Martin Grigorov
On Tue, Feb 11, 2020, 17:06 Rémy Maucherat  wrote:

> On Tue, Feb 11, 2020 at 3:50 PM Martin Grigorov 
> wrote:
>
>> Hi,
>>
>> What is the proper place to report issues with
>> https://github.com/apache/tomcat-jakartaee-migration ?
>> Since it is under `apache` org there is no 'Issues' tab.
>> Bugzilla ?!
>>
>> I've faced an issue with Spring Boot jars.
>> Once migrated trying to use it fails with:
>>
>>
>> Exception in thread "main" java.lang.IllegalStateException: Failed to get
>> nested archive for entry
>> BOOT-INF/lib/spring-boot-starter-web-2.2.4.RELEASE.jar
>> at
>> org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:113)
>> at
>> org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:87)
>> at
>> org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:69)
>> at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
>> at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
>> Caused by: java.io.IOException: Unable to open nested jar file
>> 'BOOT-INF/lib/spring-boot-starter-web-2.2.4.RELEASE.jar'
>> at
>> org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:261)
>> at
>> org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:247)
>> at
>> org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:109)
>> ... 4 more
>> Caused by: java.lang.IllegalStateException: Unable to open nested entry
>> 'BOOT-INF/lib/spring-boot-starter-web-2.2.4.RELEASE.jar'. It has been
>> compressed and nested jar files must be stored without compression. Please
>> check the mechanism used to create your executable jar file
>> at
>> org.springframework.boot.loader.jar.JarFile.createJarFileFromFileEntry(JarFile.java:287)
>> at
>> org.springframework.boot.loader.jar.JarFile.createJarFileFromEntry(JarFile.java:269)
>> at
>> org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:258)
>> ... 6 more
>>
>>
>> i.e. it needs to use `destEntry.setMethod(ZipEntry.STORED);` (for jars
>> nested in /BOOT-INF/lib/**.jar)
>> in org.apache.tomcat.jakartaee.Migration#migrateArchive()
>> I am reworking it to return a Result object instead of a boolean
>> (isSuccess) that will contain: the
>> isSuccess boolean, the accumulated size and CRC for all entries in the
>> nested jar.
>>
>> If I am on the wrong track please share your ideas!
>>
>> To reproduce it one can create a new application at
>> https://start.spring.io/, package it, migrate it and try to run it.
>>
>
> Ok, so I guess use of this tool got a bit experimental very quickly ;)
>

Right!
I'm pushing it to the limits! :-)

>
> The purpose of the tool is to run Java EE (web)apps on *Tomcat* 10+ (or
> another *compliant* EE 9 server I suppose). It seems you are trying to
> convert something like "Spring boot with an embedded app", which isn't the
> goal of the tool at the moment. If it works, great, but it's a bit hard to
> promise support for everything. So ... Does it work ?
>

I use tomcat-embed-*.jars from master, i.e. 10.x, but you are right that
the idea looks crazy :-)


> Rémy
>
>
>>
>> Martin
>>
>


  1   2   3   4   >