[VOTE][RESULT] Release Apache Tomcat Native 1.2.28

2021-04-06 Thread Mark Thomas 

The following votes were cast:

Binding:
+1: schultz, remm, markt, isapir, mgrigorov, fschumacher, csutherl

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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

svn commit: r1888428 - in /tomcat/site/trunk/docs/native-doc: index.html miscellaneous/changelog.html news/2021.html

2021-04-06 Thread markt 
Author: markt
Date: Tue Apr  6 10:54:02 2021
New Revision: 1888428

URL: http://svn.apache.org/viewvc?rev=1888428&view=rev
Log:
Update Native docs for 1.2.28 release

Modified:
tomcat/site/trunk/docs/native-doc/index.html
tomcat/site/trunk/docs/native-doc/miscellaneous/changelog.html
tomcat/site/trunk/docs/native-doc/news/2021.html

Modified: tomcat/site/trunk/docs/native-doc/index.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/native-doc/index.html?rev=1888428&r1=1888427&r2=1888428&view=diff
==
--- tomcat/site/trunk/docs/native-doc/index.html (original)
+++ tomcat/site/trunk/docs/native-doc/index.html Tue Apr  6 10:54:02 2021
@@ -28,10 +28,10 @@
 Headlines
 
 
-29 Mar 2021 - TC-Native-1.2.27
+6 Apr 2021 - TC-Native-1.2.28
 released
 The Apache Tomcat team is proud to announce the immediate availability of
-Tomcat Native 1.2.27 Stable.
+Tomcat Native 1.2.28 Stable.
 
 The sources and the binaries for selected platforms are available from the
 Download page.

Modified: tomcat/site/trunk/docs/native-doc/miscellaneous/changelog.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/native-doc/miscellaneous/changelog.html?rev=1888428&r1=1888427&r2=1888428&view=diff
==
--- tomcat/site/trunk/docs/native-doc/miscellaneous/changelog.html (original)
+++ tomcat/site/trunk/docs/native-doc/miscellaneous/changelog.html Tue Apr  6 
10:54:02 2021
@@ -3,10 +3,18 @@
   
   This is the Changelog for Tomcat Native 1.2.
   
+Changes in 1.2.28
+  
+
+  Correct a regression in the fix for https://bz.apache.org/bugzilla/show_bug.cgi?id=65181";>65181 that 
prevented an
+  error message from being displayed if an invalid key file was provided
+  and no OpenSSL Engine was configured. (markt)
+
+  
 Changes in 1.2.27
   
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=65181";>65181: 
Improve support for using OpenSSL Engines that use
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=65181";>65181: Improve 
support for using OpenSSL Engines that use
   proprietary key formats. Patch provided by Edin Hodzic. (markt)
 
 
@@ -19,7 +27,7 @@
   Enable building to continue against OpenSSL 3.x and 1.1.1. (markt)
 
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=64942";>64942: 
Expose support for Unix Domain Sockets in APR v1.6 and up. (minfrin)
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=64942";>64942: Expose 
support for Unix Domain Sockets in APR v1.6 and up. (minfrin)
 
 
   Update recommended OpenSSL version to 1.1.1i or later. (markt)
@@ -53,23 +61,23 @@
   (jfclere)
 
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=64429";>64429: Fix 
compilation with LibreSSL. (markt)
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=64429";>64429: Fix 
compilation with LibreSSL. (markt)
 
   
 Changes in 1.2.24
   
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=63671";>63671: 
libtcnative does not compile with OpenSSL < 1.1.0
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=63671";>63671: 
libtcnative does not compile with OpenSSL < 1.1.0
   and APR w/o threading support. (michaelo)
 
 
   Correct configure message for OpenSSL libdir. (michaelo)
 
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=64260";>64260: Clean 
up install target. (michaelo)
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=64260";>64260: Clean up 
install target. (michaelo)
 
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=64315";>64315: 
configure output for OpenSSL wrong/incomplete sometimes.
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=64315";>64315: 
configure output for OpenSSL wrong/incomplete sometimes.
   (michaelo)
 
 
@@ -80,11 +88,11 @@
   ssl_thread_id(void). (michaelo)
 
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=63701";>63701: Use 
new OpenSSL initialisation process when building with
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=63701";>63701: Use new 
OpenSSL initialisation process when building with
   OpenSSL 1.1.0 onwards. (mturk)
 
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=64316";>64316: 
Introduce tcn_get_thread_id(void) to reduce code
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=64316";>64316: 
Introduce tcn_get_thread_id(void) to reduce code
  duplication. (michaelo)
 
 
@@ -107,16 +115,16 @@
 Changes in 1.2.22
   
 
-  http://issues.apache.org/bugzilla/show_bug.cgi?id=63159";>63159: 
Unable to complete build when build directory is
+  https://bz.apache.org/bugzilla/show_bug.cgi?id=63159";>63159: Unable 
to complete build when build directory is
   outside of the source tree. Patch provided by Bob Huemmer. (markt)
 
 
-  http://issu

svn commit: r46886 - /dev/tomcat/tomcat-connectors/native/1.2.28/ /release/tomcat/tomcat-connectors/native/1.2.28/

2021-04-06 Thread markt 
Author: markt
Date: Tue Apr  6 10:54:56 2021
New Revision: 46886

Log:
Release Apache Tomcat Native 1.2.28

Added:
release/tomcat/tomcat-connectors/native/1.2.28/
  - copied from r46885, dev/tomcat/tomcat-connectors/native/1.2.28/
Removed:
dev/tomcat/tomcat-connectors/native/1.2.28/


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

[VOTE][RESULT] Release Apache Tomcat 10.0.5

2021-04-06 Thread Mark Thomas 

The following votes were cast:

Binding:
+1: isapir, remm, mgrigorov, fschumacher

The vote therefore passes.

Thanks to everyone who voted.

Mark

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

svn commit: r46887 - /dev/tomcat/tomcat-10/v10.0.5/ /release/tomcat/tomcat-10/v10.0.5/

2021-04-06 Thread markt 
Author: markt
Date: Tue Apr  6 11:07:33 2021
New Revision: 46887

Log:
Release Apache Tomcat 10.0.5

Added:
release/tomcat/tomcat-10/v10.0.5/
  - copied from r46886, dev/tomcat/tomcat-10/v10.0.5/
Removed:
dev/tomcat/tomcat-10/v10.0.5/


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

[VOTE][RESULT] Release Apache Tomcat 9.0.45

2021-04-06 Thread Mark Thomas 

The following votes were cast:

Binding:
+1: isapir, remm, mgrigorov, fschumacher

Non-binding:
+1: rmannibucau

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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

svn commit: r46888 - /dev/tomcat/tomcat-9/v9.0.45/ /release/tomcat/tomcat-9/v9.0.45/

2021-04-06 Thread markt 
Author: markt
Date: Tue Apr  6 11:11:19 2021
New Revision: 46888

Log:
Release Apache Tomcat 9.0.45

Added:
release/tomcat/tomcat-9/v9.0.45/
  - copied from r46887, dev/tomcat/tomcat-9/v9.0.45/
Removed:
dev/tomcat/tomcat-9/v9.0.45/


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

[VOTE][RESULT] Release Apache Tomcat 8.5.65

2021-04-06 Thread Mark Thomas 

The following votes were cast:

Binding:
+1: isapir, mgrigorov, remm, fschumacher

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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

svn commit: r46889 - /dev/tomcat/tomcat-8/v8.5.65/ /release/tomcat/tomcat-8/v8.5.65/

2021-04-06 Thread markt 
Author: markt
Date: Tue Apr  6 11:13:56 2021
New Revision: 46889

Log:
Release Apache Tomcat 8.5.65

Added:
release/tomcat/tomcat-8/v8.5.65/
  - copied from r46888, dev/tomcat/tomcat-8/v8.5.65/
Removed:
dev/tomcat/tomcat-8/v8.5.65/


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

[tomcat-native] branch master updated: Update with actual release date for 1.2.28

2021-04-06 Thread markt 
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-native.git


The following commit(s) were added to refs/heads/master by this push:
 new 03fed6c  Update with actual release date for 1.2.28
03fed6c is described below

commit 03fed6c698ac8daf273820056171de85f52e55ec
Author: Mark Thomas 
AuthorDate: Tue Apr 6 11:50:02 2021 +0100

Update with actual release date for 1.2.28
---
 xdocs/index.xml | 2 +-
 xdocs/news/2021.xml | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xdocs/index.xml b/xdocs/index.xml
index e4b5a69..239a392 100644
--- a/xdocs/index.xml
+++ b/xdocs/index.xml
@@ -60,7 +60,7 @@
 
 
 
-8 Apr 2021 - TC-Native-1.2.28
+6 Apr 2021 - TC-Native-1.2.28
 released
 The Apache Tomcat team is proud to announce the immediate availability of
 Tomcat Native 1.2.28 Stable.
diff --git a/xdocs/news/2021.xml b/xdocs/news/2021.xml
index 115180d..3fc92f8 100644
--- a/xdocs/news/2021.xml
+++ b/xdocs/news/2021.xml
@@ -29,7 +29,7 @@
 
 
 
- 
+ 
   The Apache Tomcat team is proud to announce the immediate availability of
   Tomcat Native 1.2.28. This is a bugfix release.
   

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

Re: TCK Signature for EL API

2021-04-06 Thread Mark Thomas 

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 Tomcat always overrides any such setting.
The Servlet spec allows this setting to be overridden but the TCK test
doesn't consider the possibility that a container will always do this.
Therefore we simply treat this as an expected failure. Full details

for

all the TCKs we run can be found on the Wiki:

https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs

The EL signature test failure is another example of a failure that we
consider can be safely ignored.

Tomcat does not, and has not for many, many years, formally certified
against the Jakarta EE / Java EE TCKs. I am not aware of any user
request at any point in that time to complete formal certification.
Therefore, I expect that Tomcat will continue following its current
pragmatic approach to the TCKs.

Mark

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







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




--
Jean-Louis







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

Re: [PROPOSAL] Explicitly-set the request character encoding when it has been committed

2021-04-06 Thread Mark Thomas 

On 05/04/2021 13:19, Christopher Schultz wrote:



I'm happy with incremental changes. Making the first change will be an 
improvement for sure.


On the other hand, if code calls request.setCharacterEncoding(non-null) 
then it will overwrite whatever the request had previously sent 
(including null). So in that case, request.getCharacterEncoding isn't 
always returning "what the client sent".


Another place where there is scope to add further clarity to the spec.

Mark

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

Re: TCK Signature for EL API

2021-04-06 Thread Raymond Augé 
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.

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 Tomcat always overrides any such
> setting.
> > The Servlet spec allows this setting to be overridden but the TCK
> test
> > doesn't consider the possibility that a container will always do
> this.
> > Therefore we simply treat this as an expected failure. Full details
> >> for
> > all the TCKs we run can be found on the Wiki:
> >
> > https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> >
> > The EL signature test failure is another example of a failure that we
> > consider can be safely ignored.
> >
> > Tomcat does not, and has not for many, many years, formally certified
> > against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > request at any point in that time to complete formal cer