Re: Typo on Tomcat web site

2021-10-15 Thread Mark Thomas

On 15/10/2021 16:18, Emmanuel Lecharny wrote:

Hi !

you have announced Tomcat 8.5.72 last week, but the title contains a
typo, it tells "Tomcat 8.6.72 announced".

Thanks !


Fixed. Thanks for reporting.

Mark

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



Re: [tomcat] branch main updated: Do not add a trailing / to a request URI during canonicalization.

2021-10-14 Thread Mark Thomas

On 14/10/2021 12:37, Rémy Maucherat wrote:

On Thu, Oct 14, 2021 at 11:40 AM Mark Thomas  wrote:


On 14/10/2021 10:25, Konstantin Kolinko wrote:





d. If backporting, it would better be configurable.


Yeah, I know. I'd like to avoid lots of new configuration options. Maybe
a single new option "servlet6Canonicalization" for all the changes I am
proposing (there are a few more commits to come)?


These spec changes are great for consistency. However, I think it's a
major problem to backport, it's way better to leave things in place
and wait for that 9.x "branch" to force it on users. Ok for a general
"servlet6" configuration option to allow users to try out if they are
interested.


Ack. I'm going to wait for the Servlet 6 spec changes to be finalised 
before looking at a backport (with a configuration option).


Mark

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



[SECURITY] CVE-2021-42340 Apache Tomcat DoS

2021-10-14 Thread Mark Thomas

CVE-2021-42340 Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.1.0-M1 to 10.1.0-M5
Apache Tomcat 10.0.0-M10 to 10.0.11
Apache Tomcat 9.0.40 to 9.0.53
Apache Tomcat 8.5.60 to 8.5.71

Description:
The fix for bug 63362 introduced a memory leak. The object introduced to 
collect metrics for HTTP upgrade connections was not released for 
WebSocket connections once the WebSocket connection was closed. This 
created a memory leak that, over time, could lead to a denial of service 
via an OutOfMemoryError.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 10.1.0-M6 or later
- Upgrade to Apache Tomcat 10.0.12 or later
- Upgrade to Apache Tomcat 9.0.54 or later
- Upgrade to Apache Tomcat 8.5.72 or later

History:
2021-10-14 Original advisory
2021-10-14 Correct CVE reference in body of advisory

References:
[1] https://tomcat.apache.org/security-10.html
[2] https://tomcat.apache.org/security-9.html
[3] https://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



[SECURITY] CVE-2021-42340 Apache Tomcat DoS

2021-10-14 Thread Mark Thomas

CVE-2021-41079 Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.1.0-M1 to 10.1.0-M5
Apache Tomcat 10.0.0-M10 to 10.0.11
Apache Tomcat 9.0.40 to 9.0.53
Apache Tomcat 8.5.60 to 8.5.71

Description:
The fix for bug 63362 introduced a memory leak. The object introduced to 
collect metrics for HTTP upgrade connections was not released for 
WebSocket connections once the WebSocket connection was closed. This 
created a memory leak that, over time, could lead to a denial of service 
via an OutOfMemoryError.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 10.1.0-M6 or later
- Upgrade to Apache Tomcat 10.0.12 or later
- Upgrade to Apache Tomcat 9.0.54 or later
- Upgrade to Apache Tomcat 8.5.72 or later

History:
2021-10-14 Original advisory

References:
[1] https://tomcat.apache.org/security-10.html
[2] https://tomcat.apache.org/security-9.html
[3] https://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



Re: [tomcat] branch main updated: Ensure request URIs start with /

2021-10-14 Thread Mark Thomas

On 14/10/2021 11:32, Konstantin Kolinko wrote:

чт, 14 окт. 2021 г. в 13:01, Mark Thomas :


On 14/10/2021 10:59, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
   new d33cce6  Ensure request URIs start with /
d33cce6 is described below

commit d33cce6c196efed8e35518711ba27af0a8c93d09
Author: Mark Thomas 
AuthorDate: Wed Oct 13 18:33:55 2021 +0100

  Ensure request URIs start with /


This is the third and final additional default check for consideration
to back-port.

Servlet 6 also introduces the concept of "suspicious URIs" - sequences
like "/..;a=b/" and I'll be addressing those as an optional check in a
separate commit.


How about an "OPTIONS * HTTP/1.1" request?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.7

Does Tomcat respond to it by itself, without passing the request to servlets?


That gets handled before the "starts with '/' check". Tomcat provides 
the response.


https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/CoyoteAdapter.java#L613

Mark

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



Re: [tomcat] branch main updated: Ensure request URIs start with /

2021-10-14 Thread Mark Thomas

On 14/10/2021 10:59, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new d33cce6  Ensure request URIs start with /
d33cce6 is described below

commit d33cce6c196efed8e35518711ba27af0a8c93d09
Author: Mark Thomas 
AuthorDate: Wed Oct 13 18:33:55 2021 +0100

 Ensure request URIs start with /


This is the third and final additional default check for consideration 
to back-port.


Servlet 6 also introduces the concept of "suspicious URIs" - sequences 
like "/..;a=b/" and I'll be addressing those as an optional check in a 
separate commit.


Mark

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



Re: [tomcat] branch main updated: Invalid byte sequences result in a 400 response.

2021-10-14 Thread Mark Thomas

On 14/10/2021 10:34, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new c4f881f  Invalid byte sequences result in a 400 response.
c4f881f is described below

commit c4f881f5b68809139a3ebfeb3121c50bf9be8ea8
Author: Mark Thomas 
AuthorDate: Wed Oct 13 18:32:19 2021 +0100

 Invalid byte sequences result in a 400 response.
 
 This is part of the clarification in Servet 6.0 of the expected

 canonicalization Servlet containers are expected to apply to request
 URIs.


Another one for the back-port discussion.

The old behaviour was to replace the invalid sequences with a single 
replacement character which was expected to trigger either a 404 or an 
application error (depending on where in the URI the issue was).


The new behaviour rejects with a 400.

Mark

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



Re: [tomcat] branch main updated: Do not add a trailing / to a request URI during canonicalization.

2021-10-14 Thread Mark Thomas

On 14/10/2021 10:25, Konstantin Kolinko wrote:

чт, 14 окт. 2021 г. в 11:25, Mark Thomas :


On 14/10/2021 09:22, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
   new 70d4e9b  Do not add a trailing / to a request URI during 
canonicalization.
70d4e9b is described below

commit 70d4e9ba0a81a1d782fa50695a18d23f2f1f179c
Author: Mark Thomas 
AuthorDate: Wed Oct 13 18:28:45 2021 +0100

  Do not add a trailing / to a request URI during canonicalization.

  This is part of the clarification in Servet 6.0 of the expected
  canonicalization Servlet containers are expected to apply to request
  URIs.


All,

This is the first of several clarifications. The question is do we want
to back-port this change to earlier versions?

My current thinking is that we should as the current behaviour looks
wrong. We add a trailing "/" to simplify the normalization algorithm but
then don't remove it after we have completed normalization.



Hi!

I have not thought about this in detail.
Just several quick observations / quick thoughts.

a. Generally, I like doing things correctly.

b. Looking at test example:


doTestNormalize("/foo/.", "/foo");


It can be seen that "foo" is a directory,
and thus I think it actually behaves as follows:
Old behaviour:
1. Serve content of "/foo/"

New behaviour:
1. As "/foo" is a directory, Tomcat will likely won't serve it, but
will respond with a 302-redirect to "/foo/"
2. Serve content of "/foo/".

It is one more round-trip, but at least the browser will display a
correct normalized URL.


The extra round-trip annoys me a little. But then I think if that is an 
issue for the user agent, submit a sensible URI in the first place.



c. I think that browsers usually normalize URLs before making a
request, though I am not 100% sure. If so, the non-normalized URLs
will come from elsewhere, not from a browser. (And so there will be no
difference for browsers).


I can think a few possible sources:

- reverse proxies with possibly inefficient/wrong configuration

- attackers trying to exploit a reverse proxy / servlet container
  combination

- application generate URIs where the URiu has been generated by
  concatenating various strings



d. If backporting, it would better be configurable.


Yeah, I know. I'd like to avoid lots of new configuration options. Maybe 
a single new option "servlet6Canonicalization" for all the changes I am 
proposing (there are a few more commits to come)?


Mark

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



Re: [tomcat] branch main updated: Do not add a trailing / to a request URI during canonicalization.

2021-10-14 Thread Mark Thomas

On 14/10/2021 09:22, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 70d4e9b  Do not add a trailing / to a request URI during 
canonicalization.
70d4e9b is described below

commit 70d4e9ba0a81a1d782fa50695a18d23f2f1f179c
Author: Mark Thomas 
AuthorDate: Wed Oct 13 18:28:45 2021 +0100

 Do not add a trailing / to a request URI during canonicalization.
 
 This is part of the clarification in Servet 6.0 of the expected

 canonicalization Servlet containers are expected to apply to request
 URIs.


All,

This is the first of several clarifications. The question is do we want 
to back-port this change to earlier versions?


My current thinking is that we should as the current behaviour looks 
wrong. We add a trailing "/" to simplify the normalization algorithm but 
then don't remove it after we have completed normalization.


Thoughts?

Mark

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



Re: [tomcat] 02/02: Implement new approahc to doHead(). Expand testing to cover HTTP/2.

2021-10-12 Thread Mark Thomas

On 11/10/2021 22:41, Christopher Schultz wrote:

On 10/11/21 10:04, ma...@apache.org wrote:





+    @Deprecated
+    public static final String LEGACY_DO_HEAD = 
"jakarta.servlet.http.legacyDoHead";


Since 6.0? Looks like you are adding it to 10.x.


You are correct. It is "Servlet 6.0".


Also, is it appropriate to use the "jakarta.*" namespace, here?


It is specification defined, so yes.



Hmm, okay. Should we say "@since Servlet 6.0" since it's not clear what 
the version means? Or, because it's in HttpServlet (which is defined by 
servlet.spec), is it implied that all versions will mean "(of the 
servlet spec)"?


I think adding the explicit "Servlet" is a good idea. I'll check all of 
the @since tags in the spec classes and make sure they name the spec.


For the main Tomcat code, I think it is OK to not include "Tomcat" or 
"Apache Tomcat".


Looking at the main code, we haven't used @since very consistently (or 
at all really) for 8.5.x onwards. I'm wondering if we should just remove 
all the @since tags that refer to Tomcat 8.0.x and earlier.


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-10.0.x

2021-10-11 Thread Mark Thomas

On 11/10/2021 16:44, build...@apache.org wrote:

The Buildbot has detected a new failure on builder tomcat-10.0.x while building 
tomcat. Full details are available at:
 https://ci.apache.org/builders/tomcat-10.0.x/builds/183

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-10.0-commit' 
triggered this build
Build Source Stamp: [branch 10.0.x] 21ec01ff8f28c09bf821ec0d40c449a923803022
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1


The connector shutdown improvements are triggering a number of failures 
with APR. Initial analysis suggests the connector is shutting down 
before an in-progress write completes.


I'm investigating in more detail now.

On the plus side, this looks to have made a long standard APR issue 
(occasional crashes on stop) much more repeatable.


Mark

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



Re: ECJ, Tomcat 8.5.x and Java 17

2021-10-08 Thread Mark Thomas

On 07/10/2021 20:59, Konstantin Kolinko wrote:

чт, 7 окт. 2021 г. в 18:46, Mark Thomas :





Is this a problem worth solving? If it is, is there a better way?


Hi!

Last few days I was thinking of the following approaches:




I view users having to explicitly make a choice as a disadvantage rather 
than an advantage. I'd like the solution to be automatic.


a) is essentially another variation of b), c) & d) that uses "magic" to 
select the right JAR from ${cataliba.base}/lib


I wonder about another variation where the common loader syntax gets a 
Java version added. I'm not sure this level of configuration flexibility 
is necessary.


I *really* like e). That is very neat solution. My only concern is 
licensing. There are two issues:

- the JARs are licensed under different versions of the EPL
- ASF license policy says we can't modify EPL licensed artefacts

Given we aren't making source modifications, the ASF policy concern may 
not be valid.


The multiple license issue should be manageable with appropriate updates 
to out LICENSE and NOTICE files although I'd be more comfortable if we 
checked the Eclipse foundation were happy too.


Given the completely automatic nature, my current preference is for e) 
or a).


Looking at this another way, a) and e) are similar too. The difference 
is in a) Tomcat selects the correct JAR whereas in a) the JRE selects 
the right classes from a single JAR.


e) is certainly the more elegant solution but it does have some admin 
we'd need to do. a) is less elegant but avoids the admin.  Maybe 
implement a) as a stop-gap while we see if e) is possible?


Mark

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



ECJ, Tomcat 8.5.x and Java 17

2021-10-07 Thread Mark Thomas

Hi,

As you will have seen from the 8.5.72 release vote and/or bug 65599 
there is an issue with 8.5.x, Java 17 and ECJ.


In short:
- the Java EE 7 spec requires that Tomcat 8.5.x runs on Java 7
- Tomcat 8.5.x ships with ECJ 4.6.3, the newest version that runs on
  Java 7
- ECJ 4.63 fails on Java 17 onwards

I was wondering about shipping two versions of ECJ. Using 4.6.3 if 
running on Java 7 and 4.20 (or whatever Tomcat 9 onwards is using at the 
time) if running on Java 8.


The implementation could go in ClassLoaderFactory.validateFile(). The 
idea is that it would skip adding the ECJ version that wasn't required 
to the class path. It would be a bit of a hack and it would almost 
certainly need to be hard-coded rather than configurable in anyway.


This isn't the only way I can think of to do this but it is the one that 
requires the least user input (none) and is the least 'hacky'.


Thoughts?

Is this a problem worth solving? If it is, is there a better way?

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

2021-10-05 Thread Mark Thomas

On 05/10/2021 14:19, Christopher Schultz wrote:

On 10/5/21 03:49, Mark Thomas wrote:




I believe this is fixed. The Maven repository is now closed and the 
staging repository in the original VOTE is available:

https://repository.apache.org/content/repositories/orgapachetomcat-1337


What sorcery did you apply, here?


I cheated ;) I have SSH access to the box that hosts repository.a.o

rsync the staging repo to my local machine
sign everything that needed signing
rsync the *.asc files back to my home dir on repository.a.o
set file permissions correctly
rsync the *.asc files to the right place  on repository.a.o
close the repository via the UI

The files that were in the repository are unchanged. All I have done 
is signed the files that were missing signatures (*.jar, *.zip, 
*.tar.gz and *.pom) and the closed the repository.


There were so many files I wasn't sure where to begin. Were you able to 
get a comprehensive listing of the files in there in order to download 
them? I also don't know the mechanism for uploading them (it's all done 
by the build script, which presumably you wrote).


I just grabbed the whole directory structure and then did a recursive 
find to sign everything with a given file extension. Repeat for each 
file type that needed to be signed.


From memory, it was jfclere that updated the build scripts to talk to 
Nexus.


I suggest allowing 24 hours for anyone who voted to change their vote 
if they wish and then either complete the release if the votes remain 
unchanged or create a 8.5.73 release if there are any -1 votes.


So the files were produced by me but signed by you. That shouldn't be a 
problem unless someone wants to claim that a Tomcat release must be done 
by a single person, which is of course completely untrue.


+1

Thanks for doing this. I'd love the details so I can recover in the 
future if necessary.


Generally, this will need someone from the infra team to fix this. At 
least the way I fixed it anyway. There might be a way to fix this via 
the UI but I couldn't see one although as the creator of the repository 
you might have a few more options.


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

2021-10-05 Thread Mark Thomas

On 05/10/2021 08:49, Mark Thomas wrote:

On 05/10/2021 08:12, Mark Thomas wrote:

On 05/10/2021 01:32, Christopher Schultz wrote:

All,

I'm sorry about this release. The VOTE has officially passed, but I 
fear I may have to re-roll the release as the Maven artifacts were 
not signed properly at the time. I'm trying to decide what to do 
about it.


I can re-roll the release under the same version number, but I'll 
have to re-generate everything. I can't guarantee it will be 
byte-for-byte identical for a few reasons, so I'm not sure how 
comfortable everyone will be with their votes standing.


Asking for a re-vote on a release is a little odd and may actually 
not be okay ASF-wise. So I'm thinking maybe I should cancel the vote 
and use a new version number which is source-identical to 8.5.72 and 
call for a new vote with the new artifacts.


I apologize for the confusion; I didn't notice the missing Maven 
items at the time, and cleared-away everything after uploading 
everything to svn.


I might have a way to fix this. Given em an hour or two...


I believe this is fixed. The Maven repository is now closed and the 
staging repository in the original VOTE is available:

https://repository.apache.org/content/repositories/orgapachetomcat-1337

The files that were in the repository are unchanged. All I have done is 
signed the files that were missing signatures (*.jar, *.zip, *.tar.gz 
and *.pom) and the closed the repository.


I suggest allowing 24 hours for anyone who voted to change their vote if 
they wish and then either complete the release if the votes remain 
unchanged or create a 8.5.73 release if there are any -1 votes.


One additional piece of information. I have checked all the binaries and 
they are identical to those available at dist.a.o. I haven't checked the 
-sources.jar files.


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

2021-10-05 Thread Mark Thomas

On 05/10/2021 08:12, Mark Thomas wrote:

On 05/10/2021 01:32, Christopher Schultz wrote:

All,

I'm sorry about this release. The VOTE has officially passed, but I 
fear I may have to re-roll the release as the Maven artifacts were not 
signed properly at the time. I'm trying to decide what to do about it.


I can re-roll the release under the same version number, but I'll have 
to re-generate everything. I can't guarantee it will be byte-for-byte 
identical for a few reasons, so I'm not sure how comfortable everyone 
will be with their votes standing.


Asking for a re-vote on a release is a little odd and may actually not 
be okay ASF-wise. So I'm thinking maybe I should cancel the vote and 
use a new version number which is source-identical to 8.5.72 and call 
for a new vote with the new artifacts.


I apologize for the confusion; I didn't notice the missing Maven items 
at the time, and cleared-away everything after uploading everything to 
svn.


I might have a way to fix this. Given em an hour or two...


I believe this is fixed. The Maven repository is now closed and the 
staging repository in the original VOTE is available:

https://repository.apache.org/content/repositories/orgapachetomcat-1337

The files that were in the repository are unchanged. All I have done is 
signed the files that were missing signatures (*.jar, *.zip, *.tar.gz 
and *.pom) and the closed the repository.


I suggest allowing 24 hours for anyone who voted to change their vote if 
they wish and then either complete the release if the votes remain 
unchanged or create a 8.5.73 release if there are any -1 votes.


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

2021-10-05 Thread Mark Thomas

On 05/10/2021 01:32, Christopher Schultz wrote:

All,

I'm sorry about this release. The VOTE has officially passed, but I fear 
I may have to re-roll the release as the Maven artifacts were not signed 
properly at the time. I'm trying to decide what to do about it.


I can re-roll the release under the same version number, but I'll have 
to re-generate everything. I can't guarantee it will be byte-for-byte 
identical for a few reasons, so I'm not sure how comfortable everyone 
will be with their votes standing.


Asking for a re-vote on a release is a little odd and may actually not 
be okay ASF-wise. So I'm thinking maybe I should cancel the vote and use 
a new version number which is source-identical to 8.5.72 and call for a 
new vote with the new artifacts.


I apologize for the confusion; I didn't notice the missing Maven items 
at the time, and cleared-away everything after uploading everything to svn.


I might have a way to fix this. Given em an hour or two...

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.12 available

2021-10-04 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.12.

This release is targeted at Jakarta EE 9.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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.

The notable changes compared to 10.0.11 include:

- Further robustness improvements to HTTP/2 flow control window
  management

- Improvements to the DataSourceUserDatabase

- Fix an issue that caused some Servlet non-blocking API reads of the
  HTTP request body to incorrectly use blocking IO.

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



[ANN] Apache Tomcat 10.1.0-M6 (alpha) available

2021-10-04 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.0-M6 (alpha).

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.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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


- Servlet API updates for Servlet 6 including removal of all deprecated
  code, updated schemas and a new API for connection and request IDs.

- EL API updates for EL 5.0 including deprecation of the use of
  FeatureDescriptor, improvements to BeanELResolver and the addition of
  MethodReference

- Further robustness improvements to HTTP/2 flow control window
  management

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.1-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: [VOTE] Release Apache Tomcat 8.5.72

2021-10-04 Thread Mark Thomas

On 03/10/2021 15:18, Konstantin Kolinko wrote:

вс, 3 окт. 2021 г. в 16:10, Christopher Schultz :


Konstantin,


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




1. Maven repo is still 404, and


Apologies for forgetting to close the Maven repo. Please check again.



The maven repo is still in the same state,

404 - Repository "orgapachetomcat-1337 (staging: open)"
[id=orgapachetomcat-1337] exists but is not exposed.


Chris,

The closing of the repository failed because none of .asc files appear 
to have been uploaded.


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

2021-10-01 Thread Mark Thomas

The following votes were cast:

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

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


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



Re: [VOTE][RESULT] Release Apache Tomcat 10.1.0-M6

2021-10-01 Thread Mark Thomas

The following votes were cast:

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

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Msrk

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



Re: [VOTE] Release Apache Tomcat 10.0.12

2021-09-30 Thread Mark Thomas

On 28/09/2021 14:59, Mark Thomas wrote:


The proposed 10.0.12 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.0.12 (stable)


Unit tests pass for NIO, NIO2 and APR/Native with latest Tomcat Native 
1.2.x build with latest OpenSSL 3.1.x


Tested on Linux, MacOS and Windows.

Mark

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M6

2021-09-30 Thread Mark Thomas

On 28/09/2021 13:31, Mark Thomas wrote:

The proposed 10.1.0-M6 release is:
[ ] Broken - do not release
[X] Alpha - go ahead and release as 10.1.0-M6 (alpha)


Unit tests pass for NIO and NIO2 with latest Tomcat Native 1.2.x build 
with latest OpenSSL 3.1.x


Tested on Linux, MacOS and Windows.

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

2021-09-28 Thread Mark Thomas

The proposed Apache Tomcat 10.0.12 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to jakarta.*

Applications that run on Tomcat 9 will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be 
placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory


The notable changes compared to 10.0.11 are:

- Further robustness improvements to HTTP/2 flow control window
  management

- Improvements to the DataSourceUserDatabase

- Fix an issue that caused some Servlet non-blocking API reads of the
  HTTP request body to incorrectly use blocking IO.

Along with lots of other bug fixes and improvements.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.12/

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

The tag is:
https://github.com/apache/tomcat/tree/10.0.12
84e18583f461778707f7fd2e25b1f0677e44e899

The proposed 10.0.12 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 10.0.12 (stable)

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



[VOTE] Release Apache Tomcat 10.1.0-M6

2021-09-28 Thread Mark Thomas

The proposed Apache Tomcat 10.1.0-M6 release is now available for
voting.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


The notable changes compared to 10.1.0-M5 are:

- Servlet API updates for Servlet 6 including removal of all deprecated
  code, updated schemas and a new API for connection and request IDs.

- EL API updates for EL 5.0 including deprecation of the use of
  FeatureDescriptor, improvements to BeanELResolver and the addition of
  MethodReference

- Further robustness improvements to HTTP/2 flow control window
  management

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M6/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.0-M6
51d1031c36c0f2b3ee1e0d14b56228a559144153


The proposed 10.1.0-M6 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 10.1.0-M6 (alpha)

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



Re: Refactoring handling of TRACE requests

2021-09-28 Thread Mark Thomas

On 28/09/2021 00:33, Konstantin Kolinko wrote:

пн, 27 сент. 2021 г. в 14:03, Mark Thomas :


Hi all,

I've been having some conversations at $work about Tomcat's handling of
TRACE requests and the allowTrace option on the Connector. Something
that was said in that discussion got me thinking. Why do we have special
handling for TRACE requests on the Connector? Why not use a security
constraint in the global web.xml?

I've done a quick test, setting allowTrace to true on the Connector and
adding the following to the global web.xml:

  

  /*
  TRACE


  

This blocks TRACE requests as expected.

What do the folks here think about deprecating allowTrace on the
Connector for 10.0.x and removing it (and the special handling in
HttpServlet) in 10.1.x onwards - replacing it with the security
constraint above.


In short, it does not work. See point 1.c) below and my test runs
below an "~" bar.
I am leaving my other points as I wrote them, for completeness.


Thanks for checking this. I hadn't fully thought through the 
implications of the rules for combining security constraints.


I agree, my proposal isn't going to work.

Mark

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



Re: Refactoring handling of TRACE requests

2021-09-27 Thread Mark Thomas

On 27/09/2021 14:02, Rémy Maucherat wrote:

On Mon, Sep 27, 2021 at 1:03 PM Mark Thomas  wrote:


Hi all,

I've been having some conversations at $work about Tomcat's handling of
TRACE requests and the allowTrace option on the Connector. Something
that was said in that discussion got me thinking. Why do we have special
handling for TRACE requests on the Connector? Why not use a security
constraint in the global web.xml?

I've done a quick test, setting allowTrace to true on the Connector and
adding the following to the global web.xml:

  

  /*
  TRACE


  

This blocks TRACE requests as expected.

What do the folks here think about deprecating allowTrace on the
Connector for 10.0.x and removing it (and the special handling in
HttpServlet) in 10.1.x onwards - replacing it with the security
constraint above.


It might not matter much these days, but this still looks like it
would be considerably less efficient (for a flag that will actually
never be set to false, right ?).


I can do some performance testing to see what the impact is. We can then 
judge the impact vs the benefit.


I suspect most users will leave the option as is but there might be a 
few that are happy enabling TRACE.


Mark

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



Re: [tomcat] branch main updated: Implement the new connection ID and request ID API for Servlet 6.0

2021-09-27 Thread Mark Thomas

On 24/09/2021 20:27, Christopher Schultz wrote:

Mark,

On 9/24/21 14:39, Mark Thomas wrote:

On 24/09/2021 19:21, Christopher Schultz wrote:

Mark,

Sorry for the top-post but this is quite a long patch and it will be 
easier to find my comments up here.


No problem. Makes sense.

When generating the String value for the request identifier, you 
could use:


   private String requestId = 
Long.toHexString(requestIdGenerator.getAndIncrement());


This would produce smaller strings, use slightly less CPU, and then 
nobody cares whether the value is - or +.


Excellent. I like it. I'll make the change. We might need those extra 
3,000,000 years before failover ;)


Should the new request-id be generated during recycle() or during 
another time? Is there a method which is always called to 
re-commission a Request object? If so, I think it would make more 
sense to leave the requestId alone in recycle() and allocate the new 
request-id in that other method.


Not sure. I'll take a look.

In cases where there are use-after-recycle errors in an application, 
having the old request-id might be helpful in debugging.


I think that could go either way. The ID changing as soon as recycle 
is called might make use after recycle easier to spot.


The more I think about this, the more I think changing ID on recycle 
is the way to go but I am prepared to be convinced otherwise.


How about requestId = -1 on recycle (and create) but set it to a 
definite value when it's "in service"?


Whilst I like the idea of being able to tell from the ID that the 
request is recycled, at the back of my mind are some historical bugs 
where we have two Processors (and hence 2 Requests) assigned to the same 
connection at the same time. I think always having a unique ID for the 
request is important for debugging that use case.


Your suggestion got me thinking though. It might be possible to ensure 
that once the request has been recycled (and the new ID issued) that 
subsequent calls to recycle before the start of the next request don't 
trigger an increment in the ID.


Mark

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



Refactoring handling of TRACE requests

2021-09-27 Thread Mark Thomas

Hi all,

I've been having some conversations at $work about Tomcat's handling of 
TRACE requests and the allowTrace option on the Connector. Something 
that was said in that discussion got me thinking. Why do we have special 
handling for TRACE requests on the Connector? Why not use a security 
constraint in the global web.xml?


I've done a quick test, setting allowTrace to true on the Connector and 
adding the following to the global web.xml:



  
/*
TRACE
  
  


This blocks TRACE requests as expected.

What do the folks here think about deprecating allowTrace on the 
Connector for 10.0.x and removing it (and the special handling in 
HttpServlet) in 10.1.x onwards - replacing it with the security 
constraint above.


Mark

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



Re: [tomcat] branch main updated: Implement the new connection ID and request ID API for Servlet 6.0

2021-09-24 Thread Mark Thomas

On 24/09/2021 19:21, Christopher Schultz wrote:

Mark,

Sorry for the top-post but this is quite a long patch and it will be 
easier to find my comments up here.


No problem. Makes sense.


When generating the String value for the request identifier, you could use:

   private String requestId = 
Long.toHexString(requestIdGenerator.getAndIncrement());


This would produce smaller strings, use slightly less CPU, and then 
nobody cares whether the value is - or +.


Excellent. I like it. I'll make the change. We might need those extra 
3,000,000 years before failover ;)


Should the new request-id be generated during recycle() or during 
another time? Is there a method which is always called to re-commission 
a Request object? If so, I think it would make more sense to leave the 
requestId alone in recycle() and allocate the new request-id in that 
other method.


Not sure. I'll take a look.

In cases where there are use-after-recycle errors in an application, 
having the old request-id might be helpful in debugging.


I think that could go either way. The ID changing as soon as recycle is 
called might make use after recycle easier to spot.


The more I think about this, the more I think changing ID on recycle is 
the way to go but I am prepared to be convinced otherwise.


Mark

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



Re: [tomcat] branch main updated: Implement the new connection ID and request ID API for Servlet 6.0

2021-09-24 Thread Mark Thomas

On 24/09/2021 19:03, Christopher Schultz wrote:

Mark,

I haven't looked at the patch yet but I was thinking about this since 
you mentioned it at ApacheCon.


Many load-balancers and other similar network systems are capable of 
generating their own request-identifiers and sending them as request 
headers to origin servers. I think it would make sense to allow the user 
to either use a container-generated request identifier (as you have 
implemented it) or to allow a (trusted) upstream component to provide 
one to the container.


WDYT?


I don't think that covers all use cases as it requires the successful 
parsing of the incoming request.


Users are free to log multiple IDs from different sources if that makes 
sense for their environment. These IDs are primarily to fill the gap 
that there wasn't IDs from the container perspective.


Mark

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



Re: [tomcat] branch main updated: Implement the new connection ID and request ID API for Servlet 6.0

2021-09-24 Thread Mark Thomas

On 24/09/2021 18:30, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new b7c05a8  Implement the new connection ID and request ID API for 
Servlet 6.0


Doing some simple testing locally highlighted something interesting.

The Coyote Request gets recycled twice for most requests. Once when the 
HTTP request is complete and once when the Processor is recycled just 
before the socket is added to the Poller.


I took a look to see if I could convince myself that one of these could 
be removed. The first is definitely required for pipelined requests. The 
second looks to be required for some error conditions. If anyone fancies 
a brain teaser then finding a way to have just one call to 
Request.recycle() might keep you entertained for a while ;)


Mark

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



[jira] [Resolved] (MTOMCAT-327) Tomcat 9.0.50 and it has apr-1.7.0 dependency, with Address CVE-2021-35940

2021-09-22 Thread Mark Thomas (Jira)


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

Mark Thomas resolved MTOMCAT-327.
-
Resolution: Invalid

Again, this is not an issue with the Apache Tomact Maven plugin.

> Tomcat 9.0.50 and it has apr-1.7.0 dependency, with Address CVE-2021-35940
> --
>
> Key: MTOMCAT-327
> URL: https://issues.apache.org/jira/browse/MTOMCAT-327
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>Reporter: yuanhuaijiang
>Priority: Major
>
> Tomcat 9.0.50 and it has apr-1.7.0 dependency, which is 
> vulnerable.(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35940)



--
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-327) Tomcat 9.0.50 and it has apr-1.7.0 dependency, with Address CVE-2021-35940

2021-09-22 Thread Mark Thomas (Jira)


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

Mark Thomas resolved MTOMCAT-327.
-
Resolution: Invalid

Not an Apache Tomcat Maven Plugin issue.

> Tomcat 9.0.50 and it has apr-1.7.0 dependency, with Address CVE-2021-35940
> --
>
> Key: MTOMCAT-327
> URL: https://issues.apache.org/jira/browse/MTOMCAT-327
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>Reporter: yuanhuaijiang
>Priority: Major
>
> Tomcat 9.0.50 and it has apr-1.7.0 dependency, which is 
> vulnerable.(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35940)



--
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: [tomcat] branch main updated: Fix BZ 65563. Correct parsing of Content-Range headers

2021-09-17 Thread Mark Thomas

On 17/09/2021 11:55, Rainer Jung wrote:

Am 09.09.2021 um 09:36 schrieb ma...@apache.org:

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 86bbbc6..aa4aac8 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,16 @@
    issues do not "pop up" wrt. others).
  -->
  
+  
+    
+  
+    65563: Correct parsing of HTTP 
Content-Rnage


Small typo s/Rnage/Range/
Applies to all active branches.


Thanks.

Fixed.

Mark

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



Re: [tomcat] branch main updated: Fix MethodExpression.getMethodInfo() when parameters are provided

2021-09-17 Thread Mark Thomas

On 17/09/2021 21:33, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 93dd0c2  Fix MethodExpression.getMethodInfo() when parameters are 
provided
93dd0c2 is described below

commit 93dd0c2e2a15b9e5d37a92b4d435c4f53de3c00d
Author: Mark Thomas 
AuthorDate: Fri Sep 17 21:32:38 2021 +0100

 Fix MethodExpression.getMethodInfo() when parameters are provided


Just for background information, I found this while adding some 
additional tests to the EL TCK for 5.0 to provide some coverage for the 
changes between 4.0 and 5.0.


Mark

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



[SECURITY] CVE-2021-41079 Apache Tomcat DoS

2021-09-15 Thread Mark Thomas

CVE-2021-41079 Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.0.0-M1 to 10.0.2
Apache Tomcat 9.0.0-M1 to 9.0.43
Apache Tomcat 8.5.0 to 8.5.63

Description:
When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a 
specially crafted packet could be used to trigger an infinite loop 
resulting in a denial of service.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 10.0.4 or later
- Upgrade to Apache Tomcat 9.0.44 or later
- Upgrade to Apache Tomcat 8.5.64 or later

Note: This issue was fixed in Apache Tomcat 10.0.3 but the release vote 
for the 10.0.3 release candidate did not pass. Therefore, although users 
must download 10.0.4 to obtain a version that includes a fix for this 
issue, version 10.0.3 is not included in the list of affected versions.


Credit:
The Apache Tomcat Security Team would like to thank:
- Thomas Wozenilek for originally reporting this issue
- David Frankson of Infinite Campus for providing a test case that
  reproduced the issue.

History:
2021-09-15 Original advisory

References:
[1] https://tomcat.apache.org/security-10.html
[2] https://tomcat.apache.org/security-9.html
[3] https://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



Re: Drop module-info from tomcat*.jar?

2021-09-15 Thread Mark Thomas

On 15/09/2021 11:07, Romain Manni-Bucau wrote:

I think the last option is maybe the target: modularize tomcat properly.


"Properly" is a highly subjective judgement. There are going to be 
wildly differing views on what constitutes a "proper" degree of modularity.



The people willing to have as few as possible modules would just use a new
"bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
which provides a bundle way of building apps but is not flexible.
So regarding JPMS I think it is either being really modular or not being
modular since the in between state leads to unsatisfied people and the
biggest constraints come from JPMS.
Is it something targettable or do you think it is too much work?


Don't know until we try.

My instinct is that making more modules optional and then logging 
warnings if users try to use Tomcat features that depend on a missing 
optional module is doable - but I haven't done any analysis to back that up.


I don't have a sense of how many more modules like SSI could be 
realistically created.


Broadly, embedded is going to be the "bundle" module (well, modules) and 
if folks want a finer-grained selection then they can use the JARs from 
the standard distribution.


Mark




side note: fine for me if it targets only 10.1.

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. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :


On 15/09/2021 08:34, Romain Manni-Bucau wrote:

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.


I am assuming this is with embedded.


The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to

be

able to use it in the CP if a jlink custom distro (without

forking/patching

tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina

for

ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it


Not an option as we have users that have requested it.


2. making it optional (I assume it can be released in jars with

classifiers

only)


Maybe, but it adds a bunch of artefacts.


3. making it more accurate - but this highly depends how the user

consumes

it (in particular for tomcat embed flavor)


I think a variation of this is the way to go.

Looking at the list of dependencies, I suspect most of them can be made
optional. That involves fine-tuning the bnd configuration files.

That does raise the question what we do when a user tries to use the
optional features. I think we need to:
- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
and log an appropriate error message if the module is missing.

Splitting embedded into lots of little modules where all the
dependencies are correctly declared is another solution but we have
users that have requested we provide Tomcat in as few JARs as possible.

I think we are approaching "can't please all of the people, all of the
time" territory here.

Mark

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







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



Re: Drop module-info from tomcat*.jar?

2021-09-15 Thread Mark Thomas

On 15/09/2021 08:34, Romain Manni-Bucau wrote:

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.


I am assuming this is with embedded.


The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to be
able to use it in the CP if a jlink custom distro (without forking/patching
tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina for
ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it


Not an option as we have users that have requested it.


2. making it optional (I assume it can be released in jars with classifiers
only)


Maybe, but it adds a bunch of artefacts.


3. making it more accurate - but this highly depends how the user consumes
it (in particular for tomcat embed flavor)


I think a variation of this is the way to go.

Looking at the list of dependencies, I suspect most of them can be made 
optional. That involves fine-tuning the bnd configuration files.


That does raise the question what we do when a user tries to use the 
optional features. I think we need to:

- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
  and log an appropriate error message if the module is missing.

Splitting embedded into lots of little modules where all the 
dependencies are correctly declared is another solution but we have 
users that have requested we provide Tomcat in as few JARs as possible.


I think we are approaching "can't please all of the people, all of the 
time" territory here.


Mark

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



Re: [tomcat] branch main updated (878caf6 -> dbd137f)

2021-09-13 Thread Mark Thomas

On 13/09/2021 17:05, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


 from 878caf6  Use DataSource in DataSourceUserDatabase constructor
  new 3910ab7  Avoid StackOverflowException
  new 74681f5  Step 1 - merge BackLogTracker into AbstractStream
  new dbd137f  Remove clear whole backlog shortcut


Sorry, I pushed this before I was ready. I'm still working on the full fix.

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.11 available

2021-09-13 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.11.

This release is targeted at Jakarta EE 9.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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.

The notable changes compared to 10.0.10 include:

- Add a UserDatabase implementation as a superset of the DataSourceRealm
  functionality.

- Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
  Commons Pool to 2.11.1

- Update the packaged version of the Tomcat Native Library to 1.2.31 to
  pick up Windows binaries built with OpenSSL 1.1.1l.

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



[ANN] Apache Tomcat 10.1.0-M5 (alpha) available

2021-09-13 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.0-M5 (alpha).

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.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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


- Remove the deprecated APR/Native connector which includes the HTTP APR
  and the AJP APR connector. Also remove the Java interfaces to the
  APR/Native library that are not used by the OpenSSL integration for
  the NIO and NIO2 connectors.

- Add a UserDatabase implementation as a superset of the DataSourceRealm
  functionality.

- Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
  Commons Pool to 2.11.1

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.1-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: [VOTE][RESULT] Release Apache Tomcat 10.0.11

2021-09-10 Thread Mark Thomas

The following votes were cast:

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

No other votes were cast.
The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M5

2021-09-10 Thread Mark Thomas

The following votes were cast:

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

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M5

2021-09-10 Thread Mark Thomas

On 08/09/2021 09:52, Martin Grigorov wrote:

On Mon, Sep 6, 2021 at 5:43 PM Mark Thomas  wrote:





It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M4/



This should be -M5


Sorry about that. I must have missed it in the copy/paste/edit.

Mark

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



[jira] [Deleted] (MTOMCAT-326) Slot Deposit Dana Bersama SBA99

2021-09-10 Thread Mark Thomas (Jira)


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

Mark Thomas deleted MTOMCAT-326:



> Slot Deposit Dana Bersama SBA99
> ---
>
> Key: MTOMCAT-326
> URL: https://issues.apache.org/jira/browse/MTOMCAT-326
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>Reporter: claudiatan353
>Assignee: Olivier Lamy
>Priority: Trivial
>
> h1. *Persiapan Slot Gacor 2021 Yang Menjadikan Pemain Menang Besar*
> [*!https://i.imgur.com/khrTiXA.png!*|https://18.139.152.126/]
> Bermain dalam permainan judi *Slot Gacor 2021* online menjadi satu pilihan 
> permainan yang dapat ditetapkan oleh para pemain judi online di internet. 
> Bermain game judi slot online merupakan satu pilihan dari beragam game judi 
> yang bisa ditemukan pemain ketika menjalani proses permainan judi online 
> [Slot Deposit Dana|http://45.76.153.6/] hanya di SBA99  . Kondisi permainan 
> dalam sarana online di internet memang cukup beragam dimana pemain dapat 
> memilih satu permainan untuk dimainkan oleh para pemain judi online sehingga 
> memperbesar peluangnya untuk menang.
> Permainan judi dalam sarana online di internet menjadi salah satu langkah 
> dalam bermain judi online yang perlu diperhatikan pemain dengan baik. 
> Aktivitas permainan judi online di internet dapat menjadikan pemain memiliki 
> kesempatan untuk bisa menjalani proses permainan judi dengan baik. Bagi para 
> pemain judi online di internet, bermain dalam sarana online terbaik SBA99 
> memberikan kesempatan pemain mendapatkan pilihan game yang tepat dan sesuai 
> dengan kebutuhan para pemain judi online.
> [!https://i.imgur.com/KjS1xDw.png!|https://bit.ly/3t1QuzA]
> Dalam menetapkan pilihan permainan yang akan dimainkan oleh para pemain judi 
> online di internet, pemain perlu mempertimbangkan beberapa hal yang sebaiknya 
> dipahami sebelum memilih game judi. Salah satu hal yang dapat menjadikan 
> pemain bisa memilih permainan judi dengan mudah dan tepat adalah kondisi 
> permainan yang populer dan banyak tersedia dalam pilihan agen judi online di 
> internet.
> h1. *Permainan Slot Jadi Satu Pilihan Populer Para Pemain Judi Online*
> Bagi para petaruh judi online, game *slot gacor 2021* online menjadi satu 
> permainan yang dapat menarik untuk dimainkan oleh para pemain judi online. 
> Permainan slot merupakan game yang mudah dan populer di dalam sarana berjudi 
> online di internet. Game slot jadi satu permainan yang mudah untuk dijalani 
> pejudi sehingga populer di kalangan para pemain judi baru. Pemain pemula 
> maupun pejudi berpengalaman dapat memilih game slot tersebut.
> Aktivitas permainan slot online mudah dimainkan karena semua proses bermain 
> judinya dijalani dengan menggunakan mesin *_link slot terbaik_* online. Agar 
> pemain dapat memanfaatkan permainan yang mudah tersebut dengan benar, para 
> pemain judi online di internet harus bisa memainkan game tersebut secara 
> tepat sehingga mampu memberikan kesempatan menang untuk bettor.
> h2. *Persiapan Pemain Dalam Menjalani Proses Permainan Judi Slot*
> [*!https://i.imgur.com/SeG4NJC.png!*|https://bit.ly/3BzzYdf]
> Berkaitan dengan proses bermain judi slot online, pemain harus melakukan satu 
> usaha penting agar ada kesempatan menang yang terbuka lebar ketika para 
> pemain judi online memainkannya. Persiapan dalam bermain judi online 
> merupakan kebutuhan yang sudah selayaknya dijalani agar pemain bisa melakukan 
> aktivitas berjudi di internet. Bentuk persiapan yang harus dilakukan para 
> pemain judi online dalam menjalani proses permainan judi slot online adalah 
> dengan memperhatikan penjelasan di bawah ini.
>  * *Memilih Dan Menetapkan Agen Judi Online Dengan Kualitas Terbaik*
> Cara pertama yang dapat dilakukan para pemain judi online di internet agar 
> dapat siap memainkan game slot online adalah dengan memilih dan menetapkan 
> agen judi online tempat bermain slot. Pilihan agen judi tempat pemain 
> menjalani proses permainan judi slot online perlu dipertimbangkan dengan baik 
> mengingat adanya beragam *_situs mpo slot_* judi online yang tersebar luas di 
> internet sekarang ini.
> Bermain judi dalam sarana online di internet akan membantu pemain mendapatkan 
> kesempatan untuk bisa berjudi dengan baik ketika pilihan sarananya 
> berkualitas seperti SBA99. Pemain harus memperhatikan beberapa kondisi dalam 
> permainan judi *slot gacor 2021* online agar dapat berjudi dengan lancar. 
> Pemain judi online dapat memperhatikan dengan baik beberapa kondisi agen 
> seperti tingkat kepercayaan, reputasi dan fasilitas di dalam agen judi online.
>  * *Memperhatikan Pros

[jira] [Deleted] (MTOMCAT-324) Ver la Película After 3 Almas Perdidas (2021) en Español Latin

2021-09-08 Thread Mark Thomas (Jira)


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

Mark Thomas deleted MTOMCAT-324:



> Ver la Película After 3 Almas Perdidas (2021) en Español Latin
> --
>
> Key: MTOMCAT-324
> URL: https://issues.apache.org/jira/browse/MTOMCAT-324
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>Reporter: Ver la Película After 3 Almas Perdidas (2021) en Español 
> Latin
>Assignee: Olivier Lamy
>Priority: Trivial
>
> *Ver la Película After 3 : Almas perdidas (2021) en Español Latino Online 
> Gratis, Ver After 3 : Almas perdidas online y descargar gratis, After 3 : 
> Almas perdidas online gratis, After 3 : Almas perdidas Película completa en 
> línea en Castellano, Latino, Chileno*
> Dónde ver online de After 3 : Almas perdidas gratis la película completa en 
> español latino o con subtitulada y en HD
> *Ver la Película ► [https://is.gd/8M9hjm|http://example.com]*
> *Ver la Película ► [https://is.gd/8M9hjm|http://example.com]***
> ver la película de After 3 : Almas perdidas
> plataformas :  Ver After 3 : Almas perdidas película completa en español 
> latino, After 3 : Almas perdidas (2021) película completa en Español Latino, 
> After 3 : Almas perdidas Drama, Romántico, Erótico sub español | Ver y 
> Descargar After 3 : Almas perdidas Películas Online Gratis en Español, Visita 
> la página oficial de After 3 : Almas perdidas de Disney para descubrir más 
> sobre la película online gratis en español HD, After 3 : Almas perdidas en 
> castellano o subtitulado.
> h2. Reseña de ‘After 3 : Almas perdidas’ es fácil en gracias a sus 
> servidores, rapidos y sin ads.
> *Ver After 3 : Almas perdidas online y descargar gratis*
> Las siguientes dos novelas de la serie de Todd vuelven a seguir las 
> complejidades de la relación de Tessa y Hardin, lo que significa que 
> Josephine Langford y Hero Fiennes Tiffin volverán a interpretar sus papeles. 
> La novela After Almas perdidas comienza después del final de suspenso de 
> After We Collided, donde Tessa se encuentra con su padre separado. Puede leer 
> un fragmento de la propaganda del libro a continuación. La vida de Tessa 
> cuando comienza a desmoronarse. Nada es lo que ella pensó que era. No sus 
> amigos. No su familia. La única persona en la que debería poder confiar, 
> Hardin, se enfurece cuando descubre el enorme secreto que ha estado 
> guardando. Y en lugar de ser comprensivo, recurre al sabotaje. Gran pelicula. 
> Lo puse en el podio justo después de la película Infinite. Aunque esta última 
> es una película de acción.
> A diferencia de otros finales de historias de amor, el historial de Anna Todd 
> sobre cómo termina cada libro nunca me deja con una sensación cálida y 
> confusa. De hecho, al final de After, Tessa deja a Hardin en el 
> estacionamiento de Blind Bob’s, optando por estar en la compañía de Zed. 
> Hardin luego pasa la mayor parte de After We Collided tratando de enmendar 
> las horribles decisiones que alejaron a Tessa. El segundo libro termina con 
> Hardin y Tessa saliendo juntos de un salón de tatuajes. Y en un vagabundo que 
> resulta ser el padre de Tessa. Es genial que podamos ver esta película gratis 
> en línea y sin límites.
> *After 3 : Almas perdidas online gratis*
> La trama de After Almas perdidas es dramática, pero muestra principalmente la 
> tensa dinámica entre Tessa y Hardin. Tessa intenta reconciliarse con su 
> padre, aunque Hardin le advierte contra esta idea y termina dejándolo 
> quedarse en el apartamento compartido de ella y Hardin. Tessa ve similitudes 
> entre su padre, que lucha contra la adicción, y el padre de Hardin, Ken, que 
> lucha con el alcohol y está separado de la madre de Hardin. El problema con 
> el padre de Tessa informa la trama de After Almas perdidas (After We Fell) y 
> las otras 850 páginas están llenas de drama de amistad, Tessa lucha con su 
> deseo de mudarse a Seattle y aún aferrarse a Hardin, y la pareja lucha con la 
> dinámica de su relación. Veo algunas similitudes con la serie Sex / Life 
> aquí. Ciertamente también has visto estas producciones de Netflix.
> *After 3 : Almas perdidas la Película completa en línea en Castellano, 
> Latino, Chileno*
> En defensa de Tessa, ve similitudes entre su padre y el propio padre de 
> Hardin, el canciller Scott. Si el Sr. Scott puede cambiar su vida, ¿por qué 
> no el Sr. Young? Como veremos más adelante, es porque el padre de Tessa está 
> metido en las drogas duras y está involucrado con algunas personas malas y 
> malas que no puede cambiar las cosas. Está metido demasiado.

[jira] [Deleted] (MTOMCAT-325) Ver la Película After 3 Almas Perdidas (2021) en Español Latin

2021-09-08 Thread Mark Thomas (Jira)


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

Mark Thomas deleted MTOMCAT-325:



> Ver la Película After 3 Almas Perdidas (2021) en Español Latin
> --
>
> Key: MTOMCAT-325
> URL: https://issues.apache.org/jira/browse/MTOMCAT-325
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>Reporter: Ver la Película After 3 Almas Perdidas (2021) en Español 
> Latin
>Assignee: Olivier Lamy
>Priority: Major
>
> *Ver la Película After 3 : Almas perdidas (2021) en Español Latino Online 
> Gratis, Ver After 3 : Almas perdidas online y descargar gratis, After 3 : 
> Almas perdidas online gratis, After 3 : Almas perdidas Película completa en 
> línea en Castellano, Latino, Chileno*
> Dónde ver online de After 3 : Almas perdidas gratis la película completa en 
> español latino o con subtitulada y en HD
> *Ver la Película ► https://is.gd/8M9hjm*
> *Ver la Película ►* *https://is.gd/8M9hjm*
> ver la película de After 3 : Almas perdidas
>  plataformas :  Ver After 3 : Almas perdidas película completa en español 
> latino, After 3 : Almas perdidas (2021) película completa en Español Latino, 
> After 3 : Almas perdidas Drama, Romántico, Erótico sub español | Ver y 
> Descargar After 3 : Almas perdidas Películas Online Gratis en Español, Visita 
> la página oficial de After 3 : Almas perdidas de Disney para descubrir más 
> sobre la película online gratis en español HD, After 3 : Almas perdidas en 
> castellano o subtitulado.
> h2. Reseña de ‘After 3 : Almas perdidas’ es fácil en gracias a sus 
> servidores, rapidos y sin ads.
> *Ver After 3 : Almas perdidas online y descargar gratis*
>  Las siguientes dos novelas de la serie de Todd vuelven a seguir las 
> complejidades de la relación de Tessa y Hardin, lo que significa que 
> Josephine Langford y Hero Fiennes Tiffin volverán a interpretar sus papeles. 
> La novela After Almas perdidas comienza después del final de suspenso de 
> After We Collided, donde Tessa se encuentra con su padre separado. Puede leer 
> un fragmento de la propaganda del libro a continuación. La vida de Tessa 
> cuando comienza a desmoronarse. Nada es lo que ella pensó que era. No sus 
> amigos. No su familia. La única persona en la que debería poder confiar, 
> Hardin, se enfurece cuando descubre el enorme secreto que ha estado 
> guardando. Y en lugar de ser comprensivo, recurre al sabotaje. Gran pelicula. 
> Lo puse en el podio justo después de la película Infinite. Aunque esta última 
> es una película de acción.
> A diferencia de otros finales de historias de amor, el historial de Anna Todd 
> sobre cómo termina cada libro nunca me deja con una sensación cálida y 
> confusa. De hecho, al final de After, Tessa deja a Hardin en el 
> estacionamiento de Blind Bob’s, optando por estar en la compañía de Zed. 
> Hardin luego pasa la mayor parte de After We Collided tratando de enmendar 
> las horribles decisiones que alejaron a Tessa. El segundo libro termina con 
> Hardin y Tessa saliendo juntos de un salón de tatuajes. Y en un vagabundo que 
> resulta ser el padre de Tessa. Es genial que podamos ver esta película gratis 
> en línea y sin límites.
> *After 3 : Almas perdidas online gratis*
>  La trama de After Almas perdidas es dramática, pero muestra principalmente 
> la tensa dinámica entre Tessa y Hardin. Tessa intenta reconciliarse con su 
> padre, aunque Hardin le advierte contra esta idea y termina dejándolo 
> quedarse en el apartamento compartido de ella y Hardin. Tessa ve similitudes 
> entre su padre, que lucha contra la adicción, y el padre de Hardin, Ken, que 
> lucha con el alcohol y está separado de la madre de Hardin. El problema con 
> el padre de Tessa informa la trama de After Almas perdidas (After We Fell) y 
> las otras 850 páginas están llenas de drama de amistad, Tessa lucha con su 
> deseo de mudarse a Seattle y aún aferrarse a Hardin, y la pareja lucha con la 
> dinámica de su relación. Veo algunas similitudes con la serie Sex / Life 
> aquí. Ciertamente también has visto estas producciones de Netflix.
> *After 3 : Almas perdidas la Película completa en línea en Castellano, 
> Latino, Chileno*
>  En defensa de Tessa, ve similitudes entre su padre y el propio padre de 
> Hardin, el canciller Scott. Si el Sr. Scott puede cambiar su vida, ¿por qué 
> no el Sr. Young? Como veremos más adelante, es porque el padre de Tessa está 
> metido en las drogas duras y está involucrado con algunas personas malas y 
> malas que no puede cambiar las cosas. Está metido demasiado. Y cuando la 
> madre de Tessa apa

Re: [VOTE] Release Apache Tomcat 10.0.11

2021-09-07 Thread Mark Thomas

On 06/09/2021 19:30, Mark Thomas wrote:


The proposed 10.0.11 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.0.11 (stable)


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


Mark

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



Re: svn commit: r49785 - in /dev/tomcat/tomcat-10/v10.0.11: ./ bin/ bin/embed/ src/

2021-09-07 Thread Mark Thomas

On 07/09/2021 08:20, Rémy Maucherat wrote:

On Tue, Sep 7, 2021 at 8:42 AM Konstantin Kolinko
 wrote:


пн, 6 сент. 2021 г. в 21:28, :


Author: markt
Date: Mon Sep  6 18:28:21 2021
New Revision: 49785

Log:
Upload 10.0.11 for voting

Added:





 dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.tar.gz   (with 
props)
 dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.tar.gz.sha512
 dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.zip   (with props)
 dev/tomcat/tomcat-10/v10.0.11/bin/apache-tomcat-10.0.11.zip.sha512


*.asc files are missing for apache-tomcat-10.0.11.tar.gz and
apache-tomcat-10.0.11.zip above.


This is a funny one. The build.xml is fine, there's no error building,
but the signature for these two files didn't happen. There's a bug
somewhere ...


Indeed. I can't see what it is though. The Ant build is, as far as I am 
aware, single threaded so everything should be sequential.


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

2021-09-06 Thread Mark Thomas

The proposed Apache Tomcat 10.0.11 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to jakarta.*

Applications that run on Tomcat 9 will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be 
placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory


The notable changes compared to 10.0.10 are:

- Add a UserDatabase implementation as a superset of the DataSourceRealm
  functionality.

- Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
  Commons Pool to 2.11.1

- Update the packaged version of the Tomcat Native Library to 1.2.31 to
  pick up Windows binaries built with OpenSSL 1.1.1l.

Along with lots of other bug fixes and improvements.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.11/

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

The tag is:
https://github.com/apache/tomcat/tree/10.0.11
c191bad5a0cd7f1606f573dd960d0b396aeb288d

The proposed 10.0.11 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 10.0.11 (stable)

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M5

2021-09-06 Thread Mark Thomas

On 06/09/2021 15:43, Mark Thomas wrote:

The proposed 10.1.0-M5 release is:
[ ] Broken - do not release
[X] Alpha - go ahead and release as 10.1.0-M5 (alpha)


Unit tests pass on Windows, Linux and MacOS with NIO and NIO2 with 
Tomcat Native 1.2.31.


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.1.0-M5

2021-09-06 Thread Mark Thomas

The proposed Apache Tomcat 10.1.0-M5 release is now available for
voting.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


The notable changes compared to 10.1.0-M4 are:

- Remove the deprecated APR/Native connector which includes the HTTP APR
  and the AJP APR connector. Also remove the Java interfaces to the
  APR/Native library that are not used by the OpenSSL integration for
  the NIO and NIO2 connectors.

- Add a UserDatabase implementation as a superset of the DataSourceRealm
  functionality.

- Update the internal fork of Apache Commons DBCP to 2.9.0 and Apache
  Commons Pool to 2.11.1


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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M4/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.0-M5
2a10c8d9110d7b1c7f526f3352648c6b19ba2c52


The proposed 10.1.0-M5 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 10.1.0-M5 (alpha)

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



Re: Tagging 10.1.0-M5 etc

2021-09-03 Thread Mark Thomas

On Tue, Aug 31, 2021 at 8:02 PM Mark Thomas  wrote:


Hi all,

Things are looking good for the September release. We do need the Tomcat
Native 1.2.31 vote to complete first (thanks for your vote Rémy). If you
have time to test with 1.2.31 your vote would be really helpful as we
only have 2 votes so far.

Assuming 1.2.31 passes, I'll complete the release then update the Tomcat
branches, test and then tag. If everything goes well, we should have
release votes running by the end of the week and hopefully a little sooner.


Sorry all. Two things caused a delay.

1. The Commons DBCP and Pool updates took a lot longer than I expected 
due to the large number of changes.


2. When I ran the unit tests on Mac OS I had a failure in the TLS tests. 
It took me a while to track down the root cause to a stray copy of the 
Tomcat test CA cert in the OpenSSL default cert list that meant a client 
cert was accepted (since OpenSSL recognised the CA) when it should have 
been rejected.


I'm now expecting to re-test and tag first thing 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 main updated: jarsToSkip += derby-*.jar

2021-09-03 Thread Mark Thomas

On 03/09/2021 15:02, Rémy Maucherat wrote:

On Fri, Sep 3, 2021 at 10:03 AM  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new e9cbd4c  jarsToSkip += derby-*.jar
e9cbd4c is described below

commit e9cbd4c2cdb958930fed1cfeabdd3e911fc8b1e6
Author: Mark Thomas 
AuthorDate: Fri Sep 3 09:02:05 2021 +0100

 jarsToSkip += derby-*.jar


Thanks, I always keep forgetting that ...


No worries. I only noticed it because I happened to see the stack traces 
related to the failed scan.


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



[ANN] Apache Tomcat Native 1.2.31 released

2021-09-02 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.2.31 stable.

The key features of this release are:
- Windows binaries built using OpenSSL 1.1.1l
- Fix an issue when building with OpenSSl 3.0.0

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: [VOTE][RESULT] Release Apache Tomcat Native 1.2.31

2021-09-01 Thread Mark Thomas

The following votes were cast:

Binding:
+1: markt, remm, isapir

No other votes were cast.

The vote therefore passes.

Thank you 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: Tagging 10.1.0-M5 etc

2021-09-01 Thread Mark Thomas

On 31/08/2021 21:44, Rémy Maucherat wrote:

On Tue, Aug 31, 2021 at 8:02 PM Mark Thomas  wrote:


Hi all,

Things are looking good for the September release. We do need the Tomcat
Native 1.2.31 vote to complete first (thanks for your vote Rémy). If you
have time to test with 1.2.31 your vote would be really helpful as we
only have 2 votes so far.

Assuming 1.2.31 passes, I'll complete the release then update the Tomcat
branches, test and then tag. If everything goes well, we should have
release votes running by the end of the week and hopefully a little sooner.


Ok. Should I backport the UserDatabase changes ? They are rather
independent of anything else.


No objection here.

Mark

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



Tagging 10.1.0-M5 etc

2021-08-31 Thread Mark Thomas

Hi all,

Things are looking good for the September release. We do need the Tomcat 
Native 1.2.31 vote to complete first (thanks for your vote Rémy). If you 
have time to test with 1.2.31 your vote would be really helpful as we 
only have 2 votes so far.


Assuming 1.2.31 passes, I'll complete the release then update the Tomcat 
branches, test and then tag. If everything goes well, we should have 
release votes running by the end of the week and hopefully a little sooner.


Mark

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



Re: [NOTICE] - Moving and Upgrading of Buildbot Jobs

2021-08-31 Thread Mark Thomas

On 31/08/2021 08:07, Gavin McDonald wrote:




Does the above mean that the migration includes necessary changes to
generate this output to nightlies.a.o instead? If so, that is great and
thanks for taking care of this. If not, what do we need to do?



Yes I can take care of the code changes needed.


Great. Many thanks.


Oh, is there an automatic process to remove old content from
nightlies.a.o? If not, we'll need to add one as we (well, I) currently
clean up old logs (the only dir that builds up over time) manually every
few months.



There will be a generic cleanup script that will likely delete old files
over $n days
old if your project folder is over $x GB. Details to be ironed out.

I think though that this is a hammer and not a scalpel and could have
undesired
effects on displayed output. So might be better to create your own cleanup
script
at a later date.


The hammer will be sufficient for our needs. It is only test logs that 
build up over time (assuming the same directory structure as the current 
jobs is retained) and deleting everything older than X days will be fine.



One last thing to iron out, where do you want your new config file to live,
in the new
SVN location [1] or the new Git location [2] ?

[1] - https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects
[2] - https://github.com/apache/infrastructure-bb2


I'm going to make a call on this and say git. The reasons are:

- Most of our repos have moved to git
- Using github means we have the option to edit the files via the web
  interface as well as the command line.


Finally, I have a ticket to track progress.

https://issues.apache.org/jira/browse/INFRA-22276

Let me know when I can go ahead.


Please feel free to proceed at your convenience. The CI builds provide a 
very helpful check on what we are doing but nothing in our process 
requires them.


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

2021-08-31 Thread Mark Thomas

On 26/08/2021 17:04, Mark Thomas wrote:

Version 1.2.31 includes the following changes compared to 1.2.30

- Build an issue when building with OpenSSL 3.0.0

- Clean up remaining reference to pkg-config

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

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


Tested on Linux (source) and Windows (binaries).

Mark

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

2021-08-26 Thread Mark Thomas

Version 1.2.31 includes the following changes compared to 1.2.30

- Build an issue when building with OpenSSL 3.0.0

- Clean up remaining reference to pkg-config

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

The Apache Tomcat Native 1.2.31 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.31
[2]
https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=7e16cd817767bfc1be9fd854728d97641928702f

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



Re: Embedded JDBC for the testsuite ?

2021-08-26 Thread Mark Thomas

On 26/08/2021 15:06, Rémy Maucherat wrote:

Hi,

Given there are components that use JDBC, they probably could use some
testsuite coverage. What would be the best option for a "real"
embedded JDBC DB for the Tomcat testsuite ? Derby ?


Derby is the one I thought of. If we needed a feature not present in 
Derby (seems unlikely) I'd look at h2 or hsqldb.


Mark

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



Re: OpenSSL security announcement - do we need a Tomcat Native release?

2021-08-26 Thread Mark Thomas




On 25/08/2021 09:08, Mark Thomas wrote:

Hi all,

OpenSSL have published a security announcement alongside the latest 
release:


https://www.openssl.org/news/secadv/20210824.txt

I'm trying to figure out if Tomcat Native is affected by these.

For CVE-2021-3711 it isn't clear to me if the issue relates to just 
stand-alone decryption or if any use of SM2 - including in a TLS cipher 
- is affected.


For CVE-2021-3712 I can't find any references in the Tomcat Native code 
to any of the functions named as potential ways to construct an 
ASN1_STRING without the NUL terminators.



Can anyone shed more light on CVE-2021-3711? We do have one fix related 
to building with OpenSSL 3.0.0 so it might be simpler to just do a 
release anyway.


Thoughts?


Give there have been no further comments on this, I am going to go ahead 
and tag 1.2.31 with a view to using that for the September release round 
for 10.1.x etc.


Mark

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



Re: OT: Parsing EC private keys in PEM format

2021-08-26 Thread Mark Thomas

On 25/08/2021 18:04, Christopher Schultz wrote:

Mark,

On 8/25/21 10:28, Mark Thomas wrote:

On 25/08/2021 15:10, Christopher Schultz wrote:

All,

I'm trying to do this without looking at the code which is in Tomcat 
because I'd like to release it separately and not have to worry about 
figuring out hos to get permission, etc.


It is ALv2 so the requirements are pretty minimal. You just need to 
include a copy of the ALv2, note you based it on Apache Tomcat and 
don;t use any ASF trademarks in your product name.


Hmm. I seem to recall asking someone if I could contribute your PEMFile 
stuff to the PostgreSQL JDBC driver project (they only support 
non-encrypted DER files directly) and the reply I got was something 
along the lines of "horrific copyright violation/IP theft/good luck 
finding all the original authors and getting their permission/etc." 
(paraphrasing).


Hmm. Odd. I wonder why they said that. Do you have a public reference to 
that conversation. Obviously, any potential IP issues are a concern.


Looking at the code, I'm struggling to see where the concern would come 
from.


The original contribution was from Emmanuel. Given his work on JSign I 
have no reason to think the contribution wasn't original.


The ASN.1 parser was written from scratch by me. There are comment 
references to various specifications but whatever copyright/license they 
are under has no bearing on the copyright/licensing of the 
implementation. (And most, if not all, are RFCs.)


The other commits are essentially cosmetic / refactoring.

If they wanted to relicense the code rather than use it under the ALv2 
then I can see how they might view that as potentially difficult 
although in this instance given all the people involved are Tomcat 
committers it would likely be fairly simple (assuming all the 
contributors were happy).


Mark

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



Re: OT: Parsing EC private keys in PEM format

2021-08-25 Thread Mark Thomas

On 25/08/2021 15:10, Christopher Schultz wrote:

All,

I'm trying to do this without looking at the code which is in Tomcat 
because I'd like to release it separately and not have to worry about 
figuring out hos to get permission, etc.


It is ALv2 so the requirements are pretty minimal. You just need to 
include a copy of the ALv2, note you based it on Apache Tomcat and don;t 
use any ASF trademarks in your product name.


I'm working on a piece of code which can load the following types of 
PEM-encoded DER files with private keys in them. Each is a different 
flavor of terrible.


BEGIN PRIVATE KEY (pkcs8, pretty easy)
BEGIN RSA PRIVATE KEY (RFC 3447/pkcs1, requires ASN.1)
BEGIN RSA PRIVATE KEY (with encryption)
BEGIN EC PRIVATE KEY (RFC 5915, requires ASN.1)
BEGIN ENCRYPTED PRIVATE KEY (also pkcs8)

I have completed the work on these:

BEGIN PRIVATE KEY
BEGIN RSA PRIVATE KEY
BEGIN RSA PRIVATE KEY (with encryption)

I'm now working on:

BEGIN EC PRIVATE KEY

I think I can get everything I need out of the ASN.1 structure of the 
file, but I'm getting caught up in the Java API for EC crypto.


In order to create an RSA private key, one need only assemble the 
various values required for the RSA key (e, n, etc.) and stick them into 
an RSAPrivateKeySpec object, then generate the key from the KeySpec.


For EC, however, you need what appears to be a whole menagerie of 
classes, many of which it's not clear how to construct.


Is there an easier way to do this? Shortcuts are fine: I'm not married 
to the idea of manually-parsing the ASN.1 structure and 
manually-building the Java objects required if the API already supports 
some sort of shortcut.


If there is *not* an easier way to do this, I'm wondering how to 
construct the following objects. Here is the code I have so far:


String algorithm = "EC"; // I know this from the file type
byte[] keybytes = ...; // These come from the ASN.1 structure
String curveOID = ...; // This comes from the ASN.1 stucture
byte[] paramBits = ...; // This also comes from the ASN.1 structure

Curve curve = getCurve(curveOID); // I have this, at least for the one 
curve I'm working with at the moment


ECField ecField = ???; // This should be a part of the curve definition?

EllipticCurve curve = new EllipticCurve(ecField, curve.getA(), 
curve.getB());


ECParameterSpec paramSpec = ???; // How to convert paramBits to this?

// This is the easy part
PrivateKey key = KeyFactory.getInstance(algorithm).generatePrivate(new 
ECPrivateKeySpec(new BigInteger(keybytes), paramSpec));


Is there a better way to get the curve definition (from e.g. the OID) 
than manually-building the ECField and EllipticCurve objects?


Sorry, I'd have to look at the Tomcat code to answer that. That isn't 
really any different to you looking yourself.


Mark

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



OpenSSL security announcement - do we need a Tomcat Native release?

2021-08-25 Thread Mark Thomas

Hi all,

OpenSSL have published a security announcement alongside the latest release:

https://www.openssl.org/news/secadv/20210824.txt

I'm trying to figure out if Tomcat Native is affected by these.

For CVE-2021-3711 it isn't clear to me if the issue relates to just 
stand-alone decryption or if any use of SM2 - including in a TLS cipher 
- is affected.


For CVE-2021-3712 I can't find any references in the Tomcat Native code 
to any of the functions named as potential ways to construct an 
ASN1_STRING without the NUL terminators.



Can anyone shed more light on CVE-2021-3711? We do have one fix related 
to building with OpenSSL 3.0.0 so it might be simpler to just do a 
release anyway.


Thoughts?

Mark

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



Re: OpenSSL using /lib64 rather than /lib

2021-08-23 Thread Mark Thomas

On 23/08/2021 09:45, Rainer Jung wrote:
I noticed the same - switch from lib to lib64 as the default library 
installation directory - when I recently built OpenSSL 3.0.0 beta2. It 
must be a change during the last 1-2 months between alpha16 and beta2).


Thanks for the confirmation.

How do you recommend we handle this? I know Gump is affected and I 
suspect Tomcat Native will be as well. I'd like to be able to build with 
OpenSSL 3.0.0 or 1.1.1 with minimal changes.


Should we try and change OpenSSL to use /lib or the dependent builds to 
look in /lib64 (or ideally /lib and /lib64 so either works). And how to 
do that?


Thanks,

Mark



Regards,

Rainer

Am 23.08.2021 um 10:35 schrieb Mark Thomas:

Hi,

I've noticed that both local and Gump builds of OpenSSL master have 
started using .../lib64 rather than .../lib for the shared libraries 
that are built. This is causing build problems - for example httpd 
looks in /lib


I'm not sure if something has changed in the build environments or in 
openssl.


Any idea a) what might have triggered this and b) the best way to 
handle it so the builds work?


Thanks,

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



OpenSSL using /lib64 rather than /lib

2021-08-23 Thread Mark Thomas

Hi,

I've noticed that both local and Gump builds of OpenSSL master have 
started using .../lib64 rather than .../lib for the shared libraries 
that are built. This is causing build problems - for example httpd looks 
in /lib


I'm not sure if something has changed in the build environments or in 
openssl.


Any idea a) what might have triggered this and b) the best way to handle 
it so the builds work?


Thanks,

Mark

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



Re: [tomcat] branch 8.5.x updated: Additional configuration required for JSign + DigiCert ONE on Java 7

2021-08-18 Thread Mark Thomas

On 18/08/2021 18:03, Christopher Schultz wrote:

Mark,

On 8/18/21 08:11, ma...@apache.org wrote:





 Additional configuration required for JSign + DigiCert ONE on Java 7





Ugh. I'm so glad this foolishness isn't required in Java 8 and later.

So we actually have to build 8.5 with Java 7? I think I had been using 
Java 8 to build it (oops). We should have -target 1.7 so we won't build 
anything that won't run on Java 7 even if built with Java 8... right?


Yes. But...

There are some API changes in the JRE (maybe ByteBuffer and/or Map) such 
that even if you compile with Java 8 and -target 1.7 you can see NSME.


I forget the exact details. I might have the wrong classes but I am 
fairly sure we have seen an issue here before.


One option would be to build with Java 11 and --release=7. That ensures 
the compilation is against the Java 7 API. The downside is it makes 
running the tests against Java 7 require a little more hoop jumping.


We could, potentially, do that for 9.0.x and 10.0.x as well.

Mark

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



Re: [tomcat] branch 8.5.x updated: Update to JSign 4.0 to remove dependency on client tools.

2021-08-18 Thread Mark Thomas

On 17/08/2021 23:33, Mark Thomas wrote:

On 17/08/2021 22:38, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
  new 7e7dbac  Update to JSign 4.0 to remove dependency on client 
tools.


Probably one for Emmanuel.

I'm trying to do a release build from 8.5.x with 1.7.0_80_x64 (Oracle) 
and I am getting the following error below on signing.


Any hints on how to fix this?


I enabled TLS debug logging which provided enough clues to figure out 
the problem. It was a cipher suite problem. Once I enabled the specific 
cipher suite that both DigiCert's service and Java 7 support then I was 
able to complete a release build with Java 7u80.


I need to test building on Linux and MacOS. I'll update BUILDING.txt 
once that testing is complete.


Mark

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



Re: [tomcat] branch 8.5.x updated: Update to JSign 4.0 to remove dependency on client tools.

2021-08-17 Thread Mark Thomas

On 17/08/2021 22:38, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
  new 7e7dbac  Update to JSign 4.0 to remove dependency on client tools.


Probably one for Emmanuel.

I'm trying to do a release build from 8.5.x with 1.7.0_80_x64 (Oracle) 
and I am getting the following error below on signing.


Any hints on how to fix this?

Thanks,

Mark


C:\asf-tomcat\build.xml:2295: Couldn't sign 
C:\asf-tomcat\output\dist\Uninstall.exe

at net.jsign.JsignTask.execute(JsignTask.java:183)
at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)

at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

at org.apache.tools.ant.Task.perform(Task.java:352)
at org.apache.tools.ant.Target.execute(Target.java:437)
at org.apache.tools.ant.Target.performTasks(Target.java:458)
at 
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1406)

at org.apache.tools.ant.Project.executeTarget(Project.java:1377)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)

at org.apache.tools.ant.Project.executeTargets(Project.java:1261)
at org.apache.tools.ant.Main.runBuild(Main.java:857)
at org.apache.tools.ant.Main.startAnt(Main.java:236)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:287)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
Caused by: net.jsign.SignerException: Couldn't sign 
C:\asf-tomcat\output\dist\Uninstall.exe

at net.jsign.SignerHelper.sign(SignerHelper.java:517)
at net.jsign.JsignTask.execute(JsignTask.java:181)
... 16 more
Caused by: net.jsign.bouncycastle.operator.RuntimeOperatorException: 
exception obtaining signature: java.security.GeneralSecurityException: 
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at 
net.jsign.bouncycastle.operator.jcajce.JcaContentSignerBuilder$1.getSignature(Unknown 
Source)
at 
net.jsign.bouncycastle.cms.SignerInfoGenerator.generate(Unknown Source)
at 
net.jsign.bouncycastle.cms.CMSSignedDataGenerator.generate(Unknown Source)
at 
net.jsign.bouncycastle.cms.CMSSignedDataGenerator.generate(Unknown Source)
at 
net.jsign.asn1.authenticode.AuthenticodeSignedDataGenerator.generate(AuthenticodeSignedDataGenerator.java:50)
at 
net.jsign.AuthenticodeSigner.createSignedData(AuthenticodeSigner.java:363)

at net.jsign.AuthenticodeSigner.sign(AuthenticodeSigner.java:334)
at net.jsign.SignerHelper.sign(SignerHelper.java:509)
... 17 more
Caused by: java.security.SignatureException: 
java.security.GeneralSecurityException: 
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at 
net.jsign.jca.SigningServiceSignature.engineSign(SigningServiceSignature.java:64)

at java.security.Signature$Delegate.engineSign(Signature.java:1205)
at java.security.Signature.sign(Signature.java:578)
... 25 more
Caused by: java.security.GeneralSecurityException: 
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at 
net.jsign.jca.DigiCertOneSigningService.sign(DigiCertOneSigningService.java:207)
at 
net.jsign.jca.SigningServiceSignature.engineSign(SigningServiceSignature.java:62)

... 27 more
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: 
handshake_failure

at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at 
sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979)
at 
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at 
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at 
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1092)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)

at net.jsign.jca.RESTClient.query(RESTClient.java:62)
at 

Re: [tomcat] branch main updated: Update to JSign 4.0 to remove dependency on client tools.

2021-08-17 Thread Mark Thomas

On 17/08/2021 21:08, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 16c684b  Update to JSign 4.0 to remove dependency on client tools.


Woot!

Once I managed to get wine working correctly on MacOS, I was able to 
build a complete 10.1.x release - including signed installer for Windows 
- on MacOS. :)


Wine on MacOs steps have been added to the wiki.

I'll backport the JSign 4 updates shortly.

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.70 available

2021-08-17 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.70.

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.70 is a bugfix and feature release. The notable 
changes compared to 8.5.69 include:


- Correct a regression in the previous release in the HTTP/2 flow
  control window management along with additional improvements to HTTP/2
  flow control

- Make the CorsFilter simpler to extend

- To avoid unnecessary cache revalidation, do not add an HTTP Expires
  header when setting adding an HTTP header of CacheControl: private

Along with lots of other bug fixes and improvements.

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



Re: [VOTE] Release Apache Tomcat 8.5.70

2021-08-16 Thread Mark Thomas

On 12/08/2021 12:20, jean-frederic clere wrote:

On 09/08/2021 22:05, Mark Thomas wrote:

[X] Stable - go ahead and release as 8.5.70


On fedora 34, I have the following failures:
+++
    [concat] Testsuites with failed tests:
    [concat] 
TEST-org.apache.catalina.valves.rewrite.TestResolverSSL.NIO.txt
    [concat] 
TEST-org.apache.catalina.valves.rewrite.TestResolverSSL.NIO2.txt

    [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO.txt
    [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO2.txt
    [concat] TEST-org.apache.tomcat.util.net.TestClientCertTls13.NIO.txt
    [concat] TEST-org.apache.tomcat.util.net.TestClientCertTls13.NIO2.txt
    [concat] TEST-org.apache.tomcat.util.net.TestCustomSsl.NIO.txt
    [concat] TEST-org.apache.tomcat.util.net.TestCustomSsl.NIO2.txt
+++
But that looks like a configuration problem... invalid certificate...


Various test certificates have expired.

To summarise (my recollection of) previous discussion on this:

- We could auto-generate these but there are concerns around entropy
  particularly on CI systems if we do this.

- We could generate certs with a longer expiry (currently 2 years). Two
  years was chosen as a balance between having to regenerate these too
  often, keeping up with changing requirements for certs and reducing
  damage in case someone is foolish enough to use the keys in
  production.

Overall, I'm happy with having to do this every two years or so.

I'll regenerate new ones. I'm about to go into a meeting but should have 
this down shortly afterwards.


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

2021-08-16 Thread Mark Thomas

The following votes were cast:

Binding:
+1: isapir, mturk, kkolinko, jfclere, schultz

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


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



Re: svn commit: r49514 - in /dev/tomcat/tomcat-8/v8.5.70: bin/ bin/embed/ bin/extras/ src/

2021-08-16 Thread Mark Thomas

On 16/08/2021 09:50, Rémy Maucherat wrote:

On Mon, Aug 16, 2021 at 9:32 AM Mark Thomas  wrote:


On 16/08/2021 08:19, ma...@apache.org wrote:

Author: markt
Date: Mon Aug 16 07:19:55 2021
New Revision: 49514

Log:
Sign 8.5.70 with the correct key


To be on the safe side, could someone other than me please validate that
the 8.5.70 release is now OpenPGP signed as expected.


It says it is signed with the right key.


Thanks for checking.

I'm still not entirely sure what happened on my laptop to create those 
new keys. I think I may have selected the wrong option when migrating 
from Enigmail to Thunderbird's built-in encryption and created new keys 
rather than importing the old ones.


I have reset the laptop (and the new Linux VM I used foe the 8.5.70 
build) to use the correct keys.


I'll proceed with the 8.5.70 release shortly.

Mark

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



Re: [NOTICE] - Moving and Upgrading of Buildbot Jobs

2021-08-16 Thread Mark Thomas

On 15/08/2021 09:44, Gavin McDonald wrote:




For those of you with nightly builds that use ci.apache.org/projects/* -
please note that this service is deprecated and will NOT be available going
forward. Instead, your jobs should be changed to upload to
https://nightlies.apache.org/$project/* instead. Please request if you want
your existing content migrated over otherwise we will not do so.


Hi Gavin,

One question about the above.

The Tomcat builds currently generate:
- code coverage reports
- docs
- test logs
- RAT output

to ci.a.o/projects/...

Does the above mean that the migration includes necessary changes to 
generate this output to nightlies.a.o instead? If so, that is great and 
thanks for taking care of this. If not, what do we need to do?


Either way, we don't need the old content migrated.

Oh, is there an automatic process to remove old content from 
nightlies.a.o? If not, we'll need to add one as we (well, I) currently 
clean up old logs (the only dir that builds up over time) manually every 
few months.


Thanks,

Mark

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



Re: svn commit: r49514 - in /dev/tomcat/tomcat-8/v8.5.70: bin/ bin/embed/ bin/extras/ src/

2021-08-16 Thread Mark Thomas

On 16/08/2021 08:19, ma...@apache.org wrote:

Author: markt
Date: Mon Aug 16 07:19:55 2021
New Revision: 49514

Log:
Sign 8.5.70 with the correct key


To be on the safe side, could someone other than me please validate that 
the 8.5.70 release is now OpenPGP signed as expected.


Thanks,

Mark

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



Re: openssl-3.0.0 test failures with 9.0.x (I have not checked the other branches)

2021-08-10 Thread Mark Thomas
On August 10, 2021 2:24:12 PM UTC, jean-frederic clere  
wrote:
>On 10/08/2021 14:56, Konstantin Kolinko wrote:



>> Looking at Apache Gump,
>> -  tomcat/10.1.x (main)  fails to compile
>> Apparently Gunp tries to build it with Java 8 instead of Java 11
>
>Well according to http://vmgump.apache.org/ the VM is for 
>java-8-openjdk, not sure how to get a Java11 VM.

I was in the middle of fixing that and got distracted. I'll need to remind 
myself how far I got with that.

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

2021-08-09 Thread Mark Thomas

The proposed Apache Tomcat 8.5.70 release is now available for voting.

Chris was having some difficulties before the weekend getting the 
release to build. He hasn't had time to get to the bottom of these 
issues and time is ticking on so I took a look. I had different issues 
on Windows but was still unable to complete the release. With the 
addition of JSign, we have the option to build a full release on Linux 
so I tried that and it was successful. If successful, this will be the 
first release for a very long time built on Linux.


Given the above, additional scrutiny on the release artefacts targetted 
at Windows would be welcome.


The notable changes compared to the 8.5.69 release are:

- Correct a regression in the previous release in the HTTP/2 flow
  control window management along with additional improvements to HTTP/2
  flow control

- Make the CorsFilter simpler to extend

- To avoid unnecessary cache revalidation, do not add an HTTP Expires
  header when setting adding an HTTP header of CacheControl: private

Along with lots of other bug fixes and improvements.

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

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

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

The tag is:
https://github.com/apache/tomcat/tree/8.5.70
3d2e8b1964d4dff3c0656618edc0b09d0d5634b8

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

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



[ANN] Apache Tomcat 10.1.0-M4 (alpha) available

2021-08-07 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.0-M4 (alpha).

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.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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


- The minimum Java version has been increased to Java 11 to align with
  the plans for the Jakarta EE 10 platform

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Enable EL lambda expressions to be coerced to functional interfaces.
  This is an implementation of a proposed extension to the Jakarta
  Expression Language specification.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.1-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: [VOTE][RESULT] Release Apache Tomcat 10.1.0-M4

2021-08-06 Thread Mark Thomas

The following votes were cast:

Binding:
+1: remm, jfclere, kolinko

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark



On 03/08/2021 21:21, Mark Thomas wrote:

The proposed Apache Tomcat 10.1.0-M4 release is now available for
voting.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


The notable changes compared to 10.1.0-M2 are:

- The minimum Java version has been increased to Java 11 to align with
   the plans for the Jakarta EE 10 platform

- Correct a regression in the previous release in the HTTP/2 flow
   control window management

- Enable EL lambda expressions to be coerced to functional interfaces.
   This is an implementation of a proposed extension to the Jakarta
   Expression Language specification.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M4/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.0-M4
e706972942e2c342e4a37baf5e2596f11e8a0e94

The proposed 10.1.0-M4 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 10.1.0-M4 (alpha)

-
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



[ANN] Apache Tomcat 10.0.10 available

2021-08-06 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.10.

This release is targeted at Jakarta EE 9.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


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.

The notable changes compared to 10.0.8 include:

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Correct a regression the could cause some TLS connections to hang when
  using NIO

- Use of GraalVM native images no longer automatically disables JMX
  support.

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: [VOTE][RESULT] Release Apache Tomcat 10.0.10

2021-08-05 Thread Mark Thomas

The following votes were cast:

Binding:
+1: isapir, remm, markt

No other votes were cast.

The vote therefore passes.

Thank you to everyone who contributed to this release.

Mark



On 30/07/2021 12:18, Mark Thomas wrote:

The proposed Apache Tomcat 10.0.10 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to 
jakarta.*


Applications that run on Tomcat 9 will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be 
placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory


The notable changes compared to 10.0.8 are:

- Correct a regression in the previous release in the HTTP/2 flow
   control window management

- Correct a regression the could cause some TLS connections to hang when
   using NIO

- Use of GraalVM native images no longer automatically disables JMX
   support.

Along with lots of other bug fixes and improvements.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.10/

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

The tag is:
https://github.com/apache/tomcat/tree/10.0.10
74314100023abe6d83bac842f7ef24b9d51e811f

The proposed 10.0.10 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 10.0.10 (stable)

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

2021-08-03 Thread Mark Thomas

The proposed Apache Tomcat 10.1.0-M4 release is now available for
voting.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


The notable changes compared to 10.1.0-M2 are:

- The minimum Java version has been increased to Java 11 to align with
  the plans for the Jakarta EE 10 platform

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Enable EL lambda expressions to be coerced to functional interfaces.
  This is an implementation of a proposed extension to the Jakarta
  Expression Language specification.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M4/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.0-M4
e706972942e2c342e4a37baf5e2596f11e8a0e94

The proposed 10.1.0-M4 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 10.1.0-M4 (alpha)

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

2021-08-03 Thread Mark Thomas

On 30/07/2021 12:18, Mark Thomas wrote:


The proposed 10.0.10 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.0.10 (stable)


Tests pass for NIO, NIO2 and APR/Native with Tomcat Native 1.2.30 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][CANCELLED] Release Apache Tomcat 10.1.0-M3

2021-08-03 Thread Mark Thomas
I'm cancelling the vote due to a regression. The Java 8 -> Java 11 
changes broke WebSocket due to a missing "!".


I'll tag M4 shortly.

Mark


On 29/07/2021 16:37, Mark Thomas wrote:

The proposed Apache Tomcat 10.1.0-M3 release is now available for
voting.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


The notable changes compared to 10.1.0-M2 are:

- The minimum Java version has been increased to Java 11 to align with
   the plans for the Jakarta EE 10 platform

- Correct a regression in the previous release in the HTTP/2 flow
   control window management

- Enable EL lambda expressions to be coerced to functional interfaces.
   This is an implementation of a proposed extension to the Jakarta
   Expression Language specification.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M3/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.0-M3
8778a44d6323c1066237043a89ab2f36696916b1

The proposed 10.1.0-M3 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 10.1.0-M3 (alpha)

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

2021-08-02 Thread Mark Thomas

Hi Rainer,

I see the same thing.

My Java 11 cleanup is the obvious likely candidate for the root cause. I 
can dig into this some more tomorrow. Looks like we'll need an M4 release.


Mark


On 03/08/2021 00:12, Rainer Jung wrote:

Hi there,

is anyone able to run he websockets examples? For instance the "echo" 
example? I immediately get "Info: WebSocket connection closed, Code: 
1006" and a 404 response. This happened on a self-compiled installation 
on Linux but also on an extracted binary Windows 64 Bits download from 
the voting site.


Could it be, that the registration of the endpoints is somehow broken?

The example works in 10.0.10 using the same Java 11 installation that I 
used to test 10.1.0.


Thanks and regards,

Rainer

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

2021-07-30 Thread Mark Thomas

The proposed Apache Tomcat 10.0.10 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to jakarta.*

Applications that run on Tomcat 9 will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be 
placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory


The notable changes compared to 10.0.8 are:

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Correct a regression the could cause some TLS connections to hang when
  using NIO

- Use of GraalVM native images no longer automatically disables JMX
  support.

Along with lots of other bug fixes and improvements.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.10/

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

The tag is:
https://github.com/apache/tomcat/tree/10.0.10
74314100023abe6d83bac842f7ef24b9d51e811f

The proposed 10.0.10 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 10.0.10 (stable)

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



[VOTE][CANCELLED] Release Apache Tomcat 10.0.9

2021-07-30 Thread Mark Thomas

Vote cancelled due to
https://bz.apache.org/bugzilla/show_bug.cgi?id=65476

The fix has already been applied. A new tag and vote will follow shortly.

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

2021-07-29 Thread Mark Thomas

On 29/07/2021 20:07, Mark Thomas wrote:


The proposed 10.0.9 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.0.9 (stable)


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


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

2021-07-29 Thread Mark Thomas

The proposed Apache Tomcat 10.0.9 release is now available for
voting.

Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
package for all the specification APIs has changed from javax.* to jakarta.*

Applications that run on Tomcat 9 will not run on Tomcat 10 without 
changes. Java EE applications designed for Tomcat 9 and earlier may be 
placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory


The notable changes compared to 10.0.8 are:

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Correct a regression the could cause some TLS connections to hang when
  using NIO

- Use of GraalVM native images no longer automatically disables JMX
  support.

Along with lots of other bug fixes and improvements.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.9/

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

The tag is:
https://github.com/apache/tomcat/tree/10.0.9
5a10f281b5f09e1f73572f753f34ce7a1248763d

The proposed 10.0.9 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 10.0.9 (stable)

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M3

2021-07-29 Thread Mark Thomas

On 29/07/2021 15:37, Mark Thomas wrote:


The proposed 10.1.0-M3 release is:
[ ] Broken - do not release
[X] Alpha - go ahead and release as 10.1.0-M3 (alpha)


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


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

2021-07-29 Thread Mark Thomas

The proposed Apache Tomcat 10.1.0-M3 release is now available for
voting.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory.


The notable changes compared to 10.1.0-M2 are:

- The minimum Java version has been increased to Java 11 to align with
  the plans for the Jakarta EE 10 platform

- Correct a regression in the previous release in the HTTP/2 flow
  control window management

- Enable EL lambda expressions to be coerced to functional interfaces.
  This is an implementation of a proposed extension to the Jakarta
  Expression Language specification.

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

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M3/

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

The tag is:
https://github.com/apache/tomcat/tree/10.1.0-M3
8778a44d6323c1066237043a89ab2f36696916b1

The proposed 10.1.0-M3 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 10.1.0-M3 (alpha)

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



Re: [tomcat] branch main updated: The minimum Java version for the Jakarta 10 platform will be Java 11

2021-07-27 Thread Mark Thomas

On 27/07/2021 16:14, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 5f41348  The minimum Java version for the Jakarta 10 platform will be 
Java 11
5f41348 is described below

commit 5f4134894a3744647a4671faa4140555f1013abc
Author: Mark Thomas 
AuthorDate: Tue Jul 27 16:13:54 2021 +0100

 The minimum Java version for the Jakarta 10 platform will be Java 11


I'm expecting lots of CI stuff to start breaking. I'll fix it as I see it.

Mark

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



Re: Tagging next release

2021-07-27 Thread Mark Thomas

On 27/07/2021 04:17, Christopher Schultz wrote:

Mark,

On 7/23/21 09:40, Mark Thomas wrote:

Hi all,

Partly due to the couple of regressions that have emerged this month, 
I'd like to aim to get the next set of releases out closer to the 
start of August than the middle.


With that in mind I'll be starting release prep shortly with a view to 
tagging around the middle of next week and starting the release vote 
towards the end of next week.


The 8.5.x branch looks like it's got fewer big fixes than 10.x and 9.x, 
but I'll be available to tag+vote 8.5.x as early this weekend. Any 
reason to delay to the end of next week for the vote, rather than 
starting at the beginning of the month (e.g. Monday)?


I'm planning on tagging later this week.

BZ 65460 is a regression that could cause issues for users making use of 
HTTP/2.


Mark

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



Tagging next release

2021-07-23 Thread Mark Thomas

Hi all,

Partly due to the couple of regressions that have emerged this month, 
I'd like to aim to get the next set of releases out closer to the start 
of August than the middle.


With that in mind I'll be starting release prep shortly with a view to 
tagging around the middle of next week and starting the release vote 
towards the end of next week.


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-9.0.x

2021-07-21 Thread Mark Thomas

On 21/07/2021 18:45, build...@apache.org wrote:

The Buildbot has detected a new failure on builder tomcat-9.0.x while building 
tomcat. Full details are available at:
 https://ci.apache.org/builders/tomcat-9.0.x/builds/78

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9.0-commit' 
triggered this build
Build Source Stamp: [branch 9.0.x] f5146f694698b3b53cdb19e940bc03d862caa33f
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1


https://ci.apache.org/projects/tomcat/tomcat-9.0.x/logs/78/TEST-org.apache.tomcat.websocket.TestWsWebSocketContainer.NIO.txt

Logs show system clock jumping backwards:

21-Jul-2021 17:10:08.556 INFO [main] ...
21-Jul-2021 17:09:57.804 INFO [main] ...

WebSocket session expiry reported to take -10 seconds.

I'm not planning to protect Tomcat against this sort of thing. I suspect 
there are a few places where we'd be unable to do so anyway.


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   >