Re: Backport to Java 11 for JDK-8240871

2020-10-16 Thread Mark Thomas
On 16/10/2020 15:49, Rory O'Donnell wrote:
> Hi Mark,
> 
> No details yet, but plan to backport to a JDK11 Update in the future.

Thanks for the update.

Mark


> 
> Rgds,Rory
> 
> On 16/10/2020 08:47, Rory O'Donnell wrote:
>> Hi Mark,
>>
>> Let me check if there are plans.
>>
>> Probably useful to add backport request to JBS report when confirming
>> the fix.
>>
>> Rgds,Rory
>>
>> On 15/10/2020 19:33, Mark Thomas wrote:
>>> Hi Rory,
>>>
>>> How do I find out what the plans are for back-porting this TLS 1.3 fix
>>> to Java 11?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8240871
>>>
>>> If there are no plans to backport, how do I put in a request for one?
>>>
>>> Thanks,
>>>
>>> Mark
>>


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



Backport to Java 11 for JDK-8240871

2020-10-15 Thread Mark Thomas
Hi Rory,

How do I find out what the plans are for back-porting this TLS 1.3 fix
to Java 11?

https://bugs.openjdk.java.net/browse/JDK-8240871

If there are no plans to backport, how do I put in a request for one?

Thanks,

Mark

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



Re: [tomcat] 02/02: Complete fix for BZ 63362. Collect stats for h2, websocket and upgrade

2020-10-15 Thread Mark Thomas
On 15/10/2020 09:46, 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
> 
> commit c5e4066fc25c2b8611e476199d3361341c473257
> Author: Mark Thomas 
> AuthorDate: Thu Oct 15 09:45:47 2020 +0100
> 
> Complete fix for BZ 63362. Collect stats for h2, websocket and upgrade

This has more moving parts than I would like because of all the
different variations that need to be covered. There may be some
simplifications that I missed.

Mark

> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63362
> ---
>  java/org/apache/catalina/connector/Request.java|   2 +-
>  java/org/apache/coyote/AbstractProtocol.java   |  17 ---
>  java/org/apache/coyote/LocalStrings.properties |   1 -
>  java/org/apache/coyote/UpgradeProtocol.java|  22 
>  java/org/apache/coyote/UpgradeToken.java   |   9 +-
>  .../coyote/http11/AbstractHttp11Protocol.java  |  97 -
>  java/org/apache/coyote/http11/Http11Processor.java |   2 +-
>  .../apache/coyote/http11/LocalStrings.properties   |   2 +
>  .../http11/upgrade/InternalHttpUpgradeHandler.java |   4 +
>  .../coyote/http11/upgrade/UpgradeGroupInfo.java| 120 
> +
>  .../apache/coyote/http11/upgrade/UpgradeInfo.java  |  96 +
>  .../http11/upgrade/UpgradeProcessorExternal.java   |  14 ++-
>  .../http11/upgrade/UpgradeProcessorInternal.java   |  12 ++-
>  .../http11/upgrade/UpgradeServletInputStream.java  |  17 ++-
>  .../http11/upgrade/UpgradeServletOutputStream.java |   7 +-
>  java/org/apache/coyote/http2/Http2Protocol.java|  49 -
>  .../apache/coyote/http2/LocalStrings.properties|   2 +
>  java/org/apache/coyote/http2/StreamProcessor.java  |   6 +-
>  java/org/apache/coyote/mbeans-descriptors.xml  |  30 ++
>  java/org/apache/tomcat/websocket/WsFrameBase.java  |  13 +++
>  .../tomcat/websocket/WsRemoteEndpointImplBase.java |  15 +++
>  .../tomcat/websocket/server/WsFrameServer.java |  14 ++-
>  .../websocket/server/WsHttpUpgradeHandler.java |  12 ++-
>  .../server/WsRemoteEndpointImplServer.java |  12 ++-
>  .../apache/coyote/http11/upgrade/TestUpgrade.java  |   4 +
>  webapps/docs/changelog.xml |   4 +-
>  26 files changed, 489 insertions(+), 94 deletions(-)
> 
> diff --git a/java/org/apache/catalina/connector/Request.java 
> b/java/org/apache/catalina/connector/Request.java
> index 48e0167..2177a92 100644
> --- a/java/org/apache/catalina/connector/Request.java
> +++ b/java/org/apache/catalina/connector/Request.java
> @@ -2017,7 +2017,7 @@ public class Request implements HttpServletRequest {
>  throw new ServletException(e);
>  }
>  UpgradeToken upgradeToken = new UpgradeToken(handler,
> -getContext(), instanceManager);
> +getContext(), instanceManager, 
> response.getHeader("upgrade"));
>  
>  coyoteRequest.action(ActionCode.UPGRADE, upgradeToken);
>  
> diff --git a/java/org/apache/coyote/AbstractProtocol.java 
> b/java/org/apache/coyote/AbstractProtocol.java
> index 159531e..e3ce9d7 100644
> --- a/java/org/apache/coyote/AbstractProtocol.java
> +++ b/java/org/apache/coyote/AbstractProtocol.java
> @@ -559,13 +559,6 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  endpoint.setDomain(domain);
>  
>  endpoint.init();
> -
> -UpgradeProtocol[] upgradeProtocols = findUpgradeProtocols();
> -for (UpgradeProtocol upgradeProtocol : upgradeProtocols) {
> -// Implementation note: Failure of one upgrade protocol fails the
> -// whole Connector
> -upgradeProtocol.init();
> -}
>  }
>  
>  
> @@ -679,16 +672,6 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  logPortOffset();
>  }
>  
> -UpgradeProtocol[] upgradeProtocols = findUpgradeProtocols();
> -for (UpgradeProtocol upgradeProtocol : upgradeProtocols) {
> -try {
> -upgradeProtocol.destroy();
> -} catch (Throwable t) {
> -ExceptionUtils.handleThrowable(t);
> -
> getLog().error(sm.getString("abstractProtocol.upgradeProtocolDestroyError"), 
> t);
> -}
> -}
> -
>  try {
>  endpoint.destroy();
>  } finally {
> diff --git a/java/org/apache/coyote/LocalStrings.properties 
> b/java/org/apache/coyote/LocalStrings.properties
> index 43c8d64..83960cb 100644
> --- a/java/org/apache/co

Re: Cannot override servlet context init param

2020-10-14 Thread Mark Thomas
On 14/10/2020 08:13, Mark Thomas wrote:
> On 14/10/2020 01:31, Matt Benson wrote:
>> Hello,
>> Today I was experimenting with a Servlet ContainerInitializer in which I
>> wanted to modify the value of a particular init param, but found that
>> Tomcat's ServletContext implementation (ApplicationContext) explicitly
>> rejected the override. The Servlet API doesn't seem to suggest that what
>> I'm trying to do should not be supported; would a patch (or patches,
>> thinking of multiple Tomcat versions) to support this behavior, perhaps
>> conditionally, be welcome? If so, what form should such conditional support
>> take?
> 
> Just to be clear about what you are trying to do.
> 
> All of this is within a single web application.
> 
> You are trying to use a ServletContainerInitializer (I assume one
> deployed as part of the web application so it has been discovered via
> the ServiceLoader API in a JAR located under WEB-INF/lib) to override a
> ServletContext init parameter that is defined in web.xml.
> 
> Is that correct?
> 
> Mark
> (who is off to remind himself what the spec does (and doesn't) say about
> this)

The relevant text is in the Javadoc for ServletContext#setInitParameter.
The description of the return value effectively states that init
parameters may not be overridden.

I think it is unlikely that a patch to change this behaviour would be
accepted as it is likely that there is an alternative, spec compliant,
way to achieve the same ends.

Mark

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



Re: Cannot override servlet context init param

2020-10-14 Thread Mark Thomas
On 14/10/2020 01:31, Matt Benson wrote:
> Hello,
> Today I was experimenting with a Servlet ContainerInitializer in which I
> wanted to modify the value of a particular init param, but found that
> Tomcat's ServletContext implementation (ApplicationContext) explicitly
> rejected the override. The Servlet API doesn't seem to suggest that what
> I'm trying to do should not be supported; would a patch (or patches,
> thinking of multiple Tomcat versions) to support this behavior, perhaps
> conditionally, be welcome? If so, what form should such conditional support
> take?

Just to be clear about what you are trying to do.

All of this is within a single web application.

You are trying to use a ServletContainerInitializer (I assume one
deployed as part of the web application so it has been discovered via
the ServiceLoader API in a JAR located under WEB-INF/lib) to override a
ServletContext init parameter that is defined in web.xml.

Is that correct?

Mark
(who is off to remind himself what the spec does (and doesn't) say about
this)

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



Re: [tomcat] branch master updated: Partial fix for BZ 63362 provide h2 request statistics

2020-10-13 Thread Mark Thomas
On 09/10/2020 17:43, 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 62a684c  Partial fix for BZ 63362 provide h2 request statistics
> 62a684c is described below
> 
> commit 62a684cd2b2039a68e74813cf4e20fc95a2cebe4
> Author: Mark Thomas 
> AuthorDate: Wed Jun 24 19:24:17 2020 +0100
> 
> Partial fix for BZ 63362 provide h2 request statistics

Just a quick heads up that as I work on WebSocket (and a generic
solution for any HTTP upgrade protocol) it is looking as if a chunk of
the changes below are going to be reverted.

Mark


> ---
>  java/org/apache/coyote/AbstractProtocol.java  | 35 +++
>  java/org/apache/coyote/LocalStrings.properties|  1 +
>  java/org/apache/coyote/UpgradeProtocol.java   | 22 
>  java/org/apache/coyote/http2/Http2Protocol.java   | 41 
> +++
>  java/org/apache/coyote/http2/StreamProcessor.java |  6 
>  webapps/docs/changelog.xml|  4 +++
>  6 files changed, 102 insertions(+), 7 deletions(-)
> 
> diff --git a/java/org/apache/coyote/AbstractProtocol.java 
> b/java/org/apache/coyote/AbstractProtocol.java
> index e214f80..159531e 100644
> --- a/java/org/apache/coyote/AbstractProtocol.java
> +++ b/java/org/apache/coyote/AbstractProtocol.java
> @@ -69,12 +69,6 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  
>  
>  /**
> - * Name of MBean for the Global Request Processor.
> - */
> -protected ObjectName rgOname = null;
> -
> -
> -/**
>   * Unique ID for this connector. Only used if the connector is configured
>   * to use a random port as the port will change if stop(), start() is
>   * called.
> @@ -145,6 +139,14 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  // --- Properties managed by the 
> ProtocolHandler
>  
>  /**
> + * Name of MBean for the Global Request Processor.
> + */
> +protected ObjectName rgOname = null;
> +public ObjectName getGlobalRequestProcessorMBeanName() {
> +return rgOname;
> +}
> +
> +/**
>   * The adapter provides the link between the ProtocolHandler and the
>   * connector.
>   */
> @@ -546,7 +548,8 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  }
>  
>  if (this.domain != null) {
> -rgOname = new ObjectName(domain + 
> ":type=GlobalRequestProcessor,name=" + getName());
> +ObjectName rgOname = new ObjectName(domain + 
> ":type=GlobalRequestProcessor,name=" + getName());
> +this.rgOname = rgOname;
>  Registry.getRegistry(null, null).registerComponent(
>  getHandler().getGlobal(), rgOname, null);
>  }
> @@ -556,6 +559,13 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  endpoint.setDomain(domain);
>  
>  endpoint.init();
> +
> +UpgradeProtocol[] upgradeProtocols = findUpgradeProtocols();
> +for (UpgradeProtocol upgradeProtocol : upgradeProtocols) {
> +// Implementation note: Failure of one upgrade protocol fails the
> +// whole Connector
> +upgradeProtocol.init();
> +}
>  }
>  
>  
> @@ -669,6 +679,16 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  logPortOffset();
>  }
>  
> +UpgradeProtocol[] upgradeProtocols = findUpgradeProtocols();
> +for (UpgradeProtocol upgradeProtocol : upgradeProtocols) {
> +try {
> +upgradeProtocol.destroy();
> +} catch (Throwable t) {
> +ExceptionUtils.handleThrowable(t);
> +
> getLog().error(sm.getString("abstractProtocol.upgradeProtocolDestroyError"), 
> t);
> +}
> +}
> +
>  try {
>  endpoint.destroy();
>  } finally {
> @@ -686,6 +706,7 @@ public abstract class AbstractProtocol implements 
> ProtocolHandler,
>  }
>  }
>  
> +ObjectName rgOname = getGlobalRequestProcessorMBeanName();
>  if (rgOname != null) {
>  Registry.getRegistry(null, 
> null).unregisterComponent(rgOname);
>  }
> diff --git a/java/org/apache/coyote/LocalStrings.propertie

Re: [DISCUSS] Deprecate and remove RealmBase#stripRealmForGss

2020-10-13 Thread Mark Thomas
On 13/10/2020 10:48, Michael Osipov wrote:
> Folks,
> 
> I'd like to propose to get rid of that config option in 10 and deprecate
> in previous versions for the following reasons:
> 
> * It suffers from abstraction: It assumes that the GSS name is always
> email style w/o checking its OID
> * The realm part, if any, is an integeral part of the principal. Much
> like with an email address' domain. You wouldn't stip here too, would you?
> * It is a surprise for clients having the princippal mutilated by
> default. I trip over and over again this when I set up
> UserDatabaseRealms for testing purposes I wonder why
> michae...@example.com does not work.
> * In a multi realm environment, it is perfectly fine and valid to have
> user1@REALMA and user1@REALMB. These are distinct principals, but
> treated by RealmBase equally, this has implications.
> * Finally, when doing cert-based auth in an AD envinronment, is it
> pretty common to extract the msUPN name from the cert's SAN which is
> almost always email address (enteprise principal) which would end up in
> michael.osipov, but where is the rest?!
> 
> Thoughts?

No objections to changing the default to false in 10.0.x but I think
removal/deprecation is a step too far.

Not everyone uses the full u...@bigco.com format as the "primary key" in
their internal user database. I see lots of variation depending on which
system is viewed as the source of truth to which other systems are
synchronised.

We have X509UsernameRetriever for certificate authentication. That came
out of bug 52500 where the aim was to support a wide variety of formats.
The root of that requirement was essentially the same - integration with
a variety of systems where the user name could be in in a range of
formats. The mapping of that format to an X509 cert just added another
layer of complexity.

If there was user demand for it (I haven't seen any) I'd support a
similar interface for SPNEGO. With such an interface in place,
deprecation and removal of stripRealmForGss would make sense.

Mark

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



[SECURITY] CVE-2020-13943 Apache Tomcat HTTP/2 Request mix-up

2020-10-12 Thread Mark Thomas
CVE-2020-13943 Apache Tomcat HTTP/2 Request mix-up

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.0.0-M1 to 10.0.0-M7
Apache Tomcat 9.0.0.M5 to 9.0.37
Apache Tomcat 8.5.1 to 8.5.57

Description:
If an HTTP/2 client exceeded the agreed maximum number of concurrent
streams for a connection (in violation of the HTTP/2 protocol), it was
possible that a subsequent request made on that connection could contain
HTTP headers - including HTTP/2 pseudo headers - from a previous request
rather than the intended headers. This could lead to users seeing
responses for unexpected resources.

Mitigation:
- Upgrade to Apache Tomcat 10.0.0-M8 or later
- Upgrade to Apache Tomcat 9.0.38 or later
- Upgrade to Apache Tomcat 8.5.58 or later

Credit:
This issue was identified by the Apache Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-10.html
[2] http://tomcat.apache.org/security-9.html
[3] http://tomcat.apache.org/security-8.html

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



[ANN] Apache Tomcat 8.5.59 available

2020-10-12 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.59.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled
forward from the 9.0.x branch. The notable changes since 8.5.58 include:

- Refactor the handling of closed HTTP/2 streams to reduce the heap
  usage associated with used streams and to retain information for more
  streams in the priority tree.

- Deprecate the JDBCRealm.

- Ensure that none of the methods on a ServletContext instance always
  fail when running under a SecurityManager. Pull request provided by
  Kyle Stiemann.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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



[ANN] Apache Tomcat 9.0.39 available

2020-10-12 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.39.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.39 is a bugfix and feature release. The notable
changes compared to 9.0.38 include:

- Refactor the handling of closed HTTP/2 streams to reduce the heap
  usage associated with used streams and to retain information for more
  streams in the priority tree.

- Allow using the utility executor for annotation scanning. Patch
  provided by Jatin Kamnani.

- Add a bloom filter to speed up archive lookup and improve deployment
  speed of applications with a large number of JARs. Patch provided by
  Jatin Kamnani.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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



[ANN] Apache Tomcat 10.0.0-M9 available

2020-10-12 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.0-M9.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is under development to aid
this process.

Apache Tomcat 10.0.0-M9 is a milestone release of the 10.0.x
branch and has been made to provide users with early access to the new
features in Apache Tomcat 10.0.x so that they may provide feedback. The
notable changes compared to 10.0.0-M8 include:

- Refactor the handling of closed HTTP/2 streams to reduce the heap
  usage associated with used streams and to retain information for more
  streams in the priority tree.

- Allow using the utility executor for annotation scanning. Patch
  provided by Jatin Kamnani.

- Add a bloom filter to speed up archive lookup and improve deployment
  speed of applications with a large number of JARs. Patch provided by
  Jatin Kamnani.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Re: [Bug 60030] Run away CPU with JSSE / OpenSSL with IE8

2020-10-12 Thread Mark Thomas
On 12/10/2020 07:10, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60030
> 
> --- Comment #5 from tawonpoker  ---

Another day, another idiot.

You'd think they'd notice that all links from Bugzilla were no-follow
but apparently not.

Account locked, spam deleted.

Mark

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



Re: [VOTE][RESULT] Release Apache Tomcat 8.5.59

2020-10-09 Thread Mark Thomas
The following votes were cast:

Binding:
+1: fhanik, remm, mgrigorov, markt, isapir

Non-Binding:
+1: rotty3000

The vote therefore passes.

Thank you to everyone who contributed to this this release.

Mark

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



Re: [VOTE][RESULT] Release Apache Tomcat 9.0.39

2020-10-09 Thread Mark Thomas
The following votes were cast:

Binding:
+1: fhanik, remm, mgrigorov, markt, isapir

Non-Binding:
+1: rotty3000

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



Re: [VOTE][RESULT] Release Apache Tomcat 10.0.0-M9

2020-10-09 Thread Mark Thomas
The following votes were cast:

Binding:
+1: remm, fhanik, mgrigorov, markt, isapir

Non-Binding:
+1: rotty3000

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



Re: [tomcat] branch master updated: Fix a typo in changelog

2020-10-09 Thread Mark Thomas
On 09/10/2020 08:22, mgrigo...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> mgrigorov pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 25b  Fix a typo in changelog
> 25b is described below
> 
> commit 25b55a4adb5f792dacc1a7418d7112f6f4e8
> Author: Martin Tzvetanov Grigorov 
> AuthorDate: Fri Oct 9 10:21:49 2020 +0300
> 
> Fix a typo in changelog

Tx.

Mark


> ---
>  webapps/docs/changelog.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index ec41058..d50d331 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -61,7 +61,7 @@
>
>  Refactor the HTTP/2 window update handling for padding in data 
> frames to
>  ensure that the connection window is correctly updated after a data
> -frame with zero lngth padding is received. (markt)
> +frame with zero length padding is received. (markt)
>
>  
>
> 
> 
> -
> 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: TCK status

2020-10-08 Thread Mark Thomas
On 08/10/2020 20:23, Christopher Schultz wrote:
> Mark,
> 
> On 10/3/20 14:39, Mark Thomas wrote:
>> Hi all,
>>
>> I mentioned TCK status during a couple of ApacheCon presentations.
>> Having checked the current status I thought it would be worth sending a
>> brief note to the list. More detail is on the wiki:
>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>>
>> The short version is:
>>
>> - EL: all tests pass
>> - JSP: all tests pass (once the TCK regression is fixed)
>> - WebSocket: all tests pass
>> - Servlet: one failure (expected)
>>
>> So, all good. No issues.
>>
>> Mark
>>
>> P.S. If you are wondering the servlet failure is because Tomcat ignores
>> any suggested context path in web.xml and will ALWAYS derive the context
>> path from the file name to avoid ambiguities and conflicts.
> 
> I can't for the life of me find a reference to how you "suggest" the
> context path in web.xml. Is this using the appCxtRoot env-entry? I
> thought that was vendor-specific...

... in web.xml

It was (and still is) a bad idea. The supporters of the feature ignored
questions like:

- What to do if two web apps use the same value?
- What if a webapp is already deployed at that path?

The only concession I was able to extract was the "may be overridden by
container specific configuration". In Tomcat's case this is the name of
the WAR/DIR so we can always ignore this. Once I reached the point where
I/Tomcat could ignore it, I did.

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

2020-10-07 Thread Mark Thomas
On 06/10/2020 18:34, Mark Thomas wrote:



> The proposed 8.5.59 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.59

Unit tests pass with NIO, NIO2, APR/Native with Tomcat Native 1.2.25 on
Windows, MacOS and Linux.

Mark

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



Re: [VOTE] Release Apache Tomcat 9.0.39

2020-10-07 Thread Mark Thomas
On 06/10/2020 15:49, Mark Thomas wrote:



> The proposed 9.0.39 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.39

Unit tests pass with NIO, NIO2, APR/Native with Tomcat Native 1.2.25 on
Windows, MacOS and Linux.

Mark

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



Re: [VOTE] Release Apache Tomcat 10.0.0-M9

2020-10-07 Thread Mark Thomas
On 06/10/2020 14:38, Mark Thomas wrote:



> The proposed 10.0.0-M9 release is:
> [ ] Broken - do not release
> [X] Alpha  - go ahead and release as 10.0.0-M9

Unit tests pass with NIO, NIO2, APR/Native with Tomcat Native 1.2.25 on
Windows, MacOS and Linux.

Mark

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



[VOTE] Release Apache Tomcat 8.5.59

2020-10-06 Thread Mark Thomas
The proposed Apache Tomcat 8.5.59 release is now available for voting.

The notable changes compared to the 8.5.58 release are:

- Refactor the handling of closed HTTP/2 streams to reduce the heap
  usage associated with used streams and to retain information for more
  streams in the priority tree.

- Deprecate the JDBCRealm.

- Ensure that none of the methods on a ServletContext instance always
  fail when running under a SecurityManager. Pull request provided by
  Kyle Stiemann.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.59/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1282/

The tag is:
https://github.com/apache/tomcat/tree/8.5.59
c042ec71219dbde3e1ce0381ce5be0801120d0fa

The proposed 8.5.59 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.59

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



[VOTE] Release Apache Tomcat 9.0.39

2020-10-06 Thread Mark Thomas
The proposed Apache Tomcat 9.0.39 release is now available for voting.

The notable changes compared to the 9.0.38 release are:

- Refactor the handling of closed HTTP/2 streams to reduce the heap
  usage associated with used streams and to retain information for more
  streams in the priority tree.

- Allow using the utility executor for annotation scanning. Patch
  provided by Jatin Kamnani.

- Add a bloom filter to speed up archive lookup and improve deployment
  speed of applications with a large number of JARs. Patch provided by
  Jatin Kamnani.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.39/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1281/
The tag is:
https://github.com/apache/tomcat/tree/9.0.39
6989c4e9360b4f9443862968c15a95d17f264321

The proposed 9.0.39 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.39

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



[VOTE] Release Apache Tomcat 10.0.0-M9

2020-10-06 Thread Mark Thomas
The proposed Apache Tomcat 10.0.0-M9 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to jakarta.*
Applications that run on Tomcat 9 will not run on Tomcat 10 without changes.

The notable changes compared to 10.0.0-M8 are:

- Refactor the handling of closed HTTP/2 streams to reduce the heap
  usage associated with used streams and to retain information for more
  streams in the priority tree.

- Allow using the utility executor for annotation scanning. Patch
  provided by Jatin Kamnani.

- Add a bloom filter to speed up archive lookup and improve deployment
  speed of applications with a large number of JARs. Patch provided by
  Jatin Kamnani.


Along with lots of other bug fixes and improvements.


For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0-M9/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcatrepo-1280/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0-M9
6f143d19d151620cd0bfe9ec2ffa429e36ad0e45

The proposed 10.0.0-M9 release is:
[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 10.0.0-M9

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



TCK status

2020-10-03 Thread Mark Thomas
Hi all,

I mentioned TCK status during a couple of ApacheCon presentations.
Having checked the current status I thought it would be worth sending a
brief note to the list. More detail is on the wiki:
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs

The short version is:

- EL: all tests pass
- JSP: all tests pass (once the TCK regression is fixed)
- WebSocket: all tests pass
- Servlet: one failure (expected)

So, all good. No issues.

Mark

P.S. If you are wondering the servlet failure is because Tomcat ignores
any suggested context path in web.xml and will ALWAYS derive the context
path from the file name to avoid ambiguities and conflicts.

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



svn/git for website

2020-10-01 Thread Mark Thomas
Hi all,

The topic came up at the BoF session at the end of the Tomcat track of
migrating the website from svn to git. There were strong opinions both
for migrating and for sticking with svn.

As a middle ground I'd like to propose we ask Infra to create a git
mirror of the svn repo.

For those who favour git:
The git mirror would be read-only but it would be possible to:
- clone the git mirror
- make changes in git
- use git-svn to commit those changes back to svn
- then the mirror automatically replicates them back to git

For those who favour svn there would be no change.

If there is agreement on this approach, I volunteer to contact infra to
get it set up.

Thoughts?

Mark

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



Re: buildbot failure in on tomcat-7-trunk

2020-09-30 Thread Mark Thomas
On 30/09/2020 18:12, build...@apache.org wrote:
> The Buildbot has detected a new failure on builder tomcat-7-trunk while 
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-7-trunk/builds/1787
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: asf946_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
> triggered this build
> Build Source Stamp: [branch 7.0.x] c4b1559d6e7f131be804373719fe41c26969df54
> Blamelist: Kyle Stiemann ,Mark Thomas 
> 
> 
> BUILD FAILED: failed compile_1

Looks like a TLS / download issue. I'll fix it on the build node.

Mark


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



Tagging 10.0.x, 9.0.x and 8.5.x.

2020-09-30 Thread Mark Thomas
Hi,

It looks like Martin has found a way to reproduce the buffer overflow
reported in bug 64710. Therefore I plan to hold of on the next round of
tags until I have been ablw to investigate (and hopefully) fix that issue.

Mark

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



Re: Removing the APR connector

2020-09-29 Thread Mark Thomas
On 29/09/2020 16:29, jonmcalexan...@wellsfargo.com.INVALID wrote:
> I know I'm not a contributor, but what is the reason for removing the APR 
> Connector?

It is inherently less stable. If we get the NIO code wrong, you might
see a NullPointerException. If we get the APR code wrong you might see a
JVM crash.

The primary benefit when the connector was first introduced was
performance. With current JVMs HTTP performance of pure Java connectors
is broadly similar to the APR/Native connector. For HTTPS, APR/Native
still provides a performance boost but we see a similar performance
boost when we use APR/Native to plug OpenSSL into NIO or NIO2 and that
requires less native code (and hence is less prune to stability issues).

In short, we can get the same benefits as the APR connector with
NIO+OpenSSL with less native code and hence less risk.

There are secondary benefits in terms of where we can clean up some of
the Tomcat internals if we only need to support two connectors (NIO and
NIO2) rather than 3.

Mark

> 
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
> 
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
> 
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
> 
> jonmcalexan...@wellsfargo.com
> 
> 
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
> 
> 
> -Original Message-
> From: Rémy Maucherat  
> Sent: Tuesday, September 29, 2020 6:58 AM
> To: Tomcat Developers List 
> Subject: Re: Removing the APR connector
> 
> On Tue, Sep 29, 2020 at 1:32 PM Mark Thomas  wrote:
> 
>> All,
>>
>> Removing the APR connector (HTTP and AJP) is currently on the TODO 
>> list for Tomcat 10.0.x (i.e. the current development branch).
>>
>> I am wondering whether we are still happy with this plan as we have 
>> had a few 10.0.x milestone releases and we haven't made any efforts to 
>> remove the APR connector.
>>
>> I'm happy to remove APR from 10.0.x but I am equally happy postponing 
>> this to a later release if necessary.
>>
>> We'd still need Tomcat Native support to enable the use of OpenSSL 
>> with NIO and NIO2. I am only thinking of removing the APR based HTTP 
>> and AJP connectors (with associated plumbing) and possibly some of the 
>> org.apache.tomcat.jni package.
>>
>> Thoughts?
>>
> 
> I would rather postpone at this point, with the idea of really removing it in 
> 10.1.
> Maybe we should remove it from the docs in 10.0 in preparation for the move ?
> 
> Rémy
> 
> 
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For 
>> additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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



Removing the APR connector

2020-09-29 Thread Mark Thomas
All,

Removing the APR connector (HTTP and AJP) is currently on the TODO list
for Tomcat 10.0.x (i.e. the current development branch).

I am wondering whether we are still happy with this plan as we have had
a few 10.0.x milestone releases and we haven't made any efforts to
remove the APR connector.

I'm happy to remove APR from 10.0.x but I am equally happy postponing
this to a later release if necessary.

We'd still need Tomcat Native support to enable the use of OpenSSL with
NIO and NIO2. I am only thinking of removing the APR based HTTP and AJP
connectors (with associated plumbing) and possibly some of the
org.apache.tomcat.jni package.

Thoughts?

Mark

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



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

2020-09-28 Thread Mark Thomas
On 28/09/2020 09:13, Martin Grigorov wrote:



> Good news: there are no regressions!

So far, so good.

> Neutral news: there are no performance improvements according to my tests.
> I use
> https://github.com/martin-g/http2-server-perf-tests/blob/128f24e27ef96ee31740db4130855bea2c021793/java/tomcat/src/main/java/info/mgsolutions/tomcat/Main.java
> to test HTTP2, h2c, HTTP and HTTPS
> HTTP: 28K reqs/s
> H2C: 14K reqs/s
> HTTP2: 11K req/s
> 
> I still use Vegeta as a test client + my patch to ignore CANCEL errors

You might want to try without that CANCEL error patch. The Tomcat code
should be more robust against that sort of error now as it retains state
for at least 5x max concurrent streams now.

I see slightly different figures when testing locally with Vegeta:

HTTP:   30.5k req/s
HTTPS:  18.0k req/s
h2c:20.7k req/s
h2: 17.2k req/s

There are a couple of unexpected things there:
- large drop from HTTP to HTTPS
- similar HTTP figures for your test and mine but very different h2/h2c
  figures

Given how unrepresentative local testing is I'm not entirely surprised.

I'm not planning on spending any time digging into these differences.

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

Mark

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



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

2020-09-25 Thread Mark Thomas
On 25/09/2020 14:34, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> markt pushed a change to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
> 
> 
> from 519f6f8  Fix a typo in changelog
>  new ee25710  Reduce memory footprint of closed http/2 streams
>  new f6e656e  Reduce memory footprint of closed http/2 streams
>  new 0f66705  Reduce memory footprint of closed http/2 streams
>  new fa6df26  Reduce memory footprint of closed http/2 streams
>  new 9ee7d6a  Reduce memory footprint of closed http/2 streams
>  new 30df6a0  Reduce memory footprint of closed http/2 streams
>  new 0a78ae9  Fully replace Stream with RecycledStream
>  new 954cbff  Refactor the pruning so more stream info is retained for 
> longer
>  new 18e0e3f  Update changelog

All,

This set of changes provided multiple improvements to the HTTP/2
implementation:

1. The memory used by closed streams is significantly reduced (hopefully
   without the NPEs triggered by my previous attempt).
2. We retain information on more streams in the priority tree. This
   enables greater latitude for clients that send frames for streams
   that have been closed (while not increasing memory).
3. We no longer aggressively prune the priority tree to just active
   streams (this was causing problems in some usage patterns).

My plan is to let this run on the CI for a few days and then - assuming
no issues - back-port it early next week.

Mark

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



Re: [tomcat] branch master updated: Fix a typo in changelog

2020-09-25 Thread Mark Thomas
On 25/09/2020 08:06, mgrigo...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> mgrigorov pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 519f6f8  Fix a typo in changelog
> 519f6f8 is described below
> 
> commit 519f6f89550208d020c18622ca7b870edf3a2602
> Author: Martin Tzvetanov Grigorov 
> AuthorDate: Fri Sep 25 10:02:15 2020 +0300
> 
> Fix a typo in changelog

Thanks for fixing these.

Mark


> ---
>  webapps/docs/changelog.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 85b7eee..319ae06 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -117,7 +117,7 @@
>
>
>  Improve the error handling for the HTTP/2 connection preface when the
> -Connector is configured with useAsycIO=true.
> +Connector is configured with 
> useAsyncIO=true.
>  (markt)
>
>  
> 
> 
> -
> 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: [tomcat] branch 9.0.x updated: Fix Javadoc build error and ensure 'ant clean javadoc' works

2020-09-18 Thread Mark Thomas
On 18/09/2020 22:37, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> markt pushed a commit to branch 9.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/9.0.x by this push:
>  new 33e874f  Fix Javadoc build error and ensure 'ant clean javadoc' works
> 33e874f is described below
> 
> commit 33e874fa31e6c411421ad1304dfa65f30bd58958
> Author: Mark Thomas 
> AuthorDate: Fri Sep 18 22:27:15 2020 +0100
> 
> Fix Javadoc build error and ensure 'ant clean javadoc' works



> diff --git a/build.xml b/build.xml
> index 7c65d25..8c0e40c 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -222,6 +222,7 @@
>
>
>  
> +
>  
>  
>  



In case you are wondering, this doesn't impact the license or notice
files because:
- it is only used by the Javadoc task to avoid a warning
- it is ALv2 licensed

Mark

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



Re: [tomcat] branch master updated: Use utility executor for scanning

2020-09-18 Thread Mark Thomas
On 18/09/2020 10:40, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 27bb36b  Use utility executor for scanning
> 27bb36b is described below
> 
> commit 27bb36bdaa56d62fdcc28d3b8e3d4c25f4a44a50
> Author: remm 
> AuthorDate: Fri Sep 18 11:40:17 2020 +0200
> 
> Use utility executor for scanning
> 
> PR354 submitted by Jatin Kamnani.
> The flag in on the context, as that's where it belongs. Defaults to
> false, can be configured through the context defaults or per context.



> +protected void processAnnotationsInParallel(Set fragments, 
> boolean handlesTypesOnly,
> +Map JavaClassCacheEntry> javaClassCache) {
> +Server s = getServer();
> +ExecutorService pool = null;
> +try {
> +pool = s.getUtilityExecutor();
> +List> futures = new ArrayList<>(fragments.size());
> +for (WebXml fragment : fragments) {
> +Runnable task = new AnnotationScanTask(fragment, 
> handlesTypesOnly, javaClassCache);
> +futures.add(pool.submit(task));
> +}
> +try {
> +for (Future future : futures) {
> +future.get();
> +}
> +} catch (Exception e) {
> +throw new 
> RuntimeException(sm.getString("contextConfig.processAnnotationsInParallelFailure"),
>  e);
> +}
> +} finally {
> +if (pool != null) {
> +pool.shutdownNow();
> +}
>  }
>  }

Why is the executor being shutdown here? What about other Tomcat
components that might be using it or want to use it in the future?

Mark

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



[ANN] Apache Tomcat 8.5.58 available

2020-09-16 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.58.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled
forward from the 9.0.x branch. The notable changes since 8.5.57 include:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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



[ANN] Apache Tomcat 9.0.38 available

2020-09-16 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.38.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.38 is a bugfix and feature release. The notable
changes compared to 9.0.37 include:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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



Re: [tomcat] branch master updated: Fix possible concurrency issue

2020-09-15 Thread Mark Thomas
On 15/09/2020 17:42, Mark Thomas wrote:
> On 15/09/2020 17:35, 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 6c21ee5  Fix possible concurrency issue
>> 6c21ee5 is described below
>>
>> commit 6c21ee5a57e6a6fa9c780d4a8f857d5c3a0b9a35
>> Author: Mark Thomas 
>> AuthorDate: Tue Sep 15 17:34:50 2020 +0100
>>
>> Fix possible concurrency issue
> 
> Hi,
> 
> This fix is a little on the speculative side.
> 
> I've been watching the intermittent CI failures for the last month or so
> and there is evidence (mainly in failed WebSocket tests) of something
> going wrong in HTTP request parsing.
> 
> Today, I saw a failure of once of the TestCoyoteAdapterRequestFuzzing
> tests with the following stack trace:
> 
> 15-Sep-2020 15:15:13.301 INFO [http-nio-127.0.0.1-auto-8-exec-1]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header
>  Note: further occurrences of HTTP request parsing errors will be logged
> at DEBUG level.
>   java.lang.IllegalArgumentException: Request header is too large
>   at
> org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:777)



> Given the request, that should not be possible. The only explanation I
> can come up with is that the recycling of the InputBuffer was not fully
> visible to the http-nio-127.0.0.1-auto-8-exec-1 thread.
> 
> This seems a little far-fetched to me but I can't come up with a better
> theory. With this theory in mind a looked at the Http11InputBuffer and
> if my understanding is correct:
> - there is a theoretical concurrency issue
> - the patch below fixes it
> 
> I do intend to back-port this as my understanding is that the issue is
> (theoretically) correct. I'll continue to keep an eye on the CI results
> to see if there is any noticeable impact. That said, as I can't
> reproduce this and impact is going to have be inferred.

Well, that didn't take long. The WebSocket error occurred again after
this fix so this isn't the (only?) root cause of that issue. The search
for the root cause of the intermittent WebSocket failures continues...

Mark

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



Re: [VOTE][RESULT] Release Apache Tomcat 8.5.58

2020-09-15 Thread Mark Thomas
The following votes were cast:

Binding:
+1: markt, mgrigorov, fhanik

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

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



Re: [tomcat] branch master updated: Fix possible concurrency issue

2020-09-15 Thread Mark Thomas
On 15/09/2020 17:35, 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 6c21ee5  Fix possible concurrency issue
> 6c21ee5 is described below
> 
> commit 6c21ee5a57e6a6fa9c780d4a8f857d5c3a0b9a35
> Author: Mark Thomas 
> AuthorDate: Tue Sep 15 17:34:50 2020 +0100
> 
> Fix possible concurrency issue

Hi,

This fix is a little on the speculative side.

I've been watching the intermittent CI failures for the last month or so
and there is evidence (mainly in failed WebSocket tests) of something
going wrong in HTTP request parsing.

Today, I saw a failure of once of the TestCoyoteAdapterRequestFuzzing
tests with the following stack trace:

15-Sep-2020 15:15:13.301 INFO [http-nio-127.0.0.1-auto-8-exec-1]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header
 Note: further occurrences of HTTP request parsing errors will be logged
at DEBUG level.
java.lang.IllegalArgumentException: Request header is too large
at
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:777)
at
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:938)
at
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:589)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:284)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
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)

Given the request, that should not be possible. The only explanation I
can come up with is that the recycling of the InputBuffer was not fully
visible to the http-nio-127.0.0.1-auto-8-exec-1 thread.

This seems a little far-fetched to me but I can't come up with a better
theory. With this theory in mind a looked at the Http11InputBuffer and
if my understanding is correct:
- there is a theoretical concurrency issue
- the patch below fixes it

I do intend to back-port this as my understanding is that the issue is
(theoretically) correct. I'll continue to keep an eye on the CI results
to see if there is any noticeable impact. That said, as I can't
reproduce this and impact is going to have be inferred.

Mark

> ---
>  java/org/apache/coyote/http11/Http11InputBuffer.java | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java 
> b/java/org/apache/coyote/http11/Http11InputBuffer.java
> index ab0d1c6..555e3ad 100644
> --- a/java/org/apache/coyote/http11/Http11InputBuffer.java
> +++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
> @@ -71,7 +71,7 @@ public class Http11InputBuffer implements InputBuffer, 
> ApplicationBufferHandler
>  /**
>   * State.
>   */
> -private boolean parsingHeader;
> +private volatile boolean parsingHeader;
>  
>  
>  /**
> @@ -130,7 +130,7 @@ public class Http11InputBuffer implements InputBuffer, 
> ApplicationBufferHandler
>   */
>  private byte prevChr = 0;
>  private byte chr = 0;
> -private boolean parsingRequestLine;
> +private volatile boolean parsingRequestLine;
>  private int parsingRequestLinePhase = 0;
>  private boolean parsingRequestLineEol = false;
>  private int parsingRequestLineStart = 0;
> @@ -266,18 +266,22 @@ public class Http11InputBuffer implements InputBuffer, 
> ApplicationBufferHandler
>  
>  byteBuffer.limit(0).position(0);
>  lastActiveFilter = -1;
> -parsingHeader = true;
>  swallowInput = true;
>  
>  chr = 0;
>  prevChr = 0;
>  headerParsePos = HeaderParsePosition.HEADER_START;
> -parsingRequestLine = true;
>  parsingRequestLinePhase = 0;
>  parsingRequestLineEol = false;
>  parsingRequestLineStart = 0;
>  parsingRequestLineQPos = -1;
>  headerData.recycle();
> +// Recycled last because they are volatile
> +

Re: Deprecated JDBCRealm

2020-09-15 Thread Mark Thomas
On 15/09/2020 14:12, Konstantin Kolinko wrote:
> пн, 14 сент. 2020 г. в 21:53, Mark Thomas :
>>
>> All,
>>
>> I'd like to proposed the following:
>> - Deprecated the JDBCRealm in 7.0.x, 8.5.x and 9.0.x
>> - Remove the JDBCRealm in 10.0.x
>>
>> The reasons for this are:
>> - The JDBCRealm is single threaded
>> - The DataSourceRealm is a better solution
>>
>> Thoughts?
> 
> +1
> 
> Looking at documentation [1], it may be improved:
> 
> a) Change ordering. It would be better to list DataSourceRealm first,
> followed by JDBCRealm.. (Currently JDBCRealm is the first one).

I'll fix that.

> b) Explicitly mention that JDBCRealm uses a single connection in its
> own documentation. (Currently documentation for DataSourceRealm
> mentions it, but the one for JDBCRealm itself does not).

And that.

> BTW, JNDIRealm also does not mention that it uses a single connection.

Only by default and we could/should change that. How about changing the
default to, say, 10?

Mark


> 
> [1] https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html
> 
> 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: [tomcat] branch master updated: Replace "".equals(a) with a.isEmpty()

2020-09-15 Thread Mark Thomas
On 15/09/2020 10:21, mgrigo...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> mgrigorov pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new f550254  Replace "".equals(a) with a.isEmpty()
>  new 6053839  Merge pull request #356 from 
> martin-g/improvement/use-string-isempty
> f550254 is described below
> 
> commit f550254bb15e1b0cc50225aee1c3fb1ed034f552
> Author: Martin Tzvetanov Grigorov 
> AuthorDate: Thu Sep 10 12:52:11 2020 +0300
> 
> Replace "".equals(a) with a.isEmpty()

How sure are you that none of these will introduce the possibility of a
NullPointerException?

Mark

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

Re: [VOTE][RESULT] Release Apache Tomcat 9.0.38

2020-09-15 Thread Mark Thomas
The following votes were cast:

Binding:
+1: remm, kfujino, mgrigorov, markt, fhanik, csutherl

Non-binding:
+1: Raymond Auge

The vote therefore passes.

Thank you to everyone who has contributed to this release.

Mark

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



[ANN] Apache Tomcat 10.0.0-M8 available

2020-09-15 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.0-M8.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is under development to aid
this process.

Apache Tomcat 10.0.0-M8 is a milestone release of the 10.0.x
branch and has been made to provide users with early access to the new
features in Apache Tomcat 10.0.x so that they may provide feedback. The
notable changes compared to 10.0.0-M7 include:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Deprecated JDBCRealm

2020-09-14 Thread Mark Thomas
All,

I'd like to proposed the following:
- Deprecated the JDBCRealm in 7.0.x, 8.5.x and 9.0.x
- Remove the JDBCRealm in 10.0.x

The reasons for this are:
- The JDBCRealm is single threaded
- The DataSourceRealm is a better solution

Thoughts?

Mark

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



Re: [VOTE][RESULT] Release Apache Tomcat 10.0.0-M8

2020-09-14 Thread Mark Thomas
The following votes were cast:

Binding:
+1: markt, remm, kfujino, mgrigorov, fhanik, csutherl

Non-binding:
+1: Raymond Auge

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



Re: Plans for Servlet 5.1

2020-09-14 Thread Mark Thomas
On 12/09/2020 22:56, Filip Hanik wrote:
> 
> 
> On 9/10/20, 01:17, "Mark Thomas"  wrote:
> 
> Hi all,
> 
> It looks like at least one of the specs Tomcat implements, Servlets, is
> going to have at least one release between Jakarta EE 9 / Servlet 5.0 /
> Tomcat 10.0 and Jakarta EE 10/ Servlet 6.0 / Tomcat 10.1
> 
> The current plan is for Servlet 5.1 to add same site cookie
> configuration and pick up any other low hanging fruit (mostly clean-up &
> clarification) from the issues list.
> 
> I'm currently trying to figure out what this means in terms of Tomcat
> releases. It may be that other specs do something similar. If enough
> specs do that, it may turn into a relatively quick Jakarta EE 10.
> 
> My current thinking is treat such releases the way we used to treat
> maintenance releases of the specs. That would mean updating Tomcat to
> the 5.1 release once available but not change in major or minor version.
> Another way of looking at it is that Tomcat 10.0.x will support the
> latest released version of Servlet 5.x and Tomcat 10.1.x will support
> the latest released version of Servlet 6.x.
> 
> Sounds good. Should we go to 10.5 rather than 10.1? While the numbers don't 
> mean much, we haven't had anything but .0 and .5 in a fairly long time.

The choice of version number of somewhat arbitrary. There were several
iterations of numbering scheme before we settled on this one.

For reference:
https://tomcat.markmail.org/thread/fzty4ymric7waw2s
https://tomcat.markmail.org/thread/isa6m53zv6rugebb

10.1.x vs 10.5.x wasn't explicitly discussed (that I can recall or can
find). Historically (5.5.x and 8.5.x) we have used the x.5.y releases to
indicate a major refactoring and discontinuing support for x.0.y
releases. That is slightly different from what is proposed for 10.0.x
and 10.1.x.

Mark


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



Re: [VOTE] Release Apache Tomcat 9.0.38

2020-09-11 Thread Mark Thomas
On 10/09/2020 10:03, Mark Thomas wrote:

> The proposed 9.0.38 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.38

Unit tests pass for NIO, NIO2 and APR/Native with Tomcat Native 1.2.25
on Windows, MacOS and Linux.

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

2020-09-11 Thread Mark Thomas
On 10/09/2020 23:10, Mark Thomas wrote:

> The proposed 8.5.58 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.58

Unit tests pass for NIO, NIO2 and APR/Native with Tomcat Native 1.2.25
on Windows, MacOS and Linux.

Mark

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



[VOTE] Release Apache Tomcat 8.5.58

2020-09-10 Thread Mark Thomas
The proposed Apache Tomcat 8.5.58 release is now available for voting.

The notable changes compared to the 8.5.57 release are:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.58/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1278/

The tag is:
https://github.com/apache/tomcat/tree/8.5.58
2fe65bc24e48ee5ea079937e6a73576339f871ce

The proposed 8.5.58 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.58

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



Re: Next release

2020-09-10 Thread Mark Thomas
On 08/09/2020 18:49, Mark Thomas wrote:
> On 03/09/2020 16:18, Filip Hanik wrote:
>> On Thu, Sep 3, 2020 at 07:44 Mark Thomas  
>> Commons Daemon may not be ready in time (there was a delay due an issue
>>
>> with the signing system). I'm currently planning to start tagging early
>>
>> next week. If Daemon is ready by then great. If not, we can pick up the
>>
>> update next month.
>>
>>
>> +1
> 
> FYI: It doesn't look like Commons Daemon will release in time (one vote
> short).
> 
> I'm also seeing a handful of test failures on Windows. They look like
> timing issues. I suspect a VM performance issue after a Host OS upgrade.
> I want to look into that in a little more detail before I tag.

The 8.5.x tag is currently on hold while I investigate what looks to be
a repeatable failure of
org.apache.tomcat.websocket.pojo.TestEncodingDecoding with NIO2 on a
Windows VM.

This is actually a good thing. This test has been failing
intermittently. A repeatable failure means a good chance of of finding
and fixing the root cause.

Mark

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



[VOTE] Release Apache Tomcat 9.0.38

2020-09-10 Thread Mark Thomas
The proposed Apache Tomcat 9.0.38 release is now available for voting.

The notable changes compared to the 9.0.37 release are:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.38/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1277/
The tag is:
https://github.com/apache/tomcat/tree/9.0.38
48b6a87171e502cc0becbb4c96e2266de4e805e7

The proposed 9.0.38 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.38

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



Plans for Servlet 5.1

2020-09-10 Thread Mark Thomas
Hi all,

It looks like at least one of the specs Tomcat implements, Servlets, is
going to have at least one release between Jakarta EE 9 / Servlet 5.0 /
Tomcat 10.0 and Jakarta EE 10/ Servlet 6.0 / Tomcat 10.1

The current plan is for Servlet 5.1 to add same site cookie
configuration and pick up any other low hanging fruit (mostly clean-up &
clarification) from the issues list.

I'm currently trying to figure out what this means in terms of Tomcat
releases. It may be that other specs do something similar. If enough
specs do that, it may turn into a relatively quick Jakarta EE 10.

My current thinking is treat such releases the way we used to treat
maintenance releases of the specs. That would mean updating Tomcat to
the 5.1 release once available but not change in major or minor version.
Another way of looking at it is that Tomcat 10.0.x will support the
latest released version of Servlet 5.x and Tomcat 10.1.x will support
the latest released version of Servlet 6.x.

Thoughts?

Mark

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



Re: [VOTE] Release Apache Tomcat 10.0.0-M8

2020-09-09 Thread Mark Thomas
On 09/09/2020 15:57, Mark Thomas wrote:


> 
> The proposed 10.0.0-M8 release is:
> [ ] Broken - do not release
> [X] Alpha  - go ahead and release as 10.0.0-M8

Unit tests pass for NIO, NIO2, APR/Native (with Tomcat Native 1.2.25) on
Windows, Linux and OSX.

Mark

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



[VOTE] Release Apache Tomcat 10.0.0-M8

2020-09-09 Thread Mark Thomas
The proposed Apache Tomcat 10.0.0-M8 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to jakarta.*
Applications that run on Tomcat 9 will not run on Tomcat 10 without changes.

The notable changes compared to 10.0.0-M7 are:

- For requests containing the Expect: 100-continue header, optional
  support has been added to delay sending an intermediate 100 status
  response until the servlet reads the request body, allowing the
  servlet the opportunity to respond without asking for the request
  body. Based on a pull request by malaysf.

- Add support for a read idle timeout and a write idle timeout to the
  WebSocket session via custom properties in the user properties
  instance associated with the session. Based on a pull request by
  sakshamverma.

- Update the packaged version of the Tomcat Native Library to 1.2.25

Along with lots of other bug fixes and improvements.


For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.0-M8/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcatrepo-1276/
The tag is:
https://github.com/apache/tomcat/tree/10.0.0-M8
b3f5e0d88336d81a61a767fc10ab06930c9587ee

The proposed 10.0.0-M8 release is:
[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 10.0.0-M8

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



Re: Next release

2020-09-08 Thread Mark Thomas
On 03/09/2020 16:18, Filip Hanik wrote:
> On Thu, Sep 3, 2020 at 07:44 Mark Thomas  Commons Daemon may not be ready in time (there was a delay due an issue
> 
> with the signing system). I'm currently planning to start tagging early
> 
> next week. If Daemon is ready by then great. If not, we can pick up the
> 
> update next month.
> 
> 
> +1

FYI: It doesn't look like Commons Daemon will release in time (one vote
short).

I'm also seeing a handful of test failures on Windows. They look like
timing issues. I suspect a VM performance issue after a Host OS upgrade.
I want to look into that in a little more detail before I tag.

Mark

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



Re: [tomcat] branch master updated: Add the missing string

2020-09-08 Thread Mark Thomas
On 08/09/2020 12:45, Rémy Maucherat wrote:
> On Tue, Sep 8, 2020 at 1:11 PM Mark Thomas  wrote:
> 
>> On 08/09/2020 11:55, r...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> remm pushed a commit to branch master
>>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>  new 6515798  Add the missing string
>>> 6515798 is described below
>>>
>>> commit 6515798cd693636350647f61eadcf80755bd8b11
>>> Author: remm 
>>> AuthorDate: Tue Sep 8 12:53:23 2020 +0200
>>>
>>> Add the missing string
>>
>> The string isn't missing. It is just not in alphabetic order.
>> This commit also reverts the fixes to the message wording that were
>> included in the PR.
>>
>> The new key name is an improvement - it is more consistent with existing
>> keys.
>>
> 
> Ok, sorry for the problem, I misread the commit message and missed the add,
> then I didn't find the string manually.

No worries. I should have caught the naming and ordering issues when I
reviewed the PR.

Mark

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



Re: [tomcat] branch master updated: Add the missing string

2020-09-08 Thread Mark Thomas
On 08/09/2020 11:55, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 6515798  Add the missing string
> 6515798 is described below
> 
> commit 6515798cd693636350647f61eadcf80755bd8b11
> Author: remm 
> AuthorDate: Tue Sep 8 12:53:23 2020 +0200
> 
> Add the missing string

The string isn't missing. It is just not in alphabetic order.
This commit also reverts the fixes to the message wording that were
included in the PR.

The new key name is an improvement - it is more consistent with existing
keys.

Mark



> ---
>  java/org/apache/tomcat/util/net/LocalStrings.properties | 1 +
>  java/org/apache/tomcat/util/net/SSLUtilBase.java| 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/java/org/apache/tomcat/util/net/LocalStrings.properties 
> b/java/org/apache/tomcat/util/net/LocalStrings.properties
> index e2a16b9..efd962b 100644
> --- a/java/org/apache/tomcat/util/net/LocalStrings.properties
> +++ b/java/org/apache/tomcat/util/net/LocalStrings.properties
> @@ -164,6 +164,7 @@ sslImplementation.cnfe=Unable to create SSLImplementation 
> for class [{0}]
>  
>  sslUtilBase.active=The [{0}] that are active are : [{1}]
>  sslUtilBase.alias_no_key_entry=Alias name [{0}] does not identify a key entry
> +sslUtilBase.aliasIgnored=Alias name [{0}] will be ignored when using FIPS 
> mode
>  sslUtilBase.invalidTrustManagerClassName=The trustManagerClassName provided 
> [{0}] does not implement javax.net.ssl.TrustManager
>  sslUtilBase.keystore_load_failed=Failed to load keystore type [{0}] with 
> path [{1}] due to [{2}]
>  sslUtilBase.noCertFile=SSLHostConfig attribute certificateFile must be 
> defined when using an SSL connector
> diff --git a/java/org/apache/tomcat/util/net/SSLUtilBase.java 
> b/java/org/apache/tomcat/util/net/SSLUtilBase.java
> index 143b2d2..09e3aa7 100644
> --- a/java/org/apache/tomcat/util/net/SSLUtilBase.java
> +++ b/java/org/apache/tomcat/util/net/SSLUtilBase.java
> @@ -300,7 +300,7 @@ public abstract class SSLUtilBase implements SSLUtil {
>  if (kmf.getProvider().getInfo().indexOf("FIPS") != -1) {
>  // FIPS doesn't like ANY wrapping nor key manipulation.
>  if (keyAlias != null) {
> -log.warn(sm.getString("sslUtilBase.alias_ignored", 
> keyAlias));
> +log.warn(sm.getString("sslUtilBase.aliasIgnored", keyAlias));
>  }
>  kmf.init(ksUsed, keyPassArray);
>  return kmf.getKeyManagers();
> 
> 
> -
> 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: buildbot exception in on tomcat-85-trunk

2020-09-07 Thread Mark Thomas
On 07/09/2020 14:08, build...@apache.org wrote:
> The Buildbot has detected a build exception on builder tomcat-85-trunk while 
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-85-trunk/builds/2442
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: asf946_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit' 
> triggered this build
> Build Source Stamp: [branch 8.5.x] 4363c5317e976d3f315e8aaf74e0cb142c5172aa
> Blamelist: Mark Thomas 
> 
> BUILD FAILED: exception compile upload_2

TLS issues trying to download the new Native. I'll work around it on the
build slave.

Mark

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



[ANN] Apache Tomcat Native 1.2.25 released

2020-09-07 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.2.25 stable.

The key features of this release are:
- Improvements to the build system
- Add an option to allow the OCSP check to be bypassed

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library provides portable API for features
not found in contemporary JDK's. It uses Apache Portable Runtime as
operating system abstraction layer and OpenSSL for SSL networking and
allows optimal performance in production environments.

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



Re: Next release

2020-09-03 Thread Mark Thomas


On 27/08/2020 14:15, Rémy Maucherat wrote:
> On Thu, Aug 27, 2020 at 4:26 AM Filip Hanik  <mailto:fi...@hanik.com>> wrote:
> On Wed, Aug 26, 2020 at 12:12 Rémy Maucherat  <mailto:r...@apache.org>> wrote:
> On Wed, Aug 26, 2020 at 6:25 PM Filip Hanik  <mailto:fi...@hanik.com>> wrote:
> On Wed, Aug 26, 2020 at 09:15 Mark Thomas  <mailto:ma...@apache.org>> wrote:
> On 26/08/2020 17:12, Filip Hanik wrote:
> 
> > Our cadence seems fairly predictable. 
> >
> > Any thoughts on the timeline of the  on the next batch
> of releases?
> 
> I skipped the August releases as I was away. I'm
> planning on the
> September releases as usual. I'd like to get Tomcat
> Native and Commons
> Daemon updates into those releases if possible.
> 
> 
> Thanks, that sounds like a good plan. I’m reviewing the PRs
> too.

Commons Daemon may not be ready in time (there was a delay due an issue
with the signing system). I'm currently planning to start tagging early
next week. If Daemon is ready by then great. If not, we can pick up the
update next month.

Mark

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



[VOTE][RESULT] Release Apache Tomcat Native 1.2.25

2020-09-03 Thread Mark Thomas
The following votes were cast:

Binding:
+1: markt, mgrigorov, fschumacher

+0: schultz

The vote therefore passes.

I think it is worth noting that there were crashes / unit test failures
reported with LibreSSL. This isn't unexpected. There is more work to do
for LibreSSL support.

Thanks to everyone who tested this release.

Mark

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



Re: security.txt

2020-09-01 Thread Mark Thomas
On 01/09/2020 18:01, Christopher Schultz wrote:
> All,
> 
> I'd like to propose that we publish a security.txt[1] file on our web
> site under /.well-known/security.txt and /security.txt
> 
> This file contains information we all already know, but it's in
> obviously "proprietary" locations on our web site and might not easily
> be found by someone who maybe doesn't speak English, etc.
> 
> Here's my proposed content:
> 
> Contact: secur...@tomcat.apache.org
> Contact:
> https://tomcat.apache.org/security.html#Reporting_New_Security_Problems_
> with_Apache_Tomcat
> Acknowledgments: https://tomcat.apache.org/security.html
> Preferred-Languages: en
> Canonical: https://tomcat.apache.org/.well-known/security.txt
> Hiring: https://tomcat.apache.org/getinvolved.html
> 
> If there are no objections, I'll add it to the site repo, soon.

+1

> What's the best way to make sure that the same file ends up in
> /.well-known/security.txt and /security.txt? Can git link them
> together or something like that?

The site is in svn.

A rewrite rule?

Mark

> 
> -chris
> 
> [1] https://securitytxt.org/
>
> -
> 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 Native 1.2.25

2020-09-01 Thread Mark Thomas
All,

We only have 2 PMC +1 votes for this release.

Mark


On 21/08/2020 19:22, Mark Thomas wrote:
> Version 1.2.25 includes the following changes compared to 1.2.24
> 
> - Improvements to LibreSSL support
> 
> - Improvements to HP_UX support
> 
> Various other fixes and improvements. See the changelog for details.
> 
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
> 
> The Apache Tomcat Native 1.2.25 release is
>  [ ] Stable, go ahead and release
>  [ ] Broken because of ...
> 
> Thanks,
> 
> Mark
> 
> 
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.25
> [2]
> https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=a94590ec2a5e40b168a9494144125a52f41ed0b2
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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



Re: Potentially changing utilityThreadsAsDaemon default in 10

2020-08-31 Thread Mark Thomas
On 31/08/2020 17:17, David Blevins wrote:
> Hey All,
> 
> Curious if there would be any willingness to change the default of this to 
> true for Tomcat 10 prior to final release.
> 
>  - 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/core/StandardServer.java#L195

Unlikely based on the information provided. Making the utility threads
daemon threads looks like a hack to work around a problem elsewhere. I'm
more interested in tackling the root cause.

> The current default prevents a JVM shutdown and effectively means setting 
> this to either true or false has no effect:
> 
>  - 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/startup/Catalina.java#L91

In what circumstances? I haven't observed any issues with non-clean
shutdowns when running from the command line or as a service.

Mark

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



Re: [tomcat] 02/02: Update Commons DBCP to latest

2020-08-26 Thread Mark Thomas
On 26/08/2020 18:43, Christopher Schultz wrote:



> Is there a particular reason we don't just shade the commons-dbcp and
> commons-pool code at build-time rather than manually merging-in
> patches to our private copy?

The short answer is greater flexibility.

The longer answer is that there are various reasons and that the
relative importance of those reasons has varied over time and between
components. They include:
- the ability to remove code we don't need / want
  - we only use a small subset of BCEL
  - we generally remove deprecated code immediately
  - we ignore parts of FileUpload and 8.5.x ignores part of DBCP
- the ability to fix issues / avoid regressions
  - there was an 'improvement' in the DBCP abandoned connection tracing
that caused problems so we backed that change out in our copy
  - we have applied various fixes / clean-up globally to the Tomcat code
base over time and then contributed them to Commons (there are a few
of those we still need to contribute)
- the ability to handle the Java EE / Jakarta EE transition (both DBCP
  and FileUpload have Java EE / Jakarta EE imports)
- the ability to update to any tag or commit
- the ability to skip commits that make use of newer Java features (e.g.
  lamdas) that are not available in the Java version we have to compile
  with

My sense currently is that setting up shading and then handling the
various edge cases is more work than generating a patch every ~6 months,
applying it and dealing with a small number of conflicts.

Mark

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



Re: [tomcat] 02/02: Update Commons DBCP to latest

2020-08-26 Thread Mark Thomas
On 26/08/2020 17:56, Christopher Schultz wrote:
> Mark,
> 
> On 8/26/20 11:19, 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
> 
>> commit f1c4210470a268ec6830a95ab219f418a7e775fb Author: Mark Thomas
>>  AuthorDate: Wed Aug 26 16:15:50 2020 +0100
> 
>> Update Commons DBCP to latest
> 
> It looks like, among other things, this includes the fix for
> https://issues.apache.org/jira/browse/DBCP-559
> 
> If so: hooray!
> 
> Can you confirm?

Confirmed. There were sufficient meaningful changes to DBCP since the
last release so I took the latest code.

Mark

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



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

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

Generally I concur with what Chris said about the risks of HSTS. Given
the risks, I think the current default is appropriate.

I'd be happy with a log message at WARN level if Tomcat is started with
the HSTS enabled with the default value. I think we probably need add a
warning to the docs so the log message can refer to the user to the
documentation for information on appropriate values.

Mark

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



Re: Next release

2020-08-26 Thread Mark Thomas
On 26/08/2020 17:12, Filip Hanik wrote:
> Our cadence seems fairly predictable. 
> 
> Any thoughts on the timeline of the  on the next batch of releases?

I skipped the August releases as I was away. I'm planning on the
September releases as usual. I'd like to get Tomcat Native and Commons
Daemon updates into those releases if possible.

Mark

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



[jira] [Closed] (MTOMCAT-314) Maven Package creating a issue on spark submit

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas closed MTOMCAT-314.
---
Resolution: Invalid

Not an issue with the Tomcat Maven plug-in

> Maven Package creating a issue on spark submit
> --
>
> Key: MTOMCAT-314
> URL: https://issues.apache.org/jira/browse/MTOMCAT-314
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Question
>Reporter: GOPAL
>Priority: Major
> Attachments: exceptionscala.PNG
>
>
> I am using IntelliJ and build a spark and scala application, From IntelliJ am 
> able to build and execute the application without issue,
> I did Maven compile and then package to get single Shaded Jar File. 
> Using  spark-submit am executing this shaded-jar file ,. But am getting 
> "Unable to resolve class Dependency Exception,
> Can someone please look into this , This is am facing from last one month



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Closed] (MTOMCAT-318) configuration of plug-ins to map simple types, such as Boolean or Integer

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas closed MTOMCAT-318.
---
Resolution: Incomplete

Insufficient information provided.

> configuration of plug-ins to map simple types, such as Boolean or Integer
> -
>
> Key: MTOMCAT-318
> URL: https://issues.apache.org/jira/browse/MTOMCAT-318
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat7
>Affects Versions: 2.2
> Environment: localhost
>Reporter: Roger Mbiama
>Assignee: Olivier Lamy
>Priority: Major
>  Labels: newbie
> Fix For: 2.3
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Plugin build and reporting:
> This construction and repability plugin will run during construction in 
> localhost, it should be configured in the  element.
> The report generation plugin will run during tomcat 7 generation and must be 
> configured in the  element.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (MTOMCAT-319) CVEs in the library dependencies

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved MTOMCAT-319.
-
Resolution: Fixed

The dependency question is an issue for Tomcat, not the plugin.

> CVEs in the library dependencies
> 
>
> Key: MTOMCAT-319
> URL: https://issues.apache.org/jira/browse/MTOMCAT-319
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>Reporter: XuCongying
>Priority: Major
>
> Hi, I have noticed that some library CVEs may be related to your projects. In 
> order to avoid threats, I recommend updating to a safe version. Here is the 
> details:
>  
> Vulnerable Library Version: com.h2database : h2 : 1.3.152
>   CVE ID: 
> [CVE-2018-10054](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10054),
>  
> [CVE-2018-14335](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14335)
>   Import Path: modules/jdbc-pool/pom.xml
>   Suggested Safe Versions: 1.4.198, 1.4.199, 1.4.200



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Deleted] (MTOMCAT-313) shahintel

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas deleted MTOMCAT-313:



> shahintel
> -
>
> Key: MTOMCAT-313
> URL: https://issues.apache.org/jira/browse/MTOMCAT-313
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Access
> Environment: shain
>Reporter: shahin mondal
>Assignee: Olivier Lamy
>Priority: Major
>  Labels: pull-request-available
>   Original Estimate: 458h 37m
>  Remaining Estimate: 458h 37m
>
> # 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Closed] (MTOMCAT-320) Error 400

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas closed MTOMCAT-320.
---

> Error 400
> -
>
> Key: MTOMCAT-320
> URL: https://issues.apache.org/jira/browse/MTOMCAT-320
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Request
>  Components: tomcat7
>Affects Versions: 2.2
>Reporter: Rahul Govind Londhe
>Assignee: Olivier Lamy
>Priority: Major
>
> Using enctype="multipart/form-data" trying to upload file but it throwing Bad 
> Request(400) error.
>  
> Need Help
> 8208064913



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (MTOMCAT-320) Error 400

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved MTOMCAT-320.
-
Resolution: Not A Problem

> Error 400
> -
>
> Key: MTOMCAT-320
> URL: https://issues.apache.org/jira/browse/MTOMCAT-320
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Request
>  Components: tomcat7
>Affects Versions: 2.2
>Reporter: Rahul Govind Londhe
>Assignee: Olivier Lamy
>Priority: Major
>
> Using enctype="multipart/form-data" trying to upload file but it throwing Bad 
> Request(400) error.
>  
> Need Help
> 8208064913



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Closed] (MTOMCAT-252) User is not logged in as current user

2020-08-24 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas closed MTOMCAT-252.
---
Resolution: Invalid

Insufficient information provided.

> User is not logged in as current user
> -
>
> Key: MTOMCAT-252
> URL: https://issues.apache.org/jira/browse/MTOMCAT-252
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat6
>Affects Versions: 2.0-beta-1
>Reporter: ram
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: backlog, 2.0-beta-1
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



Re: [VOTE] Release Apache Tomcat Native 1.2.25

2020-08-24 Thread Mark Thomas



On 24/08/2020 12:58, Michael Osipov wrote:
> Am 2020-08-21 um 20:22 schrieb Mark Thomas:
>> Version 1.2.25 includes the following changes compared to 1.2.24
>>
>> - Improvements to LibreSSL support
>>
>> - Improvements to HP_UX support
>>
>> Various other fixes and improvements. See the changelog for details.
>>
>> The proposed release artefacts can be found at [1],
>> and the build was done using tag [2].
> 
> A bit late, but here are my findings. I am not sure whether they are in
> Tomcat or libtcnative.
> 
> I see reliable failures in tests with LibreSSL 2.9.0 and 3.2.1 (master)
> with libtcnative master and Tomcat master on FreeBSD 12-STABLE and
> OpenJDK 1.8.0_265.

Is that any different with 1.2.24?

Mark

> 
> Please see:
> http://home.apache.org/~michaelo/tomcat-master-tcnative-master-libressl-2.9.0/
> as well as
> http://home.apache.org/~michaelo/tomcat-master-tcnative-master-libressl-master/.
> 
> 
> Let me know if you need further information for analysis/fixing.
> 
> Michael
> 
> -
> 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



[CONF] Apache Tomcat > WebSocket 2.0 TCK

2020-08-21 Thread Mark Thomas (Confluence)
Title: Message Title



 
 
 
There's 1 new edit on this page 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
WebSocket 2.0 TCK 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Mark Thomas edited this page 
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Here's the version comment 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Mark Thomas edited at 08:33 PM 
 
 
  
 
 

 
 
 
 
 
 
 
 
 Update testing results  
 
 
  
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Here's what changed: 
 
 
 
 
 
 
 
 
 
 
 ... A default 10.0.x build (as of 2020-0708-1521) running with the local staged TCK build (as of 2020-0708-1521) triggers 1 0 test failure:   1 faulty test  ...  failures:  5 Tests 'fixed' by appropriate system property configuration (see above). ...  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Go to page history 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
View page 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 7.5.0  
 
 
  
 
 
 
 
 
 
 
 
 




Re: [VOTE] Release Apache Tomcat Native 1.2.25

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

I've been running unit tests locally without any issues.

Mark


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


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



[VOTE] Release Apache Tomcat Native 1.2.25

2020-08-21 Thread Mark Thomas
Version 1.2.25 includes the following changes compared to 1.2.24

- Improvements to LibreSSL support

- Improvements to HP_UX support

Various other fixes and improvements. See the changelog for details.

The proposed release artefacts can be found at [1],
and the build was done using tag [2].

The Apache Tomcat Native 1.2.25 release is
 [ ] Stable, go ahead and release
 [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.25
[2]
https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=a94590ec2a5e40b168a9494144125a52f41ed0b2

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



Time for Tomcat Native 1.2.25

2020-08-20 Thread Mark Thomas
Hi,

It has been a while since 1.2.24 and there are a few fixes in the
changelog (mainly for LibreSSL and better support for a range of
platforms). With this in mind, I'm currently intending to tag 1.2.25 in
~24 hours

Mark

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



Re: [tomcat] branch master updated: More debugging

2020-08-17 Thread Mark Thomas
On 17/08/2020 13:14, 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 bc1adec  More debugging

Just an update on where I have got to with this.

Specifying jsp-file in web.xml creates a Wrapper instance. Init params
are copied from JSP servlet - including load-on-startup.

The JSP is compiled and the class and Java files are placed in the same
places the JSP servlet would place them.

The request arrives and is mapped to the JSP servlet. Locally, the JSP
servlet uses the pre-compiled servlet.

On s390x the JSP servlet appears to attempt recompilation. Because this
happens with the JSP servlet's standard settings, the compilation fails.

I am currently trying to figure out why local testing re-uses the
pre-compiled servlet but s390x recompiles it. I'm currently looking at
timestamps of files.

Mark

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



Re: After upgrading then version of tomcat 9.0.37 ISAPI redirect does not work successfully

2020-08-16 Thread Mark Thomas
On 16/08/2020 12:56, Selma Tomiko Araki wrote:
> 
> Hi, can I ask the following questions to this mailing list?

This question belongs on the users mailing list.

Mark


> 
> After upgrading the version of tomcat9, IIS linkage has stopped working.
> As stated in the subject, when I upgraded tomcat 9.0.37, ISAPI redirect does 
> not work successfully.
> 
> environment
> ・Windows Server 2016
> ・IIS10
> ・Isapi redirect.dll 1.2.46
> ・Tomcat 9.0.31 → 9.0.37
> 
> The error 503 message that has occurred is as follows.
> --
> Service Temporarily Unavailable!
> The server is temporarily unable to service your request due to maintenance 
> downtime or capacity problems.
> Please try again later.
> Tomcat/ISAPI/isapi_redirector/1.2.46
> --
> 
> It has been confirmed that the management screen opens at localhost:8080 
> after the version upgrade. 
> It is thought that tomcat is operating alone, and I think that it is not 
> possible to link with IIS via ISAPI.
> 
> Please teach me what kind of settings do I need to use tomcat 9.0.37 to work 
> with IIS?
> 
> I would appreciate yours reply.
> Thank's.
> 
> Selma
> 
> 
> -
> 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: Travis failures on s390x

2020-08-15 Thread Mark Thomas
On 15/08/2020 18:11, Mark Thomas wrote:
> On 14/08/2020 15:06, Mark Thomas wrote:
>> Hi,
>>
>> I am seeing consistent failures for the TestParserNoStrictWhitespace on
>> Travis for s390x.
>>
>> Rather than proxying my testing through Travis, I am trying to get
>> access to a free instance via IBM's cloud. I need to jump through some
>> account upgrade hoops to do that and IBM's systems seem to have
>> something against me at the moment.
>>
>> I'll keep the list posted re progress but expect to see at least 3
>> failures when the unit tests run on s390x for now.
> 
> I have access to a test instance running the same version of Ubuntu and
> 11.0.8 (rather than 11.0.7). Installing 11.0.7 is proving tricky at the
> moment.
> 
> I am currently unable to repeat the failures seen on Travis and I don't
> think it is related to the Java version.
> 
> I do, however, see other test failures which I'll take a look at.

Nothing to see unfortunately. The usual failures when multicast is
disabled and a non-standard openssl build is used.

Doh! Just realised that the JDKs used by Travis are downloadable from
Github.

/me goes to run tests with 11.0.7

As suspected, running the tests with 11.0.7 rather than 11.0.8 doesn't
recreate the failures we are seeing on Travis.

I'll see what I can do to add some debug info to the logs for the Travis
failures.

Mark

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



Re: Travis failures on s390x

2020-08-15 Thread Mark Thomas
On 14/08/2020 15:06, Mark Thomas wrote:
> Hi,
> 
> I am seeing consistent failures for the TestParserNoStrictWhitespace on
> Travis for s390x.
> 
> Rather than proxying my testing through Travis, I am trying to get
> access to a free instance via IBM's cloud. I need to jump through some
> account upgrade hoops to do that and IBM's systems seem to have
> something against me at the moment.
> 
> I'll keep the list posted re progress but expect to see at least 3
> failures when the unit tests run on s390x for now.

I have access to a test instance running the same version of Ubuntu and
11.0.8 (rather than 11.0.7). Installing 11.0.7 is proving tricky at the
moment.

I am currently unable to repeat the failures seen on Travis and I don't
think it is related to the Java version.

I do, however, see other test failures which I'll take a look at.

Mark

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



Re: Discouraging Rogue Users In Tomcat

2020-08-14 Thread Mark Thomas
This looks like a Tomcat specific fail2ban clone to me. My
recommendation for users that want this sort of functionality is have
the app write the offending IP address (and optional additional info) to
a log file and configure fail2ban to monitor that log file.

Mark



On 05/08/2020 18:51, Dave Fisher wrote:
> Hi -
> 
> In my experience the scans you are reporting may be from a white hat security 
> scan of your website that is contracted by your security team. These tend to 
> try every exploit that is known for any web server to make sure that your web 
> apps is secure.
> 
> I’m not sure how the Tomcat team will respond to your ideas. But to me this 
> seems like a use case for a filter and/or a reason to put httpd in front of 
> Tomcat.
> 
> All the best,
> Dave
> 
>> On Aug 5, 2020, at 10:17 AM, Alan Basche  wrote:
>>
>>>
>>> Alan,
>>>
>>>
>>> What kind of protections does this module provide? How does it
>>> integrate into Tomcat (e.g. custom
>>> Filter/Valve/ServletContextListener, patches to arbitrary places in
>>> Tomcat internals, etc.)?
>>>
>>
>> The point of this code is to prevent malicious users from probing
>> Tomcat hosted apps for weaknesses that can be exploited.  After
>> deploying Tomcat a year ago, I found that some automated programs were
>> requesting hundreds of files that were not found on my system.
>> Besides the security risk of revealing your system's configuration, a
>> single attack could increase my daily access log file size by 3 or 4
>> times with all of the file requests.  I was not able to find any way
>> to discourage this activity with any Tomcat feature.  So I started
>> developing my own solutions to shutdown these visitors.  Initially my
>> efforts focused on manipulating the website apps' responses in various
>> ways but ultimately, the most determined black-hats were not deterred.
>> A few months ago I found a solution that worked quite well.  I
>> concluded that Tomcat should simply refuse to connect to bad IP
>> addresses.  Of course, Tomcat has no way of knowing when the server is
>> being probed for vulnerabilities.  However, the website apps are fully
>> aware of an attack (e.g. when a user asks for 'wp-login.php', but the
>> apps don't even use php technology).  So the apps can determine if an
>> attack is in-progress, and inform Tomcat of the attack so it can be
>> dealt with.
>>
>> I added a new class IpHitTable.java to Tomcat that manages a list of
>> bad IP addresses, checks for an IP address in the table, has a public
>> method that allows apps to add a problem IP address, and can return an
>> HTML-formatted String for use in a website page to view the bad IP
>> address table.  I modified Tomcat class NioEndpoint.java to call a
>> method in IpHitTable to see if an IP address that wants to connect
>> should be allowed.  This bad IP address table in IpHitTable is built
>> as the system runs and is not stored/loaded to/from a disk or config
>> file.  The table is empty each time Tomcat is started.
>>
>> When a web app gets a bad request, it tells Tomcat the IP address and
>> how many bad hits are permissible before future connections should be
>> refused, and then sends a response with a status code that causes
>> Tomcat to disconnect the session
>> (org.apache.coyote.http11.statusDropsConnection()) if Tomcat informed
>> the app that the bad hits limit has been reached.  My own web apps
>> allow 3 bad requests before breaking a connection (to allow for
>> legitimate file-not-found scenarios... the hostmaster removed/renamed
>> HTML files for example).  I also have a default web app (defined in
>> server.xml, the 'Engine' definition parameter) that receives requests
>> that are not bound for a particular app.  This covers black-hats who
>> come to my server by IP address and didn't even know it was a web
>> server.  The default web app does not allow 3 bad requests, but rather
>> immediately disconnects and tells Tomcat to immediately refuse future
>> connections.  This type of request represents the vast majority of the
>> black-hat probe attempts.
>>
>>>
>>> Are you willing to post your code somewhere like GitHub where everyone
>>> can see it?
>>>
>>> - -chris
>>
>> I have posted the 2 described classes at:
>>
>> https://github.com/alannotallan/tc-code-01
>>
>> Some points regarding the code & design:
>>
>> - Look for *Alan* in NioEndpoint.java to see the bit of code I added.
>>
>> - I built at least 8 proof-of-concept systems before I came up with
>> this design.  They were meant to prove an idea, not implement a final
>> version.  Therefore, some changes are to be expected.
>>
>> - I didn't include the default web app since my app heavily uses a
>> private library.  I would create a bare-bones default web app to
>> handle requests in the manner described.
>>
>> - I would add a valve to turn on/off this feature and set parameters as 
>> needed.
>>
>> - The IP address list is an ArrayList, which should probably be
>> changed to some kind of hash list 

Re: [tomcat] branch master updated: Allow recursive substitution of properties. Add tests and use indexOf("${") instead indexOf('$').

2020-08-14 Thread Mark Thomas
On 06/08/2020 12:26, jfcl...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jfclere 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 e7896ee  Allow recursive substitution of properties. Add tests and 
> use indexOf("${") instead indexOf('$').
>  new ec5e948  Merge pull request #309 from jfclere/trunk
> e7896ee is described below
> 
> commit e7896ee44a3c9f2cff4b93bca9ae6112917f6c88
> Author: Jean-Frederic Clere 
> AuthorDate: Fri Jun 26 09:50:09 2020 +0200
> 
> Allow recursive substitution of properties.
> Add tests and use indexOf("${") instead indexOf('$').

Change log?
Docs?

Or did I miss a commit somewhere?

Mark


> ---
>  java/org/apache/tomcat/util/IntrospectionUtils.java | 21 
> +++--
>  .../apache/tomcat/util/TestIntrospectionUtils.java  | 12 
>  2 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/java/org/apache/tomcat/util/IntrospectionUtils.java 
> b/java/org/apache/tomcat/util/IntrospectionUtils.java
> index 78ab66f..9f12323 100644
> --- a/java/org/apache/tomcat/util/IntrospectionUtils.java
> +++ b/java/org/apache/tomcat/util/IntrospectionUtils.java
> @@ -285,8 +285,17 @@ public final class IntrospectionUtils {
>  public static String replaceProperties(String value,
>  Hashtable staticProp, PropertySource 
> dynamicProp[],
>  ClassLoader classLoader) {
> +return replaceProperties(value, staticProp, dynamicProp, 
> classLoader, 0);
> +}
>  
> -if (value.indexOf('$') < 0) {
> +private static String replaceProperties(String value,
> +Hashtable staticProp, PropertySource 
> dynamicProp[],
> +ClassLoader classLoader, int iterationCount) {
> +if (value.indexOf("${") < 0) {
> +return value;
> +}
> +if (iterationCount >=20) {
> +log.warn("System property failed to update and remains [" + 
> value + "]");
>  return value;
>  }
>  StringBuilder sb = new StringBuilder();
> @@ -332,7 +341,15 @@ public final class IntrospectionUtils {
>  }
>  if (prev < value.length())
>  sb.append(value.substring(prev));
> -return sb.toString();
> +String newval = sb.toString();
> +if (newval.indexOf("${") < 0) {
> +return newval;
> +}
> +if (newval.equals(value))
> +return value;
> +if (log.isDebugEnabled())
> +log.debug("IntrospectionUtils.replaceProperties iter on: " + 
> newval);
> +return replaceProperties(newval, staticProp, dynamicProp, 
> classLoader, iterationCount+1);
>  }
>  
>  private static String getProperty(String name, Hashtable 
> staticProp,
> diff --git a/test/org/apache/tomcat/util/TestIntrospectionUtils.java 
> b/test/org/apache/tomcat/util/TestIntrospectionUtils.java
> index ed9fe39..73ea86a 100644
> --- a/test/org/apache/tomcat/util/TestIntrospectionUtils.java
> +++ b/test/org/apache/tomcat/util/TestIntrospectionUtils.java
> @@ -143,5 +143,17 @@ public class TestIntrospectionUtils {
>  
>  Assert.assertEquals("abc${normal}xyz", 
> IntrospectionUtils.replaceProperties(
>  "abc${normal}xyz", properties, null, null));
> +
> +properties.setProperty("my.ajp.port", "8009");
> +properties.setProperty("tomcat.ajp.port", "${my.ajp.port}");
> +Assert.assertEquals("8009", IntrospectionUtils.replaceProperties(
> +"${tomcat.ajp.port}", properties, null, null));
> +
> +}
> +@Test
> +public void testReplacePropertiesRecursively() {
> +Properties properties = new Properties();
> +properties.setProperty("replaceMe", "something ${replaceMe}");
> +IntrospectionUtils.replaceProperties("${replaceMe}", properties, 
> null, null);
>  }
>  }
> 
> 
> -
> 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



Travis failures on s390x

2020-08-14 Thread Mark Thomas
Hi,

I am seeing consistent failures for the TestParserNoStrictWhitespace on
Travis for s390x.

Rather than proxying my testing through Travis, I am trying to get
access to a free instance via IBM's cloud. I need to jump through some
account upgrade hoops to do that and IBM's systems seem to have
something against me at the moment.

I'll keep the list posted re progress but expect to see at least 3
failures when the unit tests run on s390x for now.

Mark

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



Re: [tomcat] branch master updated: Improve entity tag handling

2020-08-12 Thread Mark Thomas
On 11/08/2020 18:52, Mark Thomas wrote:
> On 11/08/2020 18:06, Michael Osipov wrote:
>> Am 2020-08-11 um 18:53 schrieb Mark Thomas:
>>> On 11/08/2020 17:29, Michael Osipov wrote:
>>>> Am 2020-08-11 um 16:52 schrieb ma...@apache.org:
>>>
>>> 
>>>
>>>>> commit bef507e1b7ac2eb0ff012d0d40035e218a5839cc
>>>>> Author: Mark Thomas 
>>>>> AuthorDate: Tue Aug 11 15:27:45 2020 +0100
>>>>>
>>>>>   Improve entity tag handling
> 
> 
> 
>>>> Even an option for this is wrong. I agree that we cannto produce strong
>>>> ETags by default, but it is now better decoupled and a subclass can
>>>> handle this. Please retain the semantics as described in RFC 7232.
>>>
>>> It isn't possible to retain the semantics of RFC 7232 because Tomcat
>>> prior to this commit did not implement them.
>>>
>>> If you look at the code prior to this commit, any "W/" was stripped from
>>> the resource ETag and the ETag values in the If-Match header before
>>> comparison. The result of doing that is that the comparison is
>>> effectively a weak one rather than a strong one.
>>>
>>> The option is required to preserve backwards compatibility.
>>
>> Granted. This ultimately means that Tomcat 10 should remove this cruft
>> and be RFC-compliant. For previous versions a comment about behavioral
>> change/deprecation should be added too.
>>
>> Can we agree on this?
> 
> Maybe.
> 
> I'd lean towards changing the default in Tomcat 10 to the RFC 7232
> compliant behaviour with a view to removing the option in Tomcat 11 if
> the change in default doesn't trigger a bunch of user questions / bug
> reports etc.
> 
> If the consensus is to remove the option immediately in Tomcat 10 I can
> live with that but my preference would be to change the default in 10
> and remove in 11.
> 
> What do others think?

As pointed out in PR #337, using weak comparison with If-Match is fairly
new (Match 2020). Therefore, I think it is reasonable to treat that as a
regression and fix it. That means reverting the addition of the
useWeakComparisonWithIfMatch option.

Mark

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



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

2020-08-11 Thread Mark Thomas
On 11/08/2020 17:30, Michael Osipov wrote:
> Am 2020-08-10 um 17:46 schrieb Mark Thomas:
>> Hi all,
>>
>> I'd like to propose removing all the functional spec pages from the
>> documentation web application.



> +1
> 
> Can you list them specifically? I am a bit lost which you exactly mean.

Everything under:

https://tomcat.apache.org/tomcat-10.0-doc/funcspecs/

Mark

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



Re: [tomcat] branch master updated: Improve entity tag handling

2020-08-11 Thread Mark Thomas
On 11/08/2020 18:06, Michael Osipov wrote:
> Am 2020-08-11 um 18:53 schrieb Mark Thomas:
>> On 11/08/2020 17:29, Michael Osipov wrote:
>>> Am 2020-08-11 um 16:52 schrieb ma...@apache.org:
>>
>> 
>>
>>>> commit bef507e1b7ac2eb0ff012d0d40035e218a5839cc
>>>> Author: Mark Thomas 
>>>> AuthorDate: Tue Aug 11 15:27:45 2020 +0100
>>>>
>>>>   Improve entity tag handling



>>> Even an option for this is wrong. I agree that we cannto produce strong
>>> ETags by default, but it is now better decoupled and a subclass can
>>> handle this. Please retain the semantics as described in RFC 7232.
>>
>> It isn't possible to retain the semantics of RFC 7232 because Tomcat
>> prior to this commit did not implement them.
>>
>> If you look at the code prior to this commit, any "W/" was stripped from
>> the resource ETag and the ETag values in the If-Match header before
>> comparison. The result of doing that is that the comparison is
>> effectively a weak one rather than a strong one.
>>
>> The option is required to preserve backwards compatibility.
> 
> Granted. This ultimately means that Tomcat 10 should remove this cruft
> and be RFC-compliant. For previous versions a comment about behavioral
> change/deprecation should be added too.
> 
> Can we agree on this?

Maybe.

I'd lean towards changing the default in Tomcat 10 to the RFC 7232
compliant behaviour with a view to removing the option in Tomcat 11 if
the change in default doesn't trigger a bunch of user questions / bug
reports etc.

If the consensus is to remove the option immediately in Tomcat 10 I can
live with that but my preference would be to change the default in 10
and remove in 11.

What do others think?

Mark


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



Re: [tomcat] branch master updated: Improve entity tag handling

2020-08-11 Thread Mark Thomas
On 11/08/2020 17:29, Michael Osipov wrote:
> Am 2020-08-11 um 16:52 schrieb ma...@apache.org:



>> commit bef507e1b7ac2eb0ff012d0d40035e218a5839cc
>> Author: Mark Thomas 
>> AuthorDate: Tue Aug 11 15:27:45 2020 +0100
>>
>>  Improve entity tag handling



>> @@ -279,6 +280,8 @@ public class DefaultServlet extends HttpServlet {
>>    */
>>   private boolean allowPartialPut = true;
>>   +    protected boolean useWeakComparisonWithIfMatch = true;
> 
> I really must object this. It clearly violates RFC 7232, section 3.1:

Prior to this commit the code did not use a strong comparison for
If-Match contrary to the requirements of RFC 7232.

This commit does not change this behaviour (by default)

This commit adds an option so that RFC 7232 compliant behaviour can be
enabled by those who want it without breaking backwards compatibility
for any users that are reliant on the current, non-compliant behaviour.

>>    An origin server MUST use the strong comparison function when
>>    comparing entity-tags for If-Match...
> 
> Even an option for this is wrong. I agree that we cannto produce strong
> ETags by default, but it is now better decoupled and a subclass can
> handle this. Please retain the semantics as described in RFC 7232.

It isn't possible to retain the semantics of RFC 7232 because Tomcat
prior to this commit did not implement them.

If you look at the code prior to this commit, any "W/" was stripped from
the resource ETag and the ETag values in the If-Match header before
comparison. The result of doing that is that the comparison is
effectively a weak one rather than a strong one.

The option is required to preserve backwards compatibility.

Mark

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



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

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

+1

No objections here.

Mark

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



[PROPOSAL] Remove the functional specs from docs webapp

2020-08-10 Thread Mark Thomas
Hi all,

I'd like to propose removing all the functional spec pages from the
documentation web application.

My reasoning for this proposal is, in short, that we aren't using or
maintaining these pages.

I don't recall any discussion of these docs on the dev list, proposals
to change them, proposals for additions etc.

There have been changes but going back over the changes from the last 10
years (and there are very few of them) they each appear to be part of a
wider global change that is updating something or removing references to
a feature that has been removed.

Should someone want to revive these pages, or more likely a subset of
them, they'll always be in the history.

Thoughts?

Mark

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



Re: Jakarta EE - JASPIC TCK (nightly)

2020-07-23 Thread Mark Thomas
Comments in line.

On 22/07/2020 10:19, Jean-Louis MONTEIRO wrote:
> Hi,
> 
> Small update on the progress.
> Passed: 52 and Failed: 9
> 
> I had a lot of random passed/failed for quite a while and finally found
> the reason yesterday.

I took a look at running these myself for Tomcat. There is a lot of
fiddly setup required. I may come back to this but for now I have other
priorities.

> I'd be interested in having some thoughts
> 
> AuthenticatorBase uses by default CallbackHandlerImpl
> 
> The CallbackHandlerImpl will create the GenericPrincipal for the subject
> based on the supported callbacks (CallerPrincipalCallback
> and GroupPrincipalCallback).
> 
> The AuthenticatorBase will pull the GenericPrincipal from the subject
> and do the register.
> 
> Long story short, the TCK calls the CallbackHandlerImpl twice with the
> CallerCallback and another time with CallerCallback + GroupCallback. We
> end up having 2 GenericPrincipal in the subject, one with the name only
> and another one with the name and roles.
> 
> JASPIC
> TCK 
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371
> 
> See 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96
> 
> Issue is that AuthenticatorBase pulls the first one available.
> See 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956
> 
> It will randomly pull the GenericPrincipal with the name only or the
> GenericPrincipal with the name and the roles.

Nice find. That must have been a real pain to track down.

I've been reading through the Jakarta Authentication specification (it
should be essentially identical to the previous JASPIC spec).

>From 3.8.3.1

... handle a CallerPrincipalCallback using the clientSubject as argument
to the callback. If more than one module of a context uses the
CallbackHandler to handle this callback, the context is responsible for
coordinating the calls such that the appropriate caller principal value
is established.


context here is referring to ServerAuthContext.

I think, in this case, the ServerAuthContext is being provided by the
TCK so my first impression is that this is a TCK bug.

I think this is worth raising on the Jakarta Authentication mailing lists.

> I did a fork in TomEE of the CallbackHandlerImpl to merge the
> GenericPrincipal in the name is the same and switched the
> CallbackHandlerImpl class in the BasicAuthenticator valve.

Yes, that is the same solution I thought of. Rather than add the newly
created GenericPrincipal to the Subject's private credentials, see if
the new GenericPrincipal has the same name as an existing
GenericPrincipal and if it does merge them.

I'm not sure that would be safe to do in the general case though.

Mark


> 
> Hope it's more or less clear ;-)
> Some thoughts would be very helpfup
> 
> 
> Le ven. 17 juil. 2020 à 18:21, Mark Thomas  <mailto:ma...@apache.org>> a écrit :
> 
> On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > Following up on this thread.
> > Pretty old I know. Haven't seen more recent topics on JASPIC and
> Jakarta
> > EE TCK.
> >
> > I tried to invest some time in TomEE to run the JASPIC TCK which is
> > fully relying on Tomcat.
> > I have counted 68 tests under the package com.sun.ts.tests.jaspic
> >
> > The wiki says 100+ so dunno where I'm missing some.
> >
> > Long story short, after some time configuring the thing, I've got 
> >
> > Passed: 38
> > Failed: 30
> >
> > Anyone looked at it already since Feb 2019?
> 
> I'm probably the most likely candidate and I haven't looked at it.
> 
> Mark
> 
> 
> >
> >
> > Le lun. 11 févr. 2019 à 21:34, Mark Thomas  <mailto:ma...@apache.org>
> > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> a écrit :
> >
> >     All,
> >
> >     I've started to look at the Jakarta EE JASPIC TCK.
> >
> >     Again a nightly build so usual caveats apply.
> >
> >     Progress is being tracked here:
> >     https://cwiki.apache.org/confluence/display/TOMCAT/JASPIC+TCK
> >
> >     Hmm.
> >
> >     This TCK seems very different to the standalone TCKs for the
> other specs
> >     we implement.
> >     - Deployment is significantly more complex. Rather than just
> WARs there
> >       are some JARS that need to 

Re: Jakarta EE APIs

2020-07-22 Thread Mark Thomas
On 22/07/2020 17:11, Romain Manni-Bucau wrote:
> Hi Mark,
> 
> Another option is to use Apache Geronimo specs (and update/create
> missing ones - think new mail one is not yet there for ex).

This is a distinct disadvantage.

> Advantage would be we wouldn't lose all the work around OSGi and jpms
> eclipse does not - and will not probably - handle (at least for the
> first part).

As compile time only JARs OSGi and JPMS are not a factor.

> It also cleans up the legal work for Tomcat as a small side bonus.

They are all EPLv2 licensed and compile time only so there isn't any
legal work required.

Mark


> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mer. 22 juil. 2020 à 17:53, Mark Thomas  <mailto:ma...@apache.org>> a écrit :
> 
> On 22/07/2020 15:53, Mark Thomas wrote:
> > Hi all,
> >
> > We currently have implementations for all of the Jakarta APIs that
> ship with Tomcat and partial implementations for 5 additional
> Jakarta APIs that are compile time only dependencies.
> >
> > I was checking those partial implementations earlier today when I
> noticed the Jakarta Mail API needed updating to use generics. I
> started on that but paused when it looked like a number of new
> (dummy) classes would be required.
> >
> > Considering alternative options, I wondered about depending on the
> Jakarta API JARs directly. This would be a return to the 5.5.x era
> approach without  hopefully, the issue that JARs could be difficult
> to obtain.
> >
> > I have this implemented locally. It removes about 1000 lines of
> .java files (although just under 10% of them are actual code) and
> adds about 100 lines of build file config and anither 50 of IDE
> configuration.
> >
> > With the Jakarta JARs being readily available in Maven Central I
> think the primary issue that led to the current approach is no
> longer a concern.
> >
> > Thoughts on switching to using the JARs directly? I can provide a
> PR if that is helpful.
> 
> For clarity, I'm only proposing to do this for Tomcat 10 where at least
> one of these APIs has changes other than just a package rename. I don't
> see the benefit in doing this for Tomact 9 and earlier.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> <mailto:dev-h...@tomcat.apache.org>
> 


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



Re: JAX-RPC and Tomcat 10

2020-07-22 Thread Mark Thomas
On 21/07/2020 14:44, Romain Manni-Bucau wrote:
> Yes, was thinking to tomee in particular since it does not use tomcat as
> a lib but really as the container so if the container fails then it can
> become hard if not "disabl-able" somehow (at least with subclassing or
> something programmatic).

I don't think I am going to pursue this at this time. The benefit is
minimal and the chances it breaks something or makes things difficult
for TomEE is high.

I may come back to this in the future.

Mark


> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mar. 21 juil. 2020 à 15:39, Mark Thomas  <mailto:ma...@apache.org>> a écrit :
> 
> On 21/07/2020 14:26, Romain Manni-Bucau wrote:
> > Hi Mark,
> >
> > e) c as default + add a toggle to behave as a? (thinking to container
> > extending tomcat where this shouldn't fail probably)
> 
> So keep the attributes in ContextService and friends that record the
> JAX-RPC so they are accessible to downstream projects that still want to
> support JAX-RPC? Are there any such projects? TomEE?
> 
> Mark
> 
> 
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> >
> 
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> >
> >
> > Le mar. 21 juil. 2020 à 14:34, Mark Thomas  <mailto:ma...@apache.org>
> > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> a écrit :
> >
> >     All,
> >
> >     JAX-RPC has been removed in Jakarta EE 9.
> >
> >     Implementations are free to continue supporting it if they wish.
> >
> >     My preference would be to remove JAX-RPS support in Tomcat 10.
> >
> >     I am working on this at the moment and am wondering how to
> handle the
> >     JAX-RPC elements we can't entirely remove.
> >
> >     There is a chain of references from web-app_5_0.xsd to
> >     jakartaee_web_services_client_2_0.xsd which still has a number of
> >     JAX-RPC specific attributes defined for "service-ref":
> >
> >     - jaxrpc-mapping-file
> >     - handler
> >     - handler-chains
> >
> >     (a double check I have identified all the JAX-RPC specific
> attributes
> >     would be appreciated)
> >
> >     This appears to be a consequence of the same element being
> used for
> >     JAX-RPC and JAX-WS.
> >
> >     Assuming there is consensus to remove JAX-RPC support then the
> question
> >     arises what do we do if we observe one of the JAX-RPC specific
> >     attributes above? Possible options include:
> >
> >     a) Ignore it and carry on
> >     b) Log a warning but otherwise ignore it and carry on
> >     c) Log an error and fail the deployment
> >     d) Something else
> >
> >     I'm currently leaning towards option c.
> >
> >     Thoughts?
> >
> >     Mark
> >
> >   
>  -
> >     To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org>
> >     <mailto:dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org>>
> >     For additional commands, e-mail: dev-h...@tomcat.apache.org
> <mailto:dev-h...@tomcat.apache.org>
> >     <mailto:dev-h...@tomcat.apache.org
> <mailto:dev-h...@tomcat.apache.org>>
> >
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> <mailto:dev-h...@tomcat.apache.org>
> 


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



Re: Jakarta EE APIs

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

For clarity, I'm only proposing to do this for Tomcat 10 where at least
one of these APIs has changes other than just a package rename. I don't
see the benefit in doing this for Tomact 9 and earlier.

Mark

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



Jakarta EE APIs

2020-07-22 Thread Mark Thomas
Hi all,

We currently have implementations for all of the Jakarta APIs that ship with 
Tomcat and partial implementations for 5 additional Jakarta APIs that are 
compile time only dependencies.

I was checking those partial implementations earlier today when I noticed the 
Jakarta Mail API needed updating to use generics. I started on that but paused 
when it looked like a number of new (dummy) classes would be required.

Considering alternative options, I wondered about depending on the Jakarta API 
JARs directly. This would be a return to the 5.5.x era approach without  
hopefully, the issue that JARs could be difficult to obtain.

I have this implemented locally. It removes about 1000 lines of .java files 
(although just under 10% of them are actual code) and adds about 100 lines of 
build file config and anither 50 of IDE configuration.

With the Jakarta JARs being readily available in Maven Central I think the 
primary issue that led to the current approach is no longer a concern.

Thoughts on switching to using the JARs directly? I can provide a PR if that is 
helpful.

Mark

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



Re: JAX-RPC and Tomcat 10

2020-07-21 Thread Mark Thomas
On 21/07/2020 14:26, Romain Manni-Bucau wrote:
> Hi Mark,
> 
> e) c as default + add a toggle to behave as a? (thinking to container
> extending tomcat where this shouldn't fail probably)

So keep the attributes in ContextService and friends that record the
JAX-RPC so they are accessible to downstream projects that still want to
support JAX-RPC? Are there any such projects? TomEE?

Mark


> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mar. 21 juil. 2020 à 14:34, Mark Thomas  <mailto:ma...@apache.org>> a écrit :
> 
> All,
> 
> JAX-RPC has been removed in Jakarta EE 9.
> 
> Implementations are free to continue supporting it if they wish.
> 
> My preference would be to remove JAX-RPS support in Tomcat 10.
> 
> I am working on this at the moment and am wondering how to handle the
> JAX-RPC elements we can't entirely remove.
> 
> There is a chain of references from web-app_5_0.xsd to
> jakartaee_web_services_client_2_0.xsd which still has a number of
> JAX-RPC specific attributes defined for "service-ref":
> 
> - jaxrpc-mapping-file
> - handler
> - handler-chains
> 
> (a double check I have identified all the JAX-RPC specific attributes
> would be appreciated)
> 
> This appears to be a consequence of the same element being used for
> JAX-RPC and JAX-WS.
> 
> Assuming there is consensus to remove JAX-RPC support then the question
> arises what do we do if we observe one of the JAX-RPC specific
> attributes above? Possible options include:
> 
> a) Ignore it and carry on
> b) Log a warning but otherwise ignore it and carry on
> c) Log an error and fail the deployment
> d) Something else
> 
> I'm currently leaning towards option c.
> 
> Thoughts?
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> <mailto:dev-h...@tomcat.apache.org>
> 


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



Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

2020-07-21 Thread Mark Thomas
On 21/07/2020 14:21, Coty Sutherland wrote:
> On Tue, Jul 21, 2020 at 9:15 AM Mark Thomas  <mailto:ma...@apache.org>> wrote:
> 
> On 21/07/2020 14:06, Coty Sutherland wrote:
> 
> 
> 
> > Oh yeah, you're right. They were included in the ASF binaries, but
> > Fedora (and Debian I guess) built their own bits and that's where the
> > classes came up missing. I wasn't able to identify *why* the classes
> > weren't present, only that it was the OSGi step that was removing
> them.
> > I thought initially that it was because the Fedora version of
> aqute-bnd
> > in use is 3.5, but I don't see the classes in my local build from the
> > 9.0.37 tag (using bnd 5.1) either.
> 
> OK. That means it isn't quite as bad as it could be.
> 
> What about the other packages in the original list? Are:
> 
> org.apache.tomcat.util.bcel
> org.apache.tomcat.util.http.fileupload.impl
> org.apache.tomcat.util.http.fileupload.util.mime
> 
> still present?
> 
> 
> Nope.

That looks like an issue that will need fixing in Fedora's build system.
Annotation scanning and the multipart upload API will be broken if those
packages are missing.

Going back to the fix I applied. The JSSE package was being used
externally so that change looks to be OK. The modeler.modules package
was not so I'm currently leaning towards reverting that part of the change.

Overall, I don't mind exposing these packages externally if necessary
but I'd prefer not to expose them if we don't have to.

Mark

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



  1   2   3   4   5   6   7   8   9   10   >