[GitHub] [tomcat] markt-asf closed pull request #558: It is time to stop using absolute redirects

[GitBox]

markt-asf closed pull request #558: It is time to stop using absolute redirects
URL: https://github.com/apache/tomcat/pull/558


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [tomcat] markt-asf commented on pull request #558: It is time to stop using absolute redirects

[GitBox]

markt-asf commented on PR #558:
URL: https://github.com/apache/tomcat/pull/558#issuecomment-1286536223

   `useRelativeRedirects` is already `true` by default. However, the Servlet 
specification *requires* (see section 5.5) that Tomcat uses absolute redirects. 
Therefore, if `STRICT_SERVLET_COMPLIANCE` is `true`, absolute redirects are 
used.
   Note that, generally, the only reason to enable `STRICT_SERVLET_COMPLIANCE` 
is to pass the TCK. In normal production usage I'd expect this to be `false`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[Bug 66318] Set multiple domain names for one address，In Windows 10 OS. AbstractProcessor.populateRequestAttributeRemoteHost aways get wrong host

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66318

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 OS||All
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas  ---
Bugzilla is not a support forum. Please use the users mailing list.

https://tomcat.apache.org/lists.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 66318] New: Set multiple domain names for one address，In Windows 10 OS. AbstractProcessor.populateRequestAttributeRemoteHost aways get wrong host

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66318

Bug ID: 66318
   Summary: Set multiple domain names for one address，In Windows
10 OS.
AbstractProcessor.populateRequestAttributeRemoteHost
aways get wrong host
   Product: Tomcat 9
   Version: unspecified
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: xyzhu88y...@gmail.com
  Target Milestone: -

I set multiple domain names for one address.
like this:

127.0.0.1 tongtech.com
127.0.0.1 tong.com

when call tongtech.com the method
AbstractProcessor.populateRequestAttributeRemoteHost get me tong.com

when call tong.com the method
AbstractProcessor.populateRequestAttributeRemoteHost get me tongtech.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] eperez commented on pull request #558: It is time to stop using absolute redirects

[GitBox]

eperez commented on PR #558:
URL: https://github.com/apache/tomcat/pull/558#issuecomment-1286470026

   > Why? Is there a reason or a source you can refer to?
   
   It has passed some years now since this design mistake was fixed: 
https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2
   Keeping the old default just creates problems.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [tomcat] aooohan commented on pull request #558: It is time to stop using absolute redirects

[GitBox]

aooohan commented on PR #558:
URL: https://github.com/apache/tomcat/pull/558#issuecomment-1286369013

   Why? Is there a reason or a source you can refer to?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [tomcat] aooohan commented on a diff in pull request #556: Note that maxHttpHeaderSize always allocates the max size

[GitBox]

aooohan commented on code in PR #556:
URL: https://github.com/apache/tomcat/pull/556#discussion_r1001286110


##
webapps/docs/config/http.xml:
##
@@ -525,6 +525,11 @@
   the request line, header names and header values. If not specified, this
   attribute is set to the value of the maxHttpHeaderSize
   attribute.
+  If you see "Request header is too large" errors you can increase this,
+  but be aware that Tomcat will allocate the full amount you specify for
+  every request. For example, if you specify a maxHttpRequestHeaderSize of
+  1 MB and your application handles 100 concurrent requests, you will see
+  100 MB of heap consumed by request headers.

Review Comment:
   It doesn't affect the understanding, but it's not quite accurate, the buffer 
will actually be larger than 100MB due to some additional margins being taken 
into account



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

Buildbot success in on tomcat-10.1.x

[buildbot]

Build status: Build succeeded!
Worker used: bb2_worker2_ubuntu
URL: https://ci2.apache.org/#builders/44/builds/551
Blamelist: Mark Thomas , lihan 
Build Text: build successful
Status Detected: restored build
Build Source Stamp: [branch 10.1.x] 4defd829c3044358f4a7746ede4248e30d35d73e


Steps:

  worker_preparation: 0

  git: 0

  shell: 0

  shell_1: 0

  shell_2: 0

  shell_3: 0

  shell_4: 0

  shell_5: 0

  compile: 1

  shell_6: 0

  shell_7: 0

  shell_8: 0

  shell_9: 0

  Rsync docs to nightlies.apache.org: 0

  shell_10: 0

  Rsync RAT to nightlies.apache.org: 0

  compile_1: 1

  shell_11: 0

  Rsync Logs to nightlies.apache.org: 0


-- ASF Buildbot


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

[tomcat] branch 8.5.x updated: Populate min Java version at build time

[markt]

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 d82e231a89 Populate min Java version at build time
d82e231a89 is described below

commit d82e231a89ec8e75faf7ce4ba0b980ae5cab217a
Author: Mark Thomas 
AuthorDate: Thu Oct 20 18:57:33 2022 +0100

Populate min Java version at build time
---
 RUNNING.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/RUNNING.txt b/RUNNING.txt
index 5e9faebbc5..09384ccdd2 100644
--- a/RUNNING.txt
+++ b/RUNNING.txt
@@ -20,16 +20,16 @@
 ===
 
 Apache Tomcat @VERSION_MAJOR_MINOR@ requires a Java Standard Edition Runtime
-Environment (JRE) version 7 or later.
+Environment (JRE) version @MIN_JAVA_VERSION@ or later.
 
 =
-Running With JRE 7 Or Later
+Running With JRE @MIN_JAVA_VERSION@ Or Later
 =
 
 (1) Download and Install a Java SE Runtime Environment (JRE)
 
 (1.1) Download a Java SE Runtime Environment (JRE),
-  release version 7 or later, from
+  release version @MIN_JAVA_VERSION@ or later, from
   http://www.oracle.com/technetwork/java/javase/downloads/index.html
 
 (1.2) Install the JRE according to the instructions included with the


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

[tomcat] branch 9.0.x updated: Populate min Java version at build time

[markt]

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

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 9d21c29144 Populate min Java version at build time
9d21c29144 is described below

commit 9d21c29144820ed421fc38f6fb6569c91b07a2c6
Author: Mark Thomas 
AuthorDate: Thu Oct 20 18:57:33 2022 +0100

Populate min Java version at build time
---
 RUNNING.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/RUNNING.txt b/RUNNING.txt
index 58ceedda98..09384ccdd2 100644
--- a/RUNNING.txt
+++ b/RUNNING.txt
@@ -20,16 +20,16 @@
 ===
 
 Apache Tomcat @VERSION_MAJOR_MINOR@ requires a Java Standard Edition Runtime
-Environment (JRE) version 8 or later.
+Environment (JRE) version @MIN_JAVA_VERSION@ or later.
 
 =
-Running With JRE 8 Or Later
+Running With JRE @MIN_JAVA_VERSION@ Or Later
 =
 
 (1) Download and Install a Java SE Runtime Environment (JRE)
 
 (1.1) Download a Java SE Runtime Environment (JRE),
-  release version 8 or later, from
+  release version @MIN_JAVA_VERSION@ or later, from
   http://www.oracle.com/technetwork/java/javase/downloads/index.html
 
 (1.2) Install the JRE according to the instructions included with the


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

[tomcat] branch main updated (d95b769b4f -> d27c63055a)

[markt]

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 d95b769b4f Fix Javadoc related build failure when building with Java 19
 add d27c63055a Populate min Java version at build time

No new revisions were added by this update.

Summary of changes:
 RUNNING.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


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

[tomcat] branch 10.1.x updated: Populate min Java version at build time

[markt]

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

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


The following commit(s) were added to refs/heads/10.1.x by this push:
 new 4defd829c3 Populate min Java version at build time
4defd829c3 is described below

commit 4defd829c3044358f4a7746ede4248e30d35d73e
Author: Mark Thomas 
AuthorDate: Thu Oct 20 18:57:33 2022 +0100

Populate min Java version at build time
---
 RUNNING.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/RUNNING.txt b/RUNNING.txt
index 5011bc9bae..0adb82c6da 100644
--- a/RUNNING.txt
+++ b/RUNNING.txt
@@ -20,16 +20,16 @@
 ===
 
 Apache Tomcat @VERSION_MAJOR_MINOR@ requires a Java Standard Edition Runtime
-Environment (JRE) version 8 or later.
+Environment (JRE) version @MIN_JAVA_VERSION@ or later.
 
 =
-Running With JRE 8 Or Later
+Running With JRE @MIN_JAVA_VERSION@ Or Later
 =
 
 (1) Download and Install a Java SE Runtime Environment (JRE)
 
 (1.1) Download a Java SE Runtime Environment (JRE),
-  release version 8 or later, from
+  release version @MIN_JAVA_VERSION@ or later, from
   http://www.oracle.com/technetwork/java/javase/downloads/index.html
 
 (1.2) Install the JRE according to the instructions included with the


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

Re: [DISCUSS] EOL date for 8.5.x

[Coty Sutherland]

On Fri, Oct 7, 2022 at 5:28 AM Mark Thomas  wrote:

> Hi all,
>
> I don't think there is a need to make a decision on this quickly, but
> based on past experience and the current discussions about Jakarta EE 11
> I think this is something we need to start thinking about.
>
> Some key facts:
>
> - Tomcat 7.0.x reached EOL on 31 March 2021
> - EOL dates for major versions tend to be 3-4 years apart
> - We aim to support 3 major versions in parallel - currently 8.5.x,
>9.0.x and 10.1.x.
> - Tomcat 11 will implement Jakarta EE 11
> - Current Jakarta EE discussions are around a release in ~1 year
> - Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared
>stable
>
> Based on the above I think EOL for 8.5.x should be either 31 March 2024
> or 30 Sept 2024 depending on when we think Jakarta EE 11 will be released.
>
> Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is
> probably the more likely. However, it is much easier to delay an EOL
> date than to bring to bring it forward so my current thinking is to
> announce 31 March 2024 as the EOL date for 8.5.x and keep in mind that
> we can extend that if we want to.
>
> Thoughts?
>

+1 for 31 March 2024.

Buildbot failure in on tomcat-10.1.x

[buildbot]

Build status: BUILD FAILED: failed compile (failure)
Worker used: bb2_worker2_ubuntu
URL: https://ci2.apache.org/#builders/44/builds/550
Blamelist: Mark Thomas , lihan 
Build Text: failed compile (failure)
Status Detected: new failure
Build Source Stamp: [branch 10.1.x] 11807d6958125b96c976bad4f7791c9cb7ac16be


Steps:

  worker_preparation: 0

  git: 0

  shell: 0

  shell_1: 0

  shell_2: 0

  shell_3: 0

  shell_4: 0

  shell_5: 0

  compile: 1

  shell_6: 0

  shell_7: 0

  shell_8: 0

  shell_9: 0

  Rsync docs to nightlies.apache.org: 0

  shell_10: 0

  Rsync RAT to nightlies.apache.org: 0

  compile_1: 2

  shell_11: 0

  Rsync Logs to nightlies.apache.org: 0


-- ASF Buildbot


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

Re: [DISCUSS] EOL date for 8.5.x

[Han Li]

> 2022年10月20日 17:01，Rémy Maucherat  写道：
> 
> On Fri, Oct 7, 2022 at 11:28 AM Mark Thomas  > wrote:
>> 
>> Hi all,
>> 
>> I don't think there is a need to make a decision on this quickly, but
>> based on past experience and the current discussions about Jakarta EE 11
>> I think this is something we need to start thinking about.
>> 
>> Some key facts:
>> 
>> - Tomcat 7.0.x reached EOL on 31 March 2021
>> - EOL dates for major versions tend to be 3-4 years apart
>> - We aim to support 3 major versions in parallel - currently 8.5.x,
>> 9.0.x and 10.1.x.
>> - Tomcat 11 will implement Jakarta EE 11
>> - Current Jakarta EE discussions are around a release in ~1 year
>> - Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared
>> stable
>> 
>> Based on the above I think EOL for 8.5.x should be either 31 March 2024
>> or 30 Sept 2024 depending on when we think Jakarta EE 11 will be released.
>> 
>> Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is
>> probably the more likely. However, it is much easier to delay an EOL
>> date than to bring to bring it forward so my current thinking is to
>> announce 31 March 2024 as the EOL date for 8.5.x and keep in mind that
>> we can extend that if we want to.
>> 
>> Thoughts?
> 
> My slides said Tomcat 8.5 will be EOL when Tomcat 11 is released, so
> it seems that was the plan all along.
> So easy +1 :)
> 
> About the exact date, I think it is ok to set a date even if Tomcat 11
> happens to slip, Tomcat 9.0 is there.
+1

 BTW, I'm fed up with the limitations of JDK7 and I am  looking forward to JDK8 
as the minimum version to be maintained, as soon as possible so that it's a bit 
easier when back-ported.  : P : P

Han

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

[Bug 66317] AccessControlException on EL 5.0

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66317

Han Li  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Han Li  ---
Thanks for the PR.

Fixed in:
11.0.x for 11.0.0-M1 onwoards
10.1.x for 10.1.2 onwards

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] aooohan closed pull request #557: Fix for Lambda coercion security manager missing privileges

[GitBox]

aooohan closed pull request #557: Fix for Lambda coercion security manager 
missing privileges
URL: https://github.com/apache/tomcat/pull/557


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[tomcat] branch 9.0.x updated: Fix Javadoc related build failure when building with Java 19

[markt]

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

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 1d3e328723 Fix Javadoc related build failure when building with Java 19
1d3e328723 is described below

commit 1d3e328723b6ac4ac1ddb97210a68e294903dc30
Author: Mark Thomas 
AuthorDate: Thu Oct 20 15:01:21 2022 +0100

Fix Javadoc related build failure when building with Java 19
---
 java/javax/el/ELResolver.java| 12 
 java/javax/servlet/jsp/el/ScopedAttributeELResolver.java |  9 +
 java/javax/servlet/jsp/tagext/JspFragment.java   |  7 +++
 3 files changed, 28 insertions(+)

diff --git a/java/javax/el/ELResolver.java b/java/javax/el/ELResolver.java
index 0e438ec310..a43425eee3 100644
--- a/java/javax/el/ELResolver.java
+++ b/java/javax/el/ELResolver.java
@@ -29,6 +29,9 @@ public abstract class ELResolver {
 public static final String RESOLVABLE_AT_DESIGN_TIME = 
"resolvableAtDesignTime";
 
 /**
+ * Obtain the value of the given property on the given object using the
+ * given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be returned
@@ -65,6 +68,9 @@ public abstract class ELResolver {
 }
 
 /**
+ * Obtain the type of the given property on the given object using the 
given
+ * context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose type is to be returned
@@ -82,6 +88,9 @@ public abstract class ELResolver {
 Object property);
 
 /**
+ * Set the value of the given property on the given object using the given
+ * context.
+ *
  * @param context  The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be set
@@ -102,6 +111,9 @@ public abstract class ELResolver {
 Object property, Object value);
 
 /**
+ * Determine if the given property on the given object is read-only using
+ * the given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property to be checked for read only status
diff --git a/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java 
b/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
index b5481add86..6f709b3359 100644
--- a/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
+++ b/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
@@ -31,6 +31,8 @@ import javax.servlet.jsp.JspContext;
 import javax.servlet.jsp.PageContext;
 
 /**
+ * An ELResolver for working with JSP scoped attributes which may have page,
+ * request, session or application scope.
  *
  * @since JSP 2.1
  */
@@ -50,6 +52,13 @@ public class ScopedAttributeELResolver extends ELResolver {
 AST_IDENTIFIER_KEY = key;
 }
 
+/**
+ * Default constructor.
+ */
+public ScopedAttributeELResolver() {
+super();
+}
+
 @Override
 public Object getValue(ELContext context, Object base, Object property) {
 Objects.requireNonNull(context);
diff --git a/java/javax/servlet/jsp/tagext/JspFragment.java 
b/java/javax/servlet/jsp/tagext/JspFragment.java
index 9faf8d023f..16eee7cb32 100644
--- a/java/javax/servlet/jsp/tagext/JspFragment.java
+++ b/java/javax/servlet/jsp/tagext/JspFragment.java
@@ -54,6 +54,13 @@ import javax.servlet.jsp.JspException;
  */
 public abstract class JspFragment {
 
+/**
+ * Default constructor.
+ */
+public JspFragment() {
+// NO-OP by default
+}
+
 /**
  * Executes the fragment and directs all output to the given Writer,
  * or the JspWriter returned by the getOut() method of the JspContext


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

[GitHub] [tomcat] aooohan commented on pull request #557: Fix for Lambda coercion security manager missing privileges

[GitBox]

aooohan commented on PR #557:
URL: https://github.com/apache/tomcat/pull/557#issuecomment-1285610031

   Thank for the PR.
   
   I applied this manually so I could:
- add a change log entry
- slightly optimize code writing
   
   Fixed in:
   - 11.0.x for 11.0.0-M1 onwoards
   - 10.1.x for 10.1.2 onwards
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[tomcat] branch 8.5.x updated: Fix Javadoc related build failure when building with Java 19

[markt]

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 70a07e03cd Fix Javadoc related build failure when building with Java 19
70a07e03cd is described below

commit 70a07e03cd6f8fdee68c027f3c4f47c234d6d4d6
Author: Mark Thomas 
AuthorDate: Thu Oct 20 15:01:21 2022 +0100

Fix Javadoc related build failure when building with Java 19
---
 java/javax/el/ELResolver.java| 12 
 java/javax/servlet/jsp/el/ScopedAttributeELResolver.java |  9 +
 java/javax/servlet/jsp/tagext/JspFragment.java   |  7 +++
 3 files changed, 28 insertions(+)

diff --git a/java/javax/el/ELResolver.java b/java/javax/el/ELResolver.java
index 0e438ec310..a43425eee3 100644
--- a/java/javax/el/ELResolver.java
+++ b/java/javax/el/ELResolver.java
@@ -29,6 +29,9 @@ public abstract class ELResolver {
 public static final String RESOLVABLE_AT_DESIGN_TIME = 
"resolvableAtDesignTime";
 
 /**
+ * Obtain the value of the given property on the given object using the
+ * given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be returned
@@ -65,6 +68,9 @@ public abstract class ELResolver {
 }
 
 /**
+ * Obtain the type of the given property on the given object using the 
given
+ * context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose type is to be returned
@@ -82,6 +88,9 @@ public abstract class ELResolver {
 Object property);
 
 /**
+ * Set the value of the given property on the given object using the given
+ * context.
+ *
  * @param context  The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be set
@@ -102,6 +111,9 @@ public abstract class ELResolver {
 Object property, Object value);
 
 /**
+ * Determine if the given property on the given object is read-only using
+ * the given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property to be checked for read only status
diff --git a/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java 
b/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
index b5481add86..6f709b3359 100644
--- a/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
+++ b/java/javax/servlet/jsp/el/ScopedAttributeELResolver.java
@@ -31,6 +31,8 @@ import javax.servlet.jsp.JspContext;
 import javax.servlet.jsp.PageContext;
 
 /**
+ * An ELResolver for working with JSP scoped attributes which may have page,
+ * request, session or application scope.
  *
  * @since JSP 2.1
  */
@@ -50,6 +52,13 @@ public class ScopedAttributeELResolver extends ELResolver {
 AST_IDENTIFIER_KEY = key;
 }
 
+/**
+ * Default constructor.
+ */
+public ScopedAttributeELResolver() {
+super();
+}
+
 @Override
 public Object getValue(ELContext context, Object base, Object property) {
 Objects.requireNonNull(context);
diff --git a/java/javax/servlet/jsp/tagext/JspFragment.java 
b/java/javax/servlet/jsp/tagext/JspFragment.java
index 9faf8d023f..16eee7cb32 100644
--- a/java/javax/servlet/jsp/tagext/JspFragment.java
+++ b/java/javax/servlet/jsp/tagext/JspFragment.java
@@ -54,6 +54,13 @@ import javax.servlet.jsp.JspException;
  */
 public abstract class JspFragment {
 
+/**
+ * Default constructor.
+ */
+public JspFragment() {
+// NO-OP by default
+}
+
 /**
  * Executes the fragment and directs all output to the given Writer,
  * or the JspWriter returned by the getOut() method of the JspContext


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

[tomcat] branch 10.1.x updated: Fix Javadoc related build failure when building with Java 19

[markt]

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

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


The following commit(s) were added to refs/heads/10.1.x by this push:
 new 11807d6958 Fix Javadoc related build failure when building with Java 19
11807d6958 is described below

commit 11807d6958125b96c976bad4f7791c9cb7ac16be
Author: Mark Thomas 
AuthorDate: Thu Oct 20 15:01:21 2022 +0100

Fix Javadoc related build failure when building with Java 19
---
 java/jakarta/el/ELResolver.java| 12 
 java/jakarta/servlet/jsp/el/ImportELResolver.java  |  7 +++
 java/jakarta/servlet/jsp/el/NotFoundELResolver.java|  7 +++
 java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java |  9 +
 java/jakarta/servlet/jsp/tagext/JspFragment.java   |  7 +++
 5 files changed, 42 insertions(+)

diff --git a/java/jakarta/el/ELResolver.java b/java/jakarta/el/ELResolver.java
index 8846c0229e..1cf379c914 100644
--- a/java/jakarta/el/ELResolver.java
+++ b/java/jakarta/el/ELResolver.java
@@ -29,6 +29,9 @@ public abstract class ELResolver {
 public static final String RESOLVABLE_AT_DESIGN_TIME = 
"resolvableAtDesignTime";
 
 /**
+ * Obtain the value of the given property on the given object using the
+ * given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be returned
@@ -65,6 +68,9 @@ public abstract class ELResolver {
 }
 
 /**
+ * Obtain the type of the given property on the given object using the 
given
+ * context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose type is to be returned
@@ -82,6 +88,9 @@ public abstract class ELResolver {
 Object property);
 
 /**
+ * Set the value of the given property on the given object using the given
+ * context.
+ *
  * @param context  The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be set
@@ -102,6 +111,9 @@ public abstract class ELResolver {
 Object property, Object value);
 
 /**
+ * Determine if the given property on the given object is read-only using
+ * the given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property to be checked for read only status
diff --git a/java/jakarta/servlet/jsp/el/ImportELResolver.java 
b/java/jakarta/servlet/jsp/el/ImportELResolver.java
index 535e877a60..a3db558421 100644
--- a/java/jakarta/servlet/jsp/el/ImportELResolver.java
+++ b/java/jakarta/servlet/jsp/el/ImportELResolver.java
@@ -48,6 +48,13 @@ public class ImportELResolver extends ELResolver {
 AST_IDENTIFIER_KEY = key;
 }
 
+/**
+ * Default constructor.
+ */
+public ImportELResolver() {
+super();
+}
+
 @Override
 public Object getValue(ELContext context, Object base, Object property) {
 Objects.requireNonNull(context);
diff --git a/java/jakarta/servlet/jsp/el/NotFoundELResolver.java 
b/java/jakarta/servlet/jsp/el/NotFoundELResolver.java
index 517758fea2..35ad99de54 100644
--- a/java/jakarta/servlet/jsp/el/NotFoundELResolver.java
+++ b/java/jakarta/servlet/jsp/el/NotFoundELResolver.java
@@ -37,6 +37,13 @@ public class NotFoundELResolver extends ELResolver {
 private static final String LSTRING_FILE = 
"jakarta.servlet.jsp.LocalStrings";
 private static final ResourceBundle lStrings = 
ResourceBundle.getBundle(LSTRING_FILE);
 
+/**
+ * Default constructor.
+ */
+public NotFoundELResolver() {
+super();
+}
+
 /**
  * {@inheritDoc}
  * 
diff --git a/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java 
b/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java
index 0246f49421..4da4cc2b6e 100644
--- a/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java
+++ b/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java
@@ -29,11 +29,20 @@ import jakarta.servlet.jsp.JspContext;
 import jakarta.servlet.jsp.PageContext;
 
 /**
+ * An ELResolver for working with JSP scoped attributes which may have page,
+ * request, session or application scope.
  *
  * @since JSP 2.1
  */
 public class ScopedAttributeELResolver extends ELResolver {
 
+/**
+ * Default constructor.
+ */
+public ScopedAttributeELResolver() {
+super();
+}
+
 @Override
 public Object getValue(ELContext context, Object base, Object property) {
 Objects.requireNonNull(context);
diff --git a/java/jakarta/servlet/jsp/tag

[tomcat] branch main updated: Fix Javadoc related build failure when building with Java 19

[markt]

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 d95b769b4f Fix Javadoc related build failure when building with Java 19
d95b769b4f is described below

commit d95b769b4fc5d52f63b95a9835f570d4e4e947d8
Author: Mark Thomas 
AuthorDate: Thu Oct 20 15:01:21 2022 +0100

Fix Javadoc related build failure when building with Java 19
---
 java/jakarta/el/ELResolver.java| 12 
 java/jakarta/servlet/jsp/el/ImportELResolver.java  |  7 +++
 java/jakarta/servlet/jsp/el/NotFoundELResolver.java|  7 +++
 java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java |  9 +
 java/jakarta/servlet/jsp/tagext/JspFragment.java   |  7 +++
 5 files changed, 42 insertions(+)

diff --git a/java/jakarta/el/ELResolver.java b/java/jakarta/el/ELResolver.java
index 09bb98b01f..f33d3dd25e 100644
--- a/java/jakarta/el/ELResolver.java
+++ b/java/jakarta/el/ELResolver.java
@@ -27,6 +27,9 @@ public abstract class ELResolver {
 public static final String RESOLVABLE_AT_DESIGN_TIME = 
"resolvableAtDesignTime";
 
 /**
+ * Obtain the value of the given property on the given object using the
+ * given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be returned
@@ -63,6 +66,9 @@ public abstract class ELResolver {
 }
 
 /**
+ * Obtain the type of the given property on the given object using the 
given
+ * context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose type is to be returned
@@ -80,6 +86,9 @@ public abstract class ELResolver {
 Object property);
 
 /**
+ * Set the value of the given property on the given object using the given
+ * context.
+ *
  * @param context  The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property whose value is to be set
@@ -100,6 +109,9 @@ public abstract class ELResolver {
 Object property, Object value);
 
 /**
+ * Determine if the given property on the given object is read-only using
+ * the given context.
+ *
  * @param context The EL context for this evaluation
  * @param base The base object on which the property is to be found
  * @param property The property to be checked for read only status
diff --git a/java/jakarta/servlet/jsp/el/ImportELResolver.java 
b/java/jakarta/servlet/jsp/el/ImportELResolver.java
index 6e2cd81f75..38b3a26d7e 100644
--- a/java/jakarta/servlet/jsp/el/ImportELResolver.java
+++ b/java/jakarta/servlet/jsp/el/ImportELResolver.java
@@ -45,6 +45,13 @@ public class ImportELResolver extends ELResolver {
 AST_IDENTIFIER_KEY = key;
 }
 
+/**
+ * Default constructor.
+ */
+public ImportELResolver() {
+super();
+}
+
 @Override
 public Object getValue(ELContext context, Object base, Object property) {
 Objects.requireNonNull(context);
diff --git a/java/jakarta/servlet/jsp/el/NotFoundELResolver.java 
b/java/jakarta/servlet/jsp/el/NotFoundELResolver.java
index 23645abd6f..2849bad38b 100644
--- a/java/jakarta/servlet/jsp/el/NotFoundELResolver.java
+++ b/java/jakarta/servlet/jsp/el/NotFoundELResolver.java
@@ -34,6 +34,13 @@ public class NotFoundELResolver extends ELResolver {
 private static final String LSTRING_FILE = 
"jakarta.servlet.jsp.LocalStrings";
 private static final ResourceBundle lStrings = 
ResourceBundle.getBundle(LSTRING_FILE);
 
+/**
+ * Default constructor.
+ */
+public NotFoundELResolver() {
+super();
+}
+
 /**
  * {@inheritDoc}
  * 
diff --git a/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java 
b/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java
index 5908a4832c..2ec39ca7e5 100644
--- a/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java
+++ b/java/jakarta/servlet/jsp/el/ScopedAttributeELResolver.java
@@ -24,11 +24,20 @@ import jakarta.servlet.jsp.JspContext;
 import jakarta.servlet.jsp.PageContext;
 
 /**
+ * An ELResolver for working with JSP scoped attributes which may have page,
+ * request, session or application scope.
  *
  * @since JSP 2.1
  */
 public class ScopedAttributeELResolver extends ELResolver {
 
+/**
+ * Default constructor.
+ */
+public ScopedAttributeELResolver() {
+super();
+}
+
 @Override
 public Object getValue(ELContext context, Object base, Object property) {
 Objects.requireNonNull(context);
diff --git a/java/jakarta/servlet/jsp/tagext/

[tomcat] branch 10.1.x updated: Fix for Lambda coercion security manager missing privileges.

[lihan]

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

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


The following commit(s) were added to refs/heads/10.1.x by this push:
 new 220c2af01e Fix for Lambda coercion security manager missing privileges.
220c2af01e is described below

commit 220c2af01e2b05964750e5024a7b61d5c74b5e54
Author: lihan 
AuthorDate: Thu Oct 20 21:48:23 2022 +0800

Fix for Lambda coercion security manager missing privileges.

Based on pull request #557 by Isaac Rivera Rivas
---
 java/org/apache/el/lang/ELSupport.java | 28 ++--
 webapps/docs/changelog.xml |  8 
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/java/org/apache/el/lang/ELSupport.java 
b/java/org/apache/el/lang/ELSupport.java
index bc1b67a648..d07c9d6959 100644
--- a/java/org/apache/el/lang/ELSupport.java
+++ b/java/org/apache/el/lang/ELSupport.java
@@ -29,6 +29,7 @@ import java.security.PrivilegedAction;
 import java.util.Collections;
 import java.util.Map;
 import java.util.Set;
+import java.util.function.Supplier;
 
 import jakarta.el.ELContext;
 import jakarta.el.ELException;
@@ -625,17 +626,24 @@ public class ELSupport {
 
 private static  T coerceToFunctionalInterface(final ELContext ctx, 
final LambdaExpression lambdaExpression,
 final Class type) {
-// Create a dynamic proxy for the functional interface
-@SuppressWarnings("unchecked")
-T result = (T) Proxy.newProxyInstance(type.getClassLoader(), new 
Class[] { type },
+Supplier proxy = () -> {
+// Create a dynamic proxy for the functional interface
+@SuppressWarnings("unchecked")
+T result = (T) Proxy.newProxyInstance(type.getClassLoader(), new 
Class[]{type},
 (Object obj, Method method, Object[] args) -> {
-// Functional interfaces have a single, abstract method
-if (!Modifier.isAbstract(method.getModifiers())) {
-throw new 
ELException(MessageFactory.get("elSupport.coerce.nonAbstract", type, method));
-}
-return lambdaExpression.invoke(ctx, args);
-});
-return result;
+// Functional interfaces have a single, abstract method
+if (!Modifier.isAbstract(method.getModifiers())) {
+throw new 
ELException(MessageFactory.get("elSupport.coerce.nonAbstract", type, method));
+}
+return lambdaExpression.invoke(ctx, args);
+});
+return result;
+};
+if (System.getSecurityManager() !=  null) {
+return AccessController.doPrivileged((PrivilegedAction) 
proxy::get);
+} else {
+return proxy.get();
+}
 }
 
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index c42a13b3f7..7ab72a5200 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -114,6 +114,14 @@
   
 
   
+  
+
+  
+66317: Fix for Lambda coercion security manager missing
+privileges. Based on pull request #557 by Isaac Rivera Rivas (lihan)
+  
+
+  
   
 
   


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

Re: [tomcat] branch loom created (now 6a22f2f399)

[Rémy Maucherat]

On Thu, Oct 20, 2022 at 11:28 AM Mark Thomas  wrote:
>
> On 20/10/2022 09:32, Rémy Maucherat wrote:
>
> 
>
> > This is interesting since now is the best time to discuss long term plans.
> >
> > We'll see if there are some scheduling gains with Loom ... But I don't
> > think thread scheduling was the problem in Tomcat. Maybe lock
> > concurrency but it seems these had been eliminated (or improved at
> > least). I still don't understand how it could possibly really work
> > though, right now it feels like asking if Windows 3 cooperative
> > multitasking could work (= it works as long as all apps and libraries
> > are perfectly coded and there's no bug whatsoever). Also having to
> > avoid native code is annoying (just when there's finally something
> > good like Panama ...).
> >
> > I went through the Jakarta Servlet mailing list and there are some
> > discussions about Loom and a possible lower level API. It seems
> > there's a discussion between blocking and non blocking APIs. Well, IMO
> > we need both ...
> > - Blocking: For Loom. And mostly it could simply be
> > ServletRequest/Response/Cookie/IS/OS without any of the other items.
> > So it looks like everything is in there already.
> > - Async: Great if Loom isn't that appropriate for real work. However,
> > the listeners used for the Servlet API are not a very nice async API
> > (of course they are very appropriate as an extension for a blocking
> > API). So maybe that's where the new work is: come up with an async API
> > ?
> >
> > What do you think ?
>
> There are a lot of dimensions to this problem space.
>
> I have an initial implementation of the Loom module that supports the
> blocking parts of the Servlet API. I am currently working on the
> necessary refactoring to optimise that for Loom. I hope to get that
> committed later this week or early next.
>
> My working assumption is that any benefits Loom can provide will be in
> the blocking API. I don't see any way Loom could support the async and
> non-blocking APIs without adding some overhead - even if that overhead
> is negligible.
>
> Therefore, rather than moving on to try and implement support for the
> async and non-blocking parts of the Servlet API with the Loom connector,
> I'd like to spend some time exploring the performance of Loom with the
> blocking API. Hopefully, others here will also be able to undertake
> their own performance tests.

Ok, that is reasonable and seeing what can be expected in the best
case is a good plan. Async will indeed be a bit more expensive with
Loom, just like blocking is more expensive with NIO(2).

> I have only tested a couple of scenarios that aren't particularly suited
> to Loom (requests to a simple servlet) and the results are increased CPU
> usage and reduced throughput with Loom compared to NIO. I want to look
> at some tests that are more tailored to demonstrate the benefits of Loom.
>
> My expectation is that we will identify some scenarios where switching
> to the Loom module provides immediate benefits with no application
> changes. What will be interesting is how that compares to refactoring
> the application to use async and/or non-blocking.
>
> The other question is the extent to which the refactoring I have
> completed so far is necessary. I am not seeing much benefit from the
> optimisations I am implementing. It may be that a much simpler approach
> of integrating Loom (essentially a custom executor) is good enough. Note
> that this may mean undoing some of the refactoring I am currently
> implementing in Tomcat 11.
>
> Once we have that data, then I think we'll be in a position to decide
> the extent to which it makes sense to support Loom and whether or not to
> proceed and implement support for async and non-blocking in the Loom module.

+1 then. I hope there will be *something* that works more efficiently at least.

> There is clearly a demand for a lower-level HTTP API. The question for
> me at this point is whether that should be async based or blocking
> (Loom) based. Based on what I have seen so far, I think Greg Wilkins has
> called it correctly and that async will have the edge. However, that is
> more judgement/instinct than based on hard data. I want to see more data
> before making forming a final view.

Ok, let's wait for the results. I'll test it too.

Rémy

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

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

[tomcat] branch main updated: Fix for Lambda coercion security manager missing privileges.

[lihan]

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

lihan 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 34a48511a5 Fix for Lambda coercion security manager missing privileges.
34a48511a5 is described below

commit 34a48511a5b9c52b508daa347438a4a1e2b4ccfb
Author: lihan 
AuthorDate: Thu Oct 20 21:40:04 2022 +0800

Fix for Lambda coercion security manager missing privileges.

Based on pull request #557 by Isaac Rivera Rivas
---
 java/org/apache/el/lang/ELSupport.java | 28 ++--
 webapps/docs/changelog.xml |  8 
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/java/org/apache/el/lang/ELSupport.java 
b/java/org/apache/el/lang/ELSupport.java
index bc1b67a648..d07c9d6959 100644
--- a/java/org/apache/el/lang/ELSupport.java
+++ b/java/org/apache/el/lang/ELSupport.java
@@ -29,6 +29,7 @@ import java.security.PrivilegedAction;
 import java.util.Collections;
 import java.util.Map;
 import java.util.Set;
+import java.util.function.Supplier;
 
 import jakarta.el.ELContext;
 import jakarta.el.ELException;
@@ -625,17 +626,24 @@ public class ELSupport {
 
 private static  T coerceToFunctionalInterface(final ELContext ctx, 
final LambdaExpression lambdaExpression,
 final Class type) {
-// Create a dynamic proxy for the functional interface
-@SuppressWarnings("unchecked")
-T result = (T) Proxy.newProxyInstance(type.getClassLoader(), new 
Class[] { type },
+Supplier proxy = () -> {
+// Create a dynamic proxy for the functional interface
+@SuppressWarnings("unchecked")
+T result = (T) Proxy.newProxyInstance(type.getClassLoader(), new 
Class[]{type},
 (Object obj, Method method, Object[] args) -> {
-// Functional interfaces have a single, abstract method
-if (!Modifier.isAbstract(method.getModifiers())) {
-throw new 
ELException(MessageFactory.get("elSupport.coerce.nonAbstract", type, method));
-}
-return lambdaExpression.invoke(ctx, args);
-});
-return result;
+// Functional interfaces have a single, abstract method
+if (!Modifier.isAbstract(method.getModifiers())) {
+throw new 
ELException(MessageFactory.get("elSupport.coerce.nonAbstract", type, method));
+}
+return lambdaExpression.invoke(ctx, args);
+});
+return result;
+};
+if (System.getSecurityManager() !=  null) {
+return AccessController.doPrivileged((PrivilegedAction) 
proxy::get);
+} else {
+return proxy.get();
+}
 }
 
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 1b73b65c60..4e169d7f85 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -122,6 +122,14 @@
   
 
   
+  
+
+  
+66317: Fix for Lambda coercion security manager missing
+privileges. Based on pull request #557 by Isaac Rivera Rivas (lihan)
+  
+
+  
   
 
   


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

[Bug 66317] AccessControlException on EL 5.0

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66317

--- Comment #2 from Isaac Rivera Rivas  ---
Proposed fix for this https://github.com/apache/tomcat/pull/557

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] isaacrivriv opened a new pull request, #557: Fix for Lambda coercion security manager missing privileges

[GitBox]

isaacrivriv opened a new pull request, #557:
URL: https://github.com/apache/tomcat/pull/557

   Fix for https://bz.apache.org/bugzilla/show_bug.cgi?id=66317


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

Re: [tomcat] branch loom created (now 6a22f2f399)

[Mark Thomas]

On 20/10/2022 09:32, Rémy Maucherat wrote:




This is interesting since now is the best time to discuss long term plans.

We'll see if there are some scheduling gains with Loom ... But I don't
think thread scheduling was the problem in Tomcat. Maybe lock
concurrency but it seems these had been eliminated (or improved at
least). I still don't understand how it could possibly really work
though, right now it feels like asking if Windows 3 cooperative
multitasking could work (= it works as long as all apps and libraries
are perfectly coded and there's no bug whatsoever). Also having to
avoid native code is annoying (just when there's finally something
good like Panama ...).

I went through the Jakarta Servlet mailing list and there are some
discussions about Loom and a possible lower level API. It seems
there's a discussion between blocking and non blocking APIs. Well, IMO
we need both ...
- Blocking: For Loom. And mostly it could simply be
ServletRequest/Response/Cookie/IS/OS without any of the other items.
So it looks like everything is in there already.
- Async: Great if Loom isn't that appropriate for real work. However,
the listeners used for the Servlet API are not a very nice async API
(of course they are very appropriate as an extension for a blocking
API). So maybe that's where the new work is: come up with an async API
?

What do you think ?


There are a lot of dimensions to this problem space.

I have an initial implementation of the Loom module that supports the 
blocking parts of the Servlet API. I am currently working on the 
necessary refactoring to optimise that for Loom. I hope to get that 
committed later this week or early next.


My working assumption is that any benefits Loom can provide will be in 
the blocking API. I don't see any way Loom could support the async and 
non-blocking APIs without adding some overhead - even if that overhead 
is negligible.


Therefore, rather than moving on to try and implement support for the 
async and non-blocking parts of the Servlet API with the Loom connector, 
I'd like to spend some time exploring the performance of Loom with the 
blocking API. Hopefully, others here will also be able to undertake 
their own performance tests.


I have only tested a couple of scenarios that aren't particularly suited 
to Loom (requests to a simple servlet) and the results are increased CPU 
usage and reduced throughput with Loom compared to NIO. I want to look 
at some tests that are more tailored to demonstrate the benefits of Loom.


My expectation is that we will identify some scenarios where switching 
to the Loom module provides immediate benefits with no application 
changes. What will be interesting is how that compares to refactoring 
the application to use async and/or non-blocking.


The other question is the extent to which the refactoring I have 
completed so far is necessary. I am not seeing much benefit from the 
optimisations I am implementing. It may be that a much simpler approach 
of integrating Loom (essentially a custom executor) is good enough. Note 
that this may mean undoing some of the refactoring I am currently 
implementing in Tomcat 11.


Once we have that data, then I think we'll be in a position to decide 
the extent to which it makes sense to support Loom and whether or not to 
proceed and implement support for async and non-blocking in the Loom module.


There is clearly a demand for a lower-level HTTP API. The question for 
me at this point is whether that should be async based or blocking 
(Loom) based. Based on what I have seen so far, I think Greg Wilkins has 
called it correctly and that async will have the edge. However, that is 
more judgement/instinct than based on hard data. I want to see more data 
before making forming a final view.


Mark

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

Re: [DISCUSS] EOL date for 8.5.x

[Rainer Jung]

Am 20.10.2022 um 11:01 schrieb Rémy Maucherat:

On Fri, Oct 7, 2022 at 11:28 AM Mark Thomas  wrote:


Hi all,

I don't think there is a need to make a decision on this quickly, but
based on past experience and the current discussions about Jakarta EE 11
I think this is something we need to start thinking about.

Some key facts:

- Tomcat 7.0.x reached EOL on 31 March 2021
- EOL dates for major versions tend to be 3-4 years apart
- We aim to support 3 major versions in parallel - currently 8.5.x,
9.0.x and 10.1.x.
- Tomcat 11 will implement Jakarta EE 11
- Current Jakarta EE discussions are around a release in ~1 year
- Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared
stable

Based on the above I think EOL for 8.5.x should be either 31 March 2024
or 30 Sept 2024 depending on when we think Jakarta EE 11 will be released.

Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is
probably the more likely. However, it is much easier to delay an EOL
date than to bring to bring it forward so my current thinking is to
announce 31 March 2024 as the EOL date for 8.5.x and keep in mind that
we can extend that if we want to.

Thoughts?


My slides said Tomcat 8.5 will be EOL when Tomcat 11 is released, so
it seems that was the plan all along.
So easy +1 :)

About the exact date, I think it is ok to set a date even if Tomcat 11
happens to slip, Tomcat 9.0 is there.


I am also fine with 31 March 2024.

Regards,

Rainer

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

Re: [DISCUSS] EOL date for 8.5.x

[Rémy Maucherat]

On Fri, Oct 7, 2022 at 11:28 AM Mark Thomas  wrote:
>
> Hi all,
>
> I don't think there is a need to make a decision on this quickly, but
> based on past experience and the current discussions about Jakarta EE 11
> I think this is something we need to start thinking about.
>
> Some key facts:
>
> - Tomcat 7.0.x reached EOL on 31 March 2021
> - EOL dates for major versions tend to be 3-4 years apart
> - We aim to support 3 major versions in parallel - currently 8.5.x,
>9.0.x and 10.1.x.
> - Tomcat 11 will implement Jakarta EE 11
> - Current Jakarta EE discussions are around a release in ~1 year
> - Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared
>stable
>
> Based on the above I think EOL for 8.5.x should be either 31 March 2024
> or 30 Sept 2024 depending on when we think Jakarta EE 11 will be released.
>
> Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is
> probably the more likely. However, it is much easier to delay an EOL
> date than to bring to bring it forward so my current thinking is to
> announce 31 March 2024 as the EOL date for 8.5.x and keep in mind that
> we can extend that if we want to.
>
> Thoughts?

My slides said Tomcat 8.5 will be EOL when Tomcat 11 is released, so
it seems that was the plan all along.
So easy +1 :)

About the exact date, I think it is ok to set a date even if Tomcat 11
happens to slip, Tomcat 9.0 is there.

Rémy

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

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

Re: [DISCUSS] EOL date for 8.5.x

[Mark Thomas]

Bump.


On 07/10/2022 10:27, Mark Thomas wrote:

Hi all,

I don't think there is a need to make a decision on this quickly, but 
based on past experience and the current discussions about Jakarta EE 11 
I think this is something we need to start thinking about.


Some key facts:

- Tomcat 7.0.x reached EOL on 31 March 2021
- EOL dates for major versions tend to be 3-4 years apart
- We aim to support 3 major versions in parallel - currently 8.5.x,
   9.0.x and 10.1.x.
- Tomcat 11 will implement Jakarta EE 11
- Current Jakarta EE discussions are around a release in ~1 year
- Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared
   stable

Based on the above I think EOL for 8.5.x should be either 31 March 2024 
or 30 Sept 2024 depending on when we think Jakarta EE 11 will be released.


Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is 
probably the more likely. However, it is much easier to delay an EOL 
date than to bring to bring it forward so my current thinking is to 
announce 31 March 2024 as the EOL date for 8.5.x and keep in mind that 
we can extend that if we want to.


Thoughts?

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: [tomcat] branch loom created (now 6a22f2f399)

[Rémy Maucherat]

Hi Mark,

On Wed, Oct 19, 2022 at 4:41 PM Mark Thomas  wrote:
>
> On 19/10/2022 15:39, ma...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a change to branch loom
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
> Sorry for the noise.
>
> This is a local experimental branch I didn't mean to push.

This is interesting since now is the best time to discuss long term plans.

We'll see if there are some scheduling gains with Loom ... But I don't
think thread scheduling was the problem in Tomcat. Maybe lock
concurrency but it seems these had been eliminated (or improved at
least). I still don't understand how it could possibly really work
though, right now it feels like asking if Windows 3 cooperative
multitasking could work (= it works as long as all apps and libraries
are perfectly coded and there's no bug whatsoever). Also having to
avoid native code is annoying (just when there's finally something
good like Panama ...).

I went through the Jakarta Servlet mailing list and there are some
discussions about Loom and a possible lower level API. It seems
there's a discussion between blocking and non blocking APIs. Well, IMO
we need both ...
- Blocking: For Loom. And mostly it could simply be
ServletRequest/Response/Cookie/IS/OS without any of the other items.
So it looks like everything is in there already.
- Async: Great if Loom isn't that appropriate for real work. However,
the listeners used for the Servlet API are not a very nice async API
(of course they are very appropriate as an extension for a blocking
API). So maybe that's where the new work is: come up with an async API
?

What do you think ?

Rémy

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

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