[GitHub] [tomcat] michael-o commented on pull request #428: Enhancement: Additional user attributes queried by (some) realms

[GitBox]

michael-o commented on pull request #428:
URL: https://github.com/apache/tomcat/pull/428#issuecomment-876192961


   @cklein05 I am waiting for other committers to review.


-- 
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] rmaucher commented on pull request #428: Enhancement: Additional user attributes queried by (some) realms

[GitBox]

rmaucher commented on pull request #428:
URL: https://github.com/apache/tomcat/pull/428#issuecomment-876223848


   Still looks good to me, needs a super minor merging for UserDatabaseRealm.


-- 
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-native] branch main updated: Correct fox for OpenSSL 3.x build

[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-native.git


The following commit(s) were added to refs/heads/main by this push:
 new 755a9cb  Correct fox for OpenSSL 3.x build
755a9cb is described below

commit 755a9cbd49fa4f1ad6e38b741957bf2cede42b63
Author: Mark Thomas 
AuthorDate: Thu Jul 8 11:50:53 2021 +0100

Correct fox for OpenSSL 3.x build
---
 native/src/sslutils.c | 4 ++--
 xdocs/miscellaneous/changelog.xml | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/native/src/sslutils.c b/native/src/sslutils.c
index 314bdad..46898be 100644
--- a/native/src/sslutils.c
+++ b/native/src/sslutils.c
@@ -993,9 +993,9 @@ static OCSP_RESPONSE *get_ocsp_response(apr_pool_t *p, X509 
*cert, X509 *issuer,
 apr_socket_t *apr_sock = NULL;
 apr_pool_t *mp;
 #if OPENSSL_VERSION_NUMBER < 0x3000L
-if (OCSP_parse_url(url,&hostname, &c_port, &path, &use_ssl) == 0 )
+if (OCSP_parse_url(url, &hostname, &c_port, &path, &use_ssl) == 0)
 #else
-if (OCSP_HTTP_parse_url(url,&hostname, &c_port, NULL, &path, &use_ssl) == 
0 )
+if (OSSL_HTTP_parse_url(url, &use_ssl, NULL, &hostname, &c_port, NULL, 
&path, NULL, NULL) == 0)
 #endif
 goto end;
 
diff --git a/xdocs/miscellaneous/changelog.xml 
b/xdocs/miscellaneous/changelog.xml
index 39737cc..f43f41e 100644
--- a/xdocs/miscellaneous/changelog.xml
+++ b/xdocs/miscellaneous/changelog.xml
@@ -36,6 +36,10 @@
 
 
   
+
+  65441: Correct previous fix that enabled building to continue
+  with OpenSSL 3.x. Patch provided by lzsiga. (markt)
+
   
 
 

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

[Bug 65441] sslutils.c: function OCSP_HTTP_parse_url doesn't exist, use OSSL_HTTP_parse_url instead

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Mark Thomas  ---
Thanks for the report and the patch. Fixed for 1.2.31 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

Graal now supports JMX?

[Mark Thomas]

Hi,

I got pinged on this issue yesterday:
https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648

That reads to me as if Graal now supports the use of JMX. If that is the 
case I think we can remove this code:


https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139

and go back to the standard --no-jmx or calling 
Registry.disableRegistry() for those users that don't want JMX support.


Thoughts?

I plan to make this change early next week if there are no objections.

Mark

-
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 #428: Enhancement: Additional user attributes queried by (some) realms

[GitBox]

markt-asf commented on pull request #428:
URL: https://github.com/apache/tomcat/pull/428#issuecomment-876355711


   For defensive copies, I see several approaches:
   1. GenericPrincipal always returns defensive copies
   2. GenericPrincipal returns defensive copies if running under a 
SecurityManager
   3. GenericPrincipal is documented to require that any attributes added to it 
are safe to expose to applications.
   
   Option one will create unnecessary copies in some scenarios but it should be 
impossible for a security sensitive internal object to be exposed to a 
potentially untrusted application.
   Option two may create some unnecessary copies but only when working with 
untrusted applications (on the assumption that anyone running an untrusted 
application should be using a SecurityManager).
   Option three allows any unnecessary copying (either because the objects are 
safe to share or because the application is trusted) to be avoided at the risk 
of it being possible to expose an internal object if the configuration/coding 
is incorrect.
   The other thing I like about option 3 is it enables the caller to figure out 
the best way to create any required defensive copy rather than trying to write 
a generic deep object clone solution in GenericPrincipal.


-- 
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: Graal now supports JMX?

[Romain Manni-Bucau]

Hi Mark,

My understanding of the issue is that the isGraal test is not sufficient
and should be precised to be isGraalNative (just using the naming to
express the idea).
Graal is a plain JVM and this does not need any hack but when native-image
is used it needs all current hacks so guess the test is not precise enough
but that the disabling should stay by default for native-image.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 8 juil. 2021 à 13:01, Mark Thomas  a écrit :

> Hi,
>
> I got pinged on this issue yesterday:
>
> https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648
>
> That reads to me as if Graal now supports the use of JMX. If that is the
> case I think we can remove this code:
>
>
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139
>
> and go back to the standard --no-jmx or calling
> Registry.disableRegistry() for those users that don't want JMX support.
>
> Thoughts?
>
> I plan to make this change early next week if there are no objections.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Graal now supports JMX?

[Rémy Maucherat]

On Thu, Jul 8, 2021 at 1:01 PM Mark Thomas  wrote:
>
> Hi,
>
> I got pinged on this issue yesterday:
> https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648
>
> That reads to me as if Graal now supports the use of JMX. If that is the
> case I think we can remove this code:
>
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139
>
> and go back to the standard --no-jmx or calling
> Registry.disableRegistry() for those users that don't want JMX support.
>
> Thoughts?
>
> I plan to make this change early next week if there are no objections.

I agree it's worth trying since the explicit and easy to use flag
makes JMX rather easy to handle. Then we can test again.

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: Graal now supports JMX?

[Rémy Maucherat]

On Thu, Jul 8, 2021 at 1:21 PM Romain Manni-Bucau  wrote:
>
> Hi Mark,
>
> My understanding of the issue is that the isGraal test is not sufficient
> and should be precised to be isGraalNative (just using the naming to
> express the idea).
> Graal is a plain JVM and this does not need any hack but when native-image
> is used it needs all current hacks so guess the test is not precise enough
> but that the disabling should stay by default for native-image.

This is more complex since the "Graal native" mode must also be
enabled when using the agent, and that's basically what the flag does.
If running Graal without the agent, then the isGraal flag returns
false. The "org.graalvm.nativeimage.imagecode" system property
override might get in the way however since the Spring code hacks it.
The check could be refined there maybe.

Rémy

>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le jeu. 8 juil. 2021 à 13:01, Mark Thomas  a écrit :
>
> > Hi,
> >
> > I got pinged on this issue yesterday:
> >
> > https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648
> >
> > That reads to me as if Graal now supports the use of JMX. If that is the
> > case I think we can remove this code:
> >
> >
> > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139
> >
> > and go back to the standard --no-jmx or calling
> > Registry.disableRegistry() for those users that don't want JMX support.
> >
> > Thoughts?
> >
> > I plan to make this change early next week if there are no objections.
> >
> > 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

[GitHub] [tomcat] cklein05 commented on pull request #428: Enhancement: Additional user attributes queried by (some) realms

[GitBox]

cklein05 commented on pull request #428:
URL: https://github.com/apache/tomcat/pull/428#issuecomment-876456139


   On defensive copies:
   
   For my understanding, defensive copies do not prevent exposing sensitive 
user information to (potentially untrusted) applications due to an 
inappropriate configuration. So, the Realm always needs to be configured 
carefully with regards to _keeping secrets secret_. That has not much to do 
with defensive copies.
   
   The only thing defensive copies could help is to prevent that an evil 
application is able to modify a cached attribute value (we've agreed on that 
attribute values should be immutable). However, in that case, GenericPrincipal 
cannot trust the caller and has to generically create these copies itself.
   
   I guess, the question is whether we rely on Java's understanding of 
_immutable_ objects (_position A_, e. g. String _is_ an immutable type so, no 
copy is needed) or whether we account for that that's not true with reflection 
(_position B_, e. g. a String can be changed inline with reflection or native 
code). With position A, we could at least save some copies for immutable types 
(according to Java's definition of _immutable_).
   
   After all, since we can expect that most applications don't request the 
Principal's attributes too frequently, we could easily go with option 1 and 
copy every object returned.


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

Update "developers" list

[Christopher Schultz]

All,

The Apache Tomcat web site has a few places where people are 
specifically listed by name. One is under "Who We Are"[1], and it's 
fairly up-to-date. (Reasonable people can disagree as to whether e.g. 
"jim" is a committer or a committer-emeritus.)


There is another place people are listed, and it's under each version's 
documentation. For example, there is a list of "active developers" for 
Tomcat 8.5[2]. That list is quite out of date, and it looks like it's 
the same for all of 8.5, 9.0, 10.0, and 10.1.


Is it worth updating these version-specific pages? Or maybe replace them 
with redirects to "Who We Are"? We have lots of contributors (myself 
included) who are not listed there at all.


-chris

[1] https://tomcat.apache.org/whoweare.html
[2] http://tomcat.apache.org/tomcat-8.5-doc/developers.html

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

[GitHub] [tomcat] ChristopherSchultz commented on pull request #428: Enhancement: Additional user attributes queried by (some) realms

[GitBox]

ChristopherSchultz commented on pull request #428:
URL: https://github.com/apache/tomcat/pull/428#issuecomment-876511953


   When considering defensive copying, one must remember that no other code can 
be trusted, but our own code _can_ be trusted. So structures passed-into the 
realm must be copied to protect our code from a malicious (or incompetent) 
client breaking things. When returning structures, there is more flexibility 
depending upon how much you trust the JVM and whether or not you want to 
protect against truly malicious code.
   
   For example, for most cases, it's reasonable to return 
Collections.unmodifiable[Collection](foo) to ensure that foreign code doesn't 
mess with your structure. But, reflection is a possibility and therefore it's 
not _entirely_ safe.
   
   If it's reasonable to return `Collections.unmodifiable[Collection](foo)` for 
a certain `getFoo()` operation, and the strcuture needs to be unmodifiable 
locally, anyway, then making a defensive *and* unmodifiable copy during 
`setFoo` (or similar) is reasonable. Then we can avoid additional allocations 
on every `getFoo()` call.
   
   But again, it depends upon hos security-sensitive these items are. 
Unfortunately, it's impossible to know how security-sensitive these things can 
be, because they are application-defined. Having a user-attribute "locale" is 
unlikely to be highly security-sensitive. But maybe "totp-seed" may be. Or 
"user-is-unrestricted-administrator" or something similar.
   
   Security features are always a trade-off, and most applications don't need 
this kind of uber-paranoid data-handling. But some environments may require it. 
Since nobody has been beating-down the door asking for user-attributes on 
realms in the first place, perhaps engineering a solution to include 
uber-paranoia is over-engineering. Anything that can be written can be 
re-written, improved, etc.
   
   I suggest we do the minimum possible to build the useful feature and ship 
it. If "casual" damage to structures would be Bad, let's prevent that from 
happening. But let's not worry too much about an application using native code 
to modify the internal char array of a `java.lang.String` value at this point.


-- 
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: Update "developers" list

[Mark Thomas]

On 08/07/2021 15:28, Christopher Schultz wrote:

All,

The Apache Tomcat web site has a few places where people are 
specifically listed by name. One is under "Who We Are"[1], and it's 
fairly up-to-date. (Reasonable people can disagree as to whether e.g. 
"jim" is a committer or a committer-emeritus.)


There is another place people are listed, and it's under each version's 
documentation. For example, there is a list of "active developers" for 
Tomcat 8.5[2]. That list is quite out of date, and it looks like it's 
the same for all of 8.5, 9.0, 10.0, and 10.1.


Is it worth updating these version-specific pages? Or maybe replace them 
with redirects to "Who We Are"? We have lots of contributors (myself 
included) who are not listed there at all.


+1 to dropping them. I'd forgotten that those pages even existed. Happy 
with adding a redirect but no particular concerns about just dropping 
them entirely. Maybe just replace the links to that page with a link to 
[1] ?


Mark

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

Re: Graal now supports JMX?

[Romain Manni-Bucau]

Le jeu. 8 juil. 2021 à 15:36, Rémy Maucherat  a écrit :

> On Thu, Jul 8, 2021 at 1:21 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Mark,
> >
> > My understanding of the issue is that the isGraal test is not sufficient
> > and should be precised to be isGraalNative (just using the naming to
> > express the idea).
> > Graal is a plain JVM and this does not need any hack but when
> native-image
> > is used it needs all current hacks so guess the test is not precise
> enough
> > but that the disabling should stay by default for native-image.
>
> This is more complex since the "Graal native" mode must also be
> enabled when using the agent, and that's basically what the flag does.
> If running Graal without the agent, then the isGraal flag returns
> false. The "org.graalvm.nativeimage.imagecode" system property
> override might get in the way however since the Spring code hacks it.
> The check could be refined there maybe.
>

Well it is only true when tomcats itself uses the agent to generate the
json config files so guess the CLI arg or any other config works as well
there.
(for end users you still have to tune a tons of things after so not sure it
is that used and should be considered for that issue)


>
> Rémy
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 8 juil. 2021 à 13:01, Mark Thomas  a écrit :
> >
> > > Hi,
> > >
> > > I got pinged on this issue yesterday:
> > >
> > >
> https://github.com/spring-projects-experimental/spring-native/issues/805#issuecomment-875335648
> > >
> > > That reads to me as if Graal now supports the use of JMX. If that is
> the
> > > case I think we can remove this code:
> > >
> > >
> > >
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/modeler/Registry.java#L139
> > >
> > > and go back to the standard --no-jmx or calling
> > > Registry.disableRegistry() for those users that don't want JMX support.
> > >
> > > Thoughts?
> > >
> > > I plan to make this change early next week if there are no objections.
> > >
> > > 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: Update "developers" list

[Coty Sutherland]

On Thu, Jul 8, 2021 at 11:17 AM Mark Thomas  wrote:

> On 08/07/2021 15:28, Christopher Schultz wrote:
> > All,
> >
> > The Apache Tomcat web site has a few places where people are
> > specifically listed by name. One is under "Who We Are"[1], and it's
> > fairly up-to-date. (Reasonable people can disagree as to whether e.g.
> > "jim" is a committer or a committer-emeritus.)
> >
> > There is another place people are listed, and it's under each version's
> > documentation. For example, there is a list of "active developers" for
> > Tomcat 8.5[2]. That list is quite out of date, and it looks like it's
> > the same for all of 8.5, 9.0, 10.0, and 10.1.
> >
> > Is it worth updating these version-specific pages? Or maybe replace them
> > with redirects to "Who We Are"? We have lots of contributors (myself
> > included) who are not listed there at all.
>
> +1 to dropping them. I'd forgotten that those pages even existed. Happy
> with adding a redirect but no particular concerns about just dropping
> them entirely. Maybe just replace the links to that page with a link to
> [1] ?
>

Yeah, I'm +1 for dropping them and replacing the page with links to the Who
We Are page.

[tomcat] branch main updated (35bd877 -> 2fcb104)

[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 35bd877  Add more generics to EL API to align with spec project
 new c57c361  ELSupport is a utility class. Refactor so it is accessed as 
one.
 new a37f7a1  Rename so strings get picked up by POEditor import/export code
 new 2fcb104  Add support for coercing LambdaExpression to any functional 
interface

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 ...Messages.properties => LocalStrings.properties} |  2 +
 ...es_es.properties => LocalStrings_es.properties} |  0
 java/org/apache/el/lang/ELSupport.java | 36 --
 java/org/apache/el/parser/AstAnd.java  |  5 +-
 java/org/apache/el/parser/AstChoice.java   |  3 +-
 java/org/apache/el/parser/AstConcatenation.java|  5 +-
 java/org/apache/el/parser/AstEqual.java|  3 +-
 java/org/apache/el/parser/AstFunction.java |  5 +-
 java/org/apache/el/parser/AstGreaterThan.java  |  3 +-
 java/org/apache/el/parser/AstGreaterThanEqual.java |  3 +-
 java/org/apache/el/parser/AstLessThan.java |  3 +-
 java/org/apache/el/parser/AstLessThanEqual.java|  3 +-
 java/org/apache/el/parser/AstNegative.java |  5 +-
 java/org/apache/el/parser/AstNot.java  |  3 +-
 java/org/apache/el/parser/AstNotEqual.java |  3 +-
 java/org/apache/el/parser/AstOr.java   |  5 +-
 java/org/apache/el/parser/SimpleNode.java  |  3 +-
 java/org/apache/el/util/MessageFactory.java|  3 +-
 test/org/apache/el/lang/TestELSupport.java | 76 ++
 webapps/docs/changelog.xml |  5 ++
 20 files changed, 146 insertions(+), 28 deletions(-)
 rename java/org/apache/el/{Messages.properties => LocalStrings.properties} 
(96%)
 rename java/org/apache/el/{Messages_es.properties => 
LocalStrings_es.properties} (100%)

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

[tomcat] 02/03: Rename so strings get picked up by POEditor import/export code

[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

commit a37f7a11a1b644c4e9e965da730824ea656d3a3a
Author: Mark Thomas 
AuthorDate: Thu Jul 8 21:50:04 2021 +0100

Rename so strings get picked up by POEditor import/export code

Because of the non-standard name, these strings were not exported so
contributors providing translations have not been able to translate
these strings.
---
 java/org/apache/el/{Messages.properties => LocalStrings.properties}| 0
 .../apache/el/{Messages_es.properties => LocalStrings_es.properties}   | 0
 java/org/apache/el/util/MessageFactory.java| 3 +--
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/java/org/apache/el/Messages.properties 
b/java/org/apache/el/LocalStrings.properties
similarity index 100%
rename from java/org/apache/el/Messages.properties
rename to java/org/apache/el/LocalStrings.properties
diff --git a/java/org/apache/el/Messages_es.properties 
b/java/org/apache/el/LocalStrings_es.properties
similarity index 100%
rename from java/org/apache/el/Messages_es.properties
rename to java/org/apache/el/LocalStrings_es.properties
diff --git a/java/org/apache/el/util/MessageFactory.java 
b/java/org/apache/el/util/MessageFactory.java
index 904..40f2dde 100644
--- a/java/org/apache/el/util/MessageFactory.java
+++ b/java/org/apache/el/util/MessageFactory.java
@@ -25,8 +25,7 @@ import java.util.ResourceBundle;
  */
 public final class MessageFactory {
 
-static final ResourceBundle bundle =
-ResourceBundle.getBundle("org.apache.el.Messages");
+static final ResourceBundle bundle = 
ResourceBundle.getBundle("org.apache.el.LocalStrings");
 
 public MessageFactory() {
 super();

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

[tomcat] 03/03: Add support for coercing LambdaExpression to any functional interface

[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

commit 2fcb104294b2676154cb08f00d5665d668792280
Author: Mark Thomas 
AuthorDate: Thu Jul 8 22:02:26 2021 +0100

Add support for coercing LambdaExpression to any functional interface

This addresses this currently open issue against the EL spec
https://github.com/eclipse-ee4j/el-ri/issues/45
This is an initial implementation so users can provide feedback
The implementation was inspired by rmuller's suggestion for an
ELResolver that performs a similar function:
https://stackoverflow.com/questions/46573761
---
 java/org/apache/el/LocalStrings.properties |  2 +
 java/org/apache/el/lang/ELSupport.java | 27 +++
 test/org/apache/el/lang/TestELSupport.java | 76 ++
 webapps/docs/changelog.xml |  5 ++
 4 files changed, 110 insertions(+)

diff --git a/java/org/apache/el/LocalStrings.properties 
b/java/org/apache/el/LocalStrings.properties
index 1bf600d..d9f5503 100644
--- a/java/org/apache/el/LocalStrings.properties
+++ b/java/org/apache/el/LocalStrings.properties
@@ -13,6 +13,8 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+elSupport.coerce.nonAbstract=Unable to coerce a LambdaExpression to the 
functional interface [{0}] because the method [{1}] is not abstract
+
 # General Errors
 error.cannotSetVariables=Cannot set variables on factory
 error.convert=Cannot convert [{0}] of type [{1}] to [{2}]
diff --git a/java/org/apache/el/lang/ELSupport.java 
b/java/org/apache/el/lang/ELSupport.java
index 808ad79..c37fbac 100644
--- a/java/org/apache/el/lang/ELSupport.java
+++ b/java/org/apache/el/lang/ELSupport.java
@@ -19,6 +19,9 @@ package org.apache.el.lang;
 import java.beans.PropertyEditor;
 import java.beans.PropertyEditorManager;
 import java.lang.reflect.Array;
+import java.lang.reflect.Method;
+import java.lang.reflect.Modifier;
+import java.lang.reflect.Proxy;
 import java.math.BigDecimal;
 import java.math.BigInteger;
 import java.security.AccessController;
@@ -29,6 +32,7 @@ import java.util.Set;
 
 import jakarta.el.ELContext;
 import jakarta.el.ELException;
+import jakarta.el.LambdaExpression;
 
 import org.apache.el.util.MessageFactory;
 
@@ -588,6 +592,11 @@ public class ELSupport {
 return result;
 }
 
+if (obj instanceof LambdaExpression && 
type.getAnnotation(FunctionalInterface.class) != null) {
+T result = coerceToFunctionalInterface(ctx, (LambdaExpression) 
obj, type);
+return result;
+}
+
 throw new ELException(MessageFactory.get("error.convert",
 obj, obj.getClass(), type));
 }
@@ -613,6 +622,24 @@ public class ELSupport {
 return result;
 }
 
+
+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 },
+(Object obj, Method method, Object[] args) -> {
+// Functional interfaces have a single, abstract method
+if (!Modifier.isAbstract(method.getModifiers())) {
+// TODO
+throw new 
ELException(MessageFactory.get("elSupport.coerce.nonAbstract", type, method));
+}
+return lambdaExpression.invoke(ctx, args);
+});
+return result;
+}
+
+
 public static final boolean isBigDecimalOp(final Object obj0,
 final Object obj1) {
 return (obj0 instanceof BigDecimal || obj1 instanceof BigDecimal);
diff --git a/test/org/apache/el/lang/TestELSupport.java 
b/test/org/apache/el/lang/TestELSupport.java
index 84d3ed4..672afd5 100644
--- a/test/org/apache/el/lang/TestELSupport.java
+++ b/test/org/apache/el/lang/TestELSupport.java
@@ -19,9 +19,11 @@ package org.apache.el.lang;
 import java.beans.PropertyEditorManager;
 import java.math.BigDecimal;
 import java.math.BigInteger;
+import java.util.function.Predicate;
 
 import jakarta.el.ELException;
 import jakarta.el.ELManager;
+import jakarta.el.ELProcessor;
 
 import org.junit.Assert;
 import org.junit.Test;
@@ -276,4 +278,78 @@ public class TestELSupport {
 VALB1,
 VALB2
 }
+
+
+@Test
+public void testCoercetoFunctionalInterface01() throws Exception {
+final ELProcessor elp = new ELProcessor();
+elp.defineFunction("", "", "org.apache.el.lang.TestELSupport", 
"testPredicateA");
+Object result = elp.eval("testPredicateA(x -> x.equals('data'))");
+Assert.assertEquals("PASS", result);
+}
+
+
+@Test
+public void testCoercetoFunctionalInterface02() throws Exception {
+final E

[tomcat] 01/03: ELSupport is a utility class. Refactor so it is accessed as one.

[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

commit c57c3619f75f5ddc21d79f58bdda1d0866da46cb
Author: Mark Thomas 
AuthorDate: Thu Jul 8 20:55:20 2021 +0100

ELSupport is a utility class. Refactor so it is accessed as one.
---
 java/org/apache/el/lang/ELSupport.java | 9 +++--
 java/org/apache/el/parser/AstAnd.java  | 5 +++--
 java/org/apache/el/parser/AstChoice.java   | 3 ++-
 java/org/apache/el/parser/AstConcatenation.java| 5 +++--
 java/org/apache/el/parser/AstEqual.java| 3 ++-
 java/org/apache/el/parser/AstFunction.java | 5 +++--
 java/org/apache/el/parser/AstGreaterThan.java  | 3 ++-
 java/org/apache/el/parser/AstGreaterThanEqual.java | 3 ++-
 java/org/apache/el/parser/AstLessThan.java | 3 ++-
 java/org/apache/el/parser/AstLessThanEqual.java| 3 ++-
 java/org/apache/el/parser/AstNegative.java | 5 +++--
 java/org/apache/el/parser/AstNot.java  | 3 ++-
 java/org/apache/el/parser/AstNotEqual.java | 3 ++-
 java/org/apache/el/parser/AstOr.java   | 5 +++--
 java/org/apache/el/parser/SimpleNode.java  | 3 +--
 15 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/java/org/apache/el/lang/ELSupport.java 
b/java/org/apache/el/lang/ELSupport.java
index 7a81015..808ad79 100644
--- a/java/org/apache/el/lang/ELSupport.java
+++ b/java/org/apache/el/lang/ELSupport.java
@@ -660,11 +660,8 @@ public class ELSupport {
 return false;
 }
 
-/**
- *
- */
-public ELSupport() {
-super();
-}
 
+private ELSupport() {
+// Uility class - hide default constructor;
+}
 }
diff --git a/java/org/apache/el/parser/AstAnd.java 
b/java/org/apache/el/parser/AstAnd.java
index b65c731..85d268e 100644
--- a/java/org/apache/el/parser/AstAnd.java
+++ b/java/org/apache/el/parser/AstAnd.java
@@ -19,6 +19,7 @@ package org.apache.el.parser;
 
 import jakarta.el.ELException;
 
+import org.apache.el.lang.ELSupport;
 import org.apache.el.lang.EvaluationContext;
 
 
@@ -34,12 +35,12 @@ public final class AstAnd extends BooleanNode {
 public Object getValue(EvaluationContext ctx)
 throws ELException {
 Object obj = children[0].getValue(ctx);
-Boolean b = coerceToBoolean(ctx, obj, true);
+Boolean b = ELSupport.coerceToBoolean(ctx, obj, true);
 if (!b.booleanValue()) {
 return b;
 }
 obj = children[1].getValue(ctx);
-b = coerceToBoolean(ctx, obj, true);
+b = ELSupport.coerceToBoolean(ctx, obj, true);
 return b;
 }
 }
diff --git a/java/org/apache/el/parser/AstChoice.java 
b/java/org/apache/el/parser/AstChoice.java
index 5819ead..173ea22 100644
--- a/java/org/apache/el/parser/AstChoice.java
+++ b/java/org/apache/el/parser/AstChoice.java
@@ -19,6 +19,7 @@ package org.apache.el.parser;
 
 import jakarta.el.ELException;
 
+import org.apache.el.lang.ELSupport;
 import org.apache.el.lang.EvaluationContext;
 
 
@@ -41,7 +42,7 @@ public final class AstChoice extends SimpleNode {
 public Object getValue(EvaluationContext ctx)
 throws ELException {
 Object obj0 = this.children[0].getValue(ctx);
-Boolean b0 = coerceToBoolean(ctx, obj0, true);
+Boolean b0 = ELSupport.coerceToBoolean(ctx, obj0, true);
 return this.children[((b0.booleanValue() ? 1 : 2))].getValue(ctx);
 }
 }
diff --git a/java/org/apache/el/parser/AstConcatenation.java 
b/java/org/apache/el/parser/AstConcatenation.java
index f26e0a3..ae83893 100644
--- a/java/org/apache/el/parser/AstConcatenation.java
+++ b/java/org/apache/el/parser/AstConcatenation.java
@@ -19,6 +19,7 @@ package org.apache.el.parser;
 
 import jakarta.el.ELException;
 
+import org.apache.el.lang.ELSupport;
 import org.apache.el.lang.EvaluationContext;
 
 public class AstConcatenation extends SimpleNode {
@@ -31,8 +32,8 @@ public class AstConcatenation extends SimpleNode {
 @Override
 public Object getValue(EvaluationContext ctx) throws ELException {
 // Coerce the two child nodes to string and then concatenate
-String s1 = coerceToString(ctx, children[0].getValue(ctx));
-String s2 = coerceToString(ctx, children[1].getValue(ctx));
+String s1 = ELSupport.coerceToString(ctx, children[0].getValue(ctx));
+String s2 = ELSupport.coerceToString(ctx, children[1].getValue(ctx));
 return s1 + s2;
 }
 
diff --git a/java/org/apache/el/parser/AstEqual.java 
b/java/org/apache/el/parser/AstEqual.java
index a5a45cf..4a9b53e 100644
--- a/java/org/apache/el/parser/AstEqual.java
+++ b/java/org/apache/el/parser/AstEqual.java
@@ -19,6 +19,7 @@ package org.apache.el.parser;
 
 import jakarta.el.ELException;
 
+import org.apache.el.lang.ELSupport;
 import org.apache.el.lang.EvaluationContext;
 
 
@@ -35,6 +36,6 @@ public final class AstEqua

Re: [tomcat] 03/03: Add support for coercing LambdaExpression to any functional interface

[Mark Thomas]

On 08/07/2021 22:05, 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

commit 2fcb104294b2676154cb08f00d5665d668792280
Author: Mark Thomas 
AuthorDate: Thu Jul 8 22:02:26 2021 +0100

 Add support for coercing LambdaExpression to any functional interface


The implementation for this turned out to be a lot simpler than I 
initially thought. I can;t help be think I've missed something. Please 
try and find ways to break this. If you do, feel free to add a disabled 
out test case and I'll take a look.


Thanks,

Mark

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

[tomcat] branch main updated: Slightly more interesting test case

[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 cd6be41  Slightly more interesting test case
cd6be41 is described below

commit cd6be41aa22e9ceda43089ddeab98dc79cc9be7b
Author: Mark Thomas 
AuthorDate: Thu Jul 8 22:37:50 2021 +0100

Slightly more interesting test case
---
 test/org/apache/el/lang/TestELSupport.java | 20 
 1 file changed, 20 insertions(+)

diff --git a/test/org/apache/el/lang/TestELSupport.java 
b/test/org/apache/el/lang/TestELSupport.java
index 672afd5..2cf1217 100644
--- a/test/org/apache/el/lang/TestELSupport.java
+++ b/test/org/apache/el/lang/TestELSupport.java
@@ -19,6 +19,7 @@ package org.apache.el.lang;
 import java.beans.PropertyEditorManager;
 import java.math.BigDecimal;
 import java.math.BigInteger;
+import java.util.function.BiPredicate;
 import java.util.function.Predicate;
 
 import jakarta.el.ELException;
@@ -324,6 +325,15 @@ public class TestELSupport {
 }
 
 
+@Test
+public void testCoercetoFunctionalInterface06() throws Exception {
+final ELProcessor elp = new ELProcessor();
+elp.defineFunction("", "", "org.apache.el.lang.TestELSupport", 
"testBiPredicateA");
+Object result = elp.eval("testBiPredicateA((x,y) -> 
x.name().equals('VALA1') && y)");
+Assert.assertEquals("PASS", result);
+}
+
+
 public static String testPredicateA(Predicate filter) {
 String s = "data";
 if (filter.test(s)) {
@@ -352,4 +362,14 @@ public class TestELSupport {
 return "BLOCK";
 }
 }
+
+
+public static String testBiPredicateA(BiPredicate 
filter) {
+// Mainly interested in if these coerce correctly
+if (filter.test(TestEnumC.VALA1, Boolean.TRUE)) {
+return "PASS";
+} else {
+return "BLOCK";
+}
+}
 }

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