Re: [VOTE] Release Apache Tomcat 9.0.54

2021-09-29 Thread Martin Grigorov
On Tue, Sep 28, 2021 at 5:32 PM Rémy Maucherat  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.12

2021-09-29 Thread Martin Grigorov
On Tue, Sep 28, 2021 at 4:59 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.1.0-M6

2021-09-29 Thread Martin Grigorov
On Tue, Sep 28, 2021 at 3:31 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M6 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M5 are:
>
> - Servlet API updates for Servlet 6 including removal of all deprecated
>code, updated schemas and a new API for connection and request IDs.
>
> - EL API updates for EL 5.0 including deprecation of the use of
>FeatureDescriptor, improvements to BeanELResolver and the addition of
>MethodReference
>
> - Further robustness improvements to HTTP/2 flow control window
>management
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M6/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1334
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M6
> 51d1031c36c0f2b3ee1e0d14b56228a559144153
>
>
> The proposed 10.1.0-M6 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M6 (alpha)
>


Regards,
Martin


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


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

2021-09-15 Thread Martin Grigorov
Hi Rory,

Congratiolations for JDK 17 GA!

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

Regards,
Martin

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

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


Re: [VOTE] Release Apache Tomcat 8.5.71

2021-09-13 Thread Martin Grigorov
On Thu, Sep 9, 2021 at 10:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

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

Regards,
Martin


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


Re: building Tomcat with a third-party library

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

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

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



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

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

Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.53

2021-09-08 Thread Martin Grigorov
On Mon, Sep 6, 2021 at 10:22 PM Rémy Maucherat  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.11

2021-09-08 Thread Martin Grigorov
On Mon, Sep 6, 2021 at 9:30 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.1.0-M5

2021-09-08 Thread Martin Grigorov
On Mon, Sep 6, 2021 at 5:43 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M5 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M4 are:
>
> - Remove the deprecated APR/Native connector which includes the HTTP APR
>and the AJP APR connector. Also remove the Java interfaces to the
>APR/Native library that are not used by the OpenSSL integration for
>the NIO and NIO2 connectors.
>
> - Add a UserDatabase implementation as a superset of the DataSourceRealm
>functionality.
>
> - Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
>Commons Pool to 2.11.1
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M4/


This should be -M5


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

Regards,
Martin


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


Re: JDK 17 is now in the Release Candidate Phase

2021-08-09 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


Re: JDK 17 is now in Rampdown Phase Two

2021-07-16 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


Re: Possible code clean-up

2021-06-30 Thread Martin Grigorov
On Wed, Jun 30, 2021 at 3:51 PM Mark Thomas  wrote:

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

+1 to simplify !


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


Re: [VOTE] Release Apache Tomcat 10.1.0-M2

2021-06-30 Thread Martin Grigorov
On Sat, Jun 26, 2021 at 1:07 AM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M2 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M1 are:
>
> - Re-work the HTTP/2 overhead protection to reduce the likelihood of
>false positives. Note that the default overheadCountFactor has changed
>from 1 to 10 and that the useful range is now 0 to ~20.
>
> - Update to Eclipse JDT compiler 4.20.
>
> - Fix regressions in JSP compilation in the previous release.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M2/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1318
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M2
> 0e59fedb28df646930c5aff945159b64d7a52260
>
> The proposed 10.1.0-M2 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 10.1.0-M2 (alpha)
>

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.8

2021-06-30 Thread Martin Grigorov
On Sat, Jun 26, 2021 at 2:27 AM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 8.5.69

2021-06-30 Thread Martin Grigorov
Hi,

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

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

One more issue:

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


>
> Rémy
>
> >
> > Best regards,
> > Konstantin Kolinko
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: [VOTE] Release Apache Tomcat 9.0.50

2021-06-30 Thread Martin Grigorov
On Mon, Jun 28, 2021 at 11:57 AM Rémy Maucherat  wrote:

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

Regards,
Martin

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


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

2021-06-25 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


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

2021-06-17 Thread Martin Grigorov
Hi Mark,

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

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

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


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


Re: JDK 17 is now in Rampdown Phase One

2021-06-14 Thread Martin Grigorov
Same for JDK 18-ea+1-7 !

Regards,
Martin

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

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

Re: JDK 17 is now in Rampdown Phase One

2021-06-14 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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

Re: [VOTE] Release Apache Tomcat 8.5.68

2021-06-14 Thread Martin Grigorov
On Fri, Jun 11, 2021 at 5:01 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

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


Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 8.5.67

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

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


Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.7

2021-06-11 Thread Martin Grigorov
On Tue, Jun 8, 2021 at 8:47 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.48

2021-06-11 Thread Martin Grigorov
On Thu, Jun 10, 2021 at 1:20 PM Rémy Maucherat  wrote:

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

Regards,
Martin


>
> Rémy
>


Re: [VOTE] Release Apache Tomcat 10.1.0-M1

2021-06-11 Thread Martin Grigorov
On Tue, Jun 8, 2021 at 6:37 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.1.0-M1 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> This is the first milestone release of the 10.1.x branch.
>
> The notable changes compared to 10.0.x are:
>
> - Remove code (but not the APR/Native Connector) previously marked for
>removal in 10.1.x The APR/Native Connector will almost certainly be
>removed in a future milestone.
>
> - Align the Servlet API implementation with the current Servlet API
>development branch.
>
> - Align the EL API implementation with the current El API development
>branch.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1312
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M1
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
>
> The proposed 10.1.0-M1 release is:
> [ ] Broken - do not release
> [ X ] Alpha - go ahead and release as 10.1.0-M1 (alpha)
>

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.1.0-M1

2021-06-11 Thread Martin Grigorov
Hi Mark,

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

> The proposed Apache Tomcat 10.1.0-M1 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> This is the first milestone release of the 10.1.x branch.
>
> The notable changes compared to 10.0.x are:
>
> - Remove code (but not the APR/Native Connector) previously marked for
>removal in 10.1.x The APR/Native Connector will almost certainly be
>removed in a future milestone.
>
> - Align the Servlet API implementation with the current Servlet API
>development branch.
>
> - Align the EL API implementation with the current El API development
>branch.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1312
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M1
> f2ab9ac8bc3f40ee9b2cb50b030c99df927f0429
>

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


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


Re: JDK 17 Early Access build 23 is available

2021-05-21 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


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

2021-05-19 Thread Martin Grigorov
On Tue, May 18, 2021 at 3:16 PM Romain Manni-Bucau 
wrote:

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

Same vote from me!


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 18 mai 2021 à 14:13, Emmanuel Bourg  a écrit :
>
> > Le 2021-05-18 14:10, Emmanuel Bourg a écrit :
> >
> > >> Comments?
> > >
> > > I don't think the 7.0.x branch should be removed, there is no harm
> > > keeping it.
> > >
> > > As for the master->main change I think that's a waste of time for all
> > > of us. i don't buy the argument that "master" is offensive, but by
> > > moving awa
> >
> > Grr message sent too quickly, sorry.
> >
> > I don't want to reopen the debate, please ignore my comment.
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>


Re: [VOTE] Release Apache Tomcat 10.0.6

2021-05-11 Thread Martin Grigorov
On Sat, May 8, 2021 at 7:18 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.46

2021-05-11 Thread Martin Grigorov
On Sat, May 8, 2021 at 9:15 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 8.5.66

2021-05-11 Thread Martin Grigorov
On Sun, May 9, 2021 at 2:12 AM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: Disabling Some Test Cases by Pattern

2021-05-11 Thread Martin Grigorov
Hi Igal,

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

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

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


>
> Thanks,
>
> Igal
>


Re: JDK 17 Early Access build 21 is available

2021-05-11 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


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

2021-05-07 Thread Martin Grigorov
On Tue, May 4, 2021 at 3:06 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 7.0.109

2021-04-26 Thread Martin Grigorov
On Thu, Apr 22, 2021 at 10:13 PM Violeta Georgieva 
wrote:

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

Martin


>
> Regards,
> Violeta
>


Re: JDK 17 Early Access build 18 is available

2021-04-21 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


Re: TCK Signature for EL API

2021-04-07 Thread Martin Grigorov
Hi,

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

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

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


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


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

Re: [VOTE] Release Apache Tomcat Native 1.2.28

2021-04-02 Thread Martin Grigorov
On Thu, Apr 1, 2021 at 4:56 PM Mark Thomas  wrote:

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

Regards,
Martin

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


Re: OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Martin Grigorov
On Fri, Apr 2, 2021 at 12:19 PM Rémy Maucherat  wrote:

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

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

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

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

to be available in JDK 17."


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

Re: OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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

Re: [VOTE] Release Apache Tomcat 10.0.5

2021-03-31 Thread Martin Grigorov
On Tue, Mar 30, 2021 at 11:46 AM Mark Thomas  wrote:

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

Martin


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


Re: [VOTE] Release Apache Tomcat 8.5.65

2021-03-31 Thread Martin Grigorov
On Tue, Mar 30, 2021 at 4:13 PM Mark Thomas  wrote:

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

Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.45

2021-03-31 Thread Martin Grigorov
On Tue, Mar 30, 2021 at 1:52 PM Mark Thomas  wrote:

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

Regards,
Martin


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


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

2021-03-17 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


Re: Refactoring the HTTP/2 API

2021-03-11 Thread Martin Grigorov
On Thu, Mar 11, 2021 at 12:03 PM Mark Thomas  wrote:

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

No objections from me!

Martin


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


Re: [VOTE] Release Apache Tomcat 8.5.64

2021-03-07 Thread Martin Grigorov
On Fri, Mar 5, 2021 at 1:49 AM Mark Thomas  wrote:

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


Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.44

2021-03-07 Thread Martin Grigorov
On Fri, Mar 5, 2021 at 12:22 AM Mark Thomas  wrote:

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


Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.4

2021-03-07 Thread Martin Grigorov
On Fri, Mar 5, 2021 at 1:26 PM Mark Thomas  wrote:

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

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

Martin


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


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

2021-02-18 Thread Martin Grigorov
On Wed, Feb 17, 2021 at 5:49 PM  wrote:

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

nit: you could use CLASS_FILE_SUFFIX as you did below


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


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

2021-02-17 Thread Martin Grigorov
On Tue, Feb 9, 2021 at 7:18 PM  wrote:

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

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


> +constantPool[i] = c;
> +}
>  }
>  }
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


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

2021-02-15 Thread Martin Grigorov
On Thu, Feb 11, 2021 at 7:47 PM Mark Thomas  wrote:

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

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

Martin


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


Re: Integrating migration tool into Tomcat 10

2021-02-10 Thread Martin Grigorov
On Wed, Feb 10, 2021 at 12:24 PM Mark Thomas  wrote:

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

Good to know!


>
> There are other complications with Spring Boot applications (you need to
> swap out the Tomcat implementation JARs as well) but those should be
> solvable. Whether it is the migration tool's job to solve them is a
> different question.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


Re: Integrating migration tool into Tomcat 10

2021-02-10 Thread Martin Grigorov
Hi Romain,

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

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

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


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

I don't really understand you here


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

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


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


Re: Integrating migration tool into Tomcat 10

2021-02-10 Thread Martin Grigorov
Hi,

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

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

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

Martin


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


Re: JDK 16 is now in the Release Candidate Phase

2021-02-08 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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

Re: JDK 16 is now in the Release Candidate Phase

2021-02-08 Thread Martin Grigorov
Hi Rémy,

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

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

Re: JDK 16 is now in the Release Candidate Phase

2021-02-08 Thread Martin Grigorov
Hi devs,

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

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

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

2021-02-01 Thread Martin Grigorov
On Mon, Feb 1, 2021 at 4:06 PM  wrote:

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

Why Object + toString() ? It is a String


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

Re: [VOTE] Release Apache Tomcat 8.5.63

2021-02-01 Thread Martin Grigorov
On Fri, Jan 29, 2021 at 1:43 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.43

2021-02-01 Thread Martin Grigorov
On Thu, Jan 28, 2021 at 10:48 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.2

2021-02-01 Thread Martin Grigorov
On Thu, Jan 28, 2021 at 9:13 PM Mark Thomas  wrote:

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


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


Re: [VOTE] Release Apache Tomcat 7.0.108

2021-01-28 Thread Martin Grigorov
On Thu, Jan 28, 2021 at 11:49 AM Violeta Georgieva 
wrote:

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

Regards,
Martin


>
> Regards,
> Violeta
>


Re: [VOTE] Release Apache Tomcat 8.5.62

2021-01-28 Thread Martin Grigorov
On Wed, Jan 27, 2021 at 9:25 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.42

2021-01-28 Thread Martin Grigorov
On Wed, Jan 27, 2021 at 7:40 PM Mark Thomas  wrote:

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

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.1

2021-01-28 Thread Martin Grigorov
On Wed, Jan 27, 2021 at 5:08 PM Mark Thomas  wrote:

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

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

Regards,
Martin


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


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

2021-01-22 Thread Martin Grigorov
On Mon, Jan 18, 2021 at 1:07 PM  wrote:

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

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


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

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


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

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


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

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

2021-01-22 Thread Martin Grigorov
On Tue, Jan 19, 2021 at 7:55 PM Mark Thomas  wrote:

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

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


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

Re: JDK 16 is now in Rampdown Phase Two

2021-01-18 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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

Re: Compat versions

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

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

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


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

+1



>
> Rémy
>


Re: JDK 16 is in Rampdown Phase One

2020-12-15 Thread Martin Grigorov
Hi Rory,

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

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

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

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

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

2020-12-15 Thread Martin Grigorov
On Tue, Dec 15, 2020 at 3:35 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 61f4baf  Add opens for Java 16
> 61f4baf is described below
>
> commit 61f4baf64c69c5fd738d34b6139eda4549258cea
> Author: remm 
> AuthorDate: Tue Dec 15 14:30:51 2020 +0100
>
> Add opens for Java 16
> ---
>  build.xml | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/build.xml b/build.xml
> index f937fc3..913dd0c 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -226,6 +226,10 @@
>   property="java9.test.option.4"
>   value="--add-opens=java.base/java.util=ALL-UNNAMED"/>
>
> +   + property="java9.test.option.5"
> +
>  value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/>
> +  
>
>
>
> @@ -1947,6 +1951,7 @@
>  
>  
>  
> +
>

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


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


Re: JDK 16 is in Rampdown Phase One

2020-12-15 Thread Martin Grigorov
Hi Rémy,

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

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

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

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

^^ this fixes them!


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


Re: JDK 16 is in Rampdown Phase One

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

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

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



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

Re: JDK 16 is in Rampdown Phase One

2020-12-14 Thread Martin Grigorov
On Mon, Dec 14, 2020 at 10:08 AM Rémy Maucherat  wrote:

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

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

But the next problem is:

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

Re: JDK 16 is in Rampdown Phase One

2020-12-13 Thread Martin Grigorov
Hi Tomcat team,

The following tests fail on JDK 16 b28:

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


with this reason:

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

Regards,
Martin

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

> Hi Mark,
>
> *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] .
> *
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.*
>
>   * Schedule for JDK 16
>   o *2020/12/10 Rampdown Phase One*
>   o 2021/01/14  Rampdown Phase Two
>   o 2021/02/04  Initial Release Candidate
>   o 2021/02/18  Final Release Candidate
>   o 2021/03/16  General Availability
>   * Release Notes [2]
>
> OpenJDK 16 Early Access build 28**is now available at
> http://jdk.java.net/16
>
>   * Features - the overall feature set is frozen. No further JEPs will
> be targeted to this release.
>   * Significant Integrations in b28:
>   o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by
> Default **
> *
>   + Strongly encapsulate all internal elements of the JDK by
> default, except for critical internal APIs
>  such as
> |sun.misc.Unsafe|.
>   + Allow end users to choose the relaxed strong encapsulation
> that has been the default since JDK 9.
>   o Integrated JEP 397: Sealed Classes (Second Preview)
>  with this release.
>   + Enhance the Java programming language with sealed classes
> and interfaces
> .
>   + Refines JEP 360  which
> was delivered in JDK 15 as a preview feature.
>
>   * These early-access , open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Changes in recent builds that maybe of interest:
>   o Build 28
>   + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by
> Default
>   + JDK-8166596: TLS support for the EdDSA signature algorithm
>   + JDK-8256718: Old tracing flags are now obsolete and must be
> replaced with unified logging
>   o Build 27
>   + JDK-8159746: (proxy) Support for default methods
>   + JDK-8254631: Better support ALPN byte wire values in SunJSSE
>
> Project Loom Early-Access: *Build 16-loom+9-316
> * (2020/11/30) - based on JDK-16+25
> 
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> 
>   * These builds are intended for developers looking to "kick the tyres"
> and provide feedback on using the API or by sending bug reports.
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> Rgds, Rory
>
> [1]
> 

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

2020-12-11 Thread Martin Grigorov
On Fri, Dec 11, 2020, 21:34 Christopher Schultz <
ch...@christopherschultz.net> wrote:

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

Re: [VOTE] Release Apache Tomcat Native 1.2.26

2020-12-11 Thread Martin Grigorov
On Thu, Dec 10, 2020 at 11:10 PM Mark Thomas  wrote:

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

UDS works well!

Martin


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


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

2020-12-11 Thread Martin Grigorov
On Fri, Dec 11, 2020 at 1:20 PM Rainer Jung  wrote:

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

This works perfect!
Thank you, Rainer!


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


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

2020-12-11 Thread Martin Grigorov
On Fri, Dec 11, 2020 at 10:53 AM Mark Thomas  wrote:

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

Do we need to fix it ? It works fine.


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


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

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

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

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

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


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


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

2020-12-11 Thread Martin Grigorov
Hi Rainer,

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

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

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


>
> Maybe one could
>
>cd `dirname $0`
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


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

2020-12-10 Thread Martin Grigorov
On Thu, Dec 10, 2020 at 1:39 PM Mark Thomas  wrote:

> The proposed Apache Tomcat migration tool for Jakarta EE 0.1.0 is now
> available for voting.
>
> This is (potentially) the first release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/jakartaee-migration/v0.1.0/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1291/
>
> The tag is:
> https://github.com/apache/tomcat-jakartaee-migration/tree/0.1.0
> cbada3204bf9c43ca0cf481cd88c7521690b30a0
>
> The proposed 0.1.0 release is:
>
> [ ] -1: Broken. Do not release because...
> [ X ] +1: Acceptable. Go ahead and release.
>

Regards,
Martin


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


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

2020-12-10 Thread Martin Grigorov
On Thu, Dec 10, 2020 at 11:50 PM Igal Sapir  wrote:

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

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

Martin


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


Re: Snapshot published for Jakarta EE migration tool

2020-12-09 Thread Martin Grigorov
On Tue, Dec 8, 2020 at 8:13 PM Martin Grigorov  wrote:

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

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


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


Re: Snapshot published for Jakarta EE migration tool

2020-12-08 Thread Martin Grigorov
On Tue, Dec 8, 2020, 19:13 Mark Thomas  wrote:

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

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


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


io_uring backend for NIO

2020-12-07 Thread Martin Grigorov
Hi devs,

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

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

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

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

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

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

- io_uring

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

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

and the results were better but not so dramatic:

- epoll

-- x86_64: 24688 reqs/sec

-- aarch64: 25344

- uring

-- x86_64: 26731

-- aarch64: 28443


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

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

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

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

make use of it.


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

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

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

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

soon).

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

should not be considered as a stopper.


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

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


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


Regards,

Martin


Re: [VOTE] Release Apache Tomcat 10.0.0

2020-12-06 Thread Martin Grigorov
On Thu, Dec 3, 2020 at 12:50 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.0-M10 are:
>
> - Specs are now final. Tomcat passes the TCKs apart from a number of
>   expected failures that don't impact spec compliance.
>
> - The APR/Native AJP and HTTP connectors have been deprecated.
>   Tomcat Native will continue to be used to support OpenSSL use with NIO
>   and NIO2.
>
> - Align the behaviour of ServletContext.getRealPath(String path) with
>   the recent clarification from the Servlet specification project. If
>   the path parameter does not start with / then Tomcat processes the
>   call as if / is appended to the beginning of the provided path.
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1287/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0
> 4c8b650437e2464c1c31c6598a263b3805b7a81f
>
> The proposed 10.0.0 release is:
> [ ] Broken - do not release
> [ X ] Beta   - go ahead and release as 10.0.0 (beta)
> [ ] Stable - go ahead and release as 10.0.0 (stable)
>
>
Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.41

2020-12-06 Thread Martin Grigorov
On Thu, Dec 3, 2020 at 3:12 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.41 release is now available for voting.
>
> The notable changes compared to the 9.0.40 release are:
>
> - Align the behaviour of ServletContext.getRealPath(String path) with
>   the recent clarification from the Servlet specification project. If
>   the path parameter does not start with / then Tomcat processes the
>   call as if / is appended to the beginning of the provided path.
>
> - Fix a potential file descriptor leak when WebSocket connections are
>   attempted and fail. Patch provided by Maurizio Adami.
>
> -  Ensure that the LoadBalancerDrainingValve uses the correct setting
>for the secure attribute for any session cookies it creates. Based on
>a pull request by Andreas Kurth.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.41/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1289/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.41
> 75d7a2069bf4360bcd8b885c6b7387d70c9cb052
>
> The proposed 9.0.41 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.41
>

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 8.5.61

2020-12-06 Thread Martin Grigorov
On Thu, Dec 3, 2020 at 4:50 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.61 release is now available for voting.
>
> The notable changes compared to the 8.5.60 release are:
>
> - Align the behaviour of ServletContext.getRealPath(String path) with
>   the recent clarification from the Servlet specification project. If
>   the path parameter does not start with / then Tomcat processes the
>   call as if / is appended to the beginning of the provided path.
>
> - Fix a potential file descriptor leak when WebSocket connections are
>   attempted and fail. Patch provided by Maurizio Adami.
>
> - Ensure that the LoadBalancerDrainingValve uses the correct setting
>   for the secure attribute for any session cookies it creates. Based on
>   a pull request by Andreas Kurth.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.61/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1290/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.61
> 77d330abea52e4aeb039ca7eb8a766e0e1c56a71
>
> The proposed 8.5.61 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.61
>


Regards,
Martin


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


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

2020-12-03 Thread Martin Grigorov
Hi,

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

Martin

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

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


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

2020-12-01 Thread Martin Grigorov
Hi Graham,

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

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

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

Regards,
Martin


>
> Regards,
> Graham
> —
>
>


Re: JDK 16 Early Access build 26 is now available

2020-11-30 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


Re: Tomcat 10.0.x and Jakarta 9 TCK status

2020-11-23 Thread Martin Grigorov
On Mon, Nov 23, 2020, 17:07 Mark Thomas  wrote:

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


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

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

Awesome!


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


Re: [VOTE] Release Apache Tomcat 7.0.107

2020-11-19 Thread Martin Grigorov
On Wed, Nov 18, 2020 at 3:00 PM Violeta Georgieva 
wrote:

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

Tested with Apache Wicket 8.x examples application.

Regards,
Martin


>
> Regards,
> Violeta
>


Re: JDK 16 Early Access build 24 is now available

2020-11-13 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


Re: [VOTE] Release Apache Tomcat 8.5.60

2020-11-13 Thread Martin Grigorov
On Thu, Nov 12, 2020 at 7:54 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.60 release is now available for voting.
>
> The notable changes compared to the 8.5.59 release are:
>
> - Statistics are now available (via JMX) for HTTP/2, WebSocket and
>   HTTP/1.1 upgraded connections
>
> - Stability improvements for HTTP/2
>
> - Improvements to error handling in the connection pool used by the JNDI
>   Realm
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.60/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1285/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.60
> 04d663d7541a013098db3a3f81b1c23c255c12a4
>
> The proposed 8.5.60 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 8.5.60
>

Tested with Apache Wicket 9.x examples app.

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 9.0.40

2020-11-13 Thread Martin Grigorov
On Thu, Nov 12, 2020 at 5:58 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.40 release is now available for voting.
>
> The notable changes compared to the 9.0.39 release are:
>
> - Statistics are now available (via JMX) for HTTP/2, WebSocket and
>   HTTP/1.1 upgraded connections
>
> - Stability improvements for HTTP/2
>
> - Stability improvements for the NIO connector
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.40/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1284/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.40
> 11cce490eb67a8aca64377a22c0cea2e38896725
>
> The proposed 9.0.40 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 9.0.40
>

Tested with Apache Wicket 9.x examples app.

Regards,
Martin


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


Re: [VOTE] Release Apache Tomcat 10.0.0-M10

2020-11-13 Thread Martin Grigorov
On Thu, Nov 12, 2020 at 2:33 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 10.0.0-M10 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes.
>
> The notable changes compared to 10.0.0-M9 are:
>
> - Statistics are now available (via JMX) for HTTP/2, WebSocket and
>   HTTP/1.1 upgraded connections
>
> - Stability improvements for HTTP/2
>
> - Stability improvements for the NIO connector
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0-M10/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1283/
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.0-M10
> 9826be4c8368c94eab1e804b456867ca1cb766c3
>
> The proposed 10.0.0-M10 release is:
> [ ] Broken - do not release
> [ X ] Alpha  - go ahead and release as 10.0.0-M10
>

Tested with Apache Wicket 9.x examples.

Regards,
Martin


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


Re: JDK 16 EA build 21 is available

2020-10-23 Thread Martin Grigorov
Hi Rory,

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

Regards,
Martin

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

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


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

2020-10-22 Thread Martin Grigorov
On Thu, Oct 22, 2020 at 5:56 PM  wrote:

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

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


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


  1   2   3   4   5   >