Istvan Toth

This is a simple correctness issue. These methods are called from a few places, but there is a reason for each call, and at least the callAs() and doPrivileged() calls...

Specifically, for JDK 17 the code won't find the new callAs() method, because it was added in 18, and then won't even try the new API if the jetty property...

> We should probably have a Jetty SecurityUtils.callAs() method option. > I wonder how hard it would be to move usages of SecurityUtils.doAs() to this new non-deprecated javax.security.auth.Subject.callAs(Subject, Callable) replacement?...

However, Subject.doAs() is so old, that I gave up trying to figure when it was added. It has certainly been present in Java 7 : https://docs.oracle.com/javase/7/docs/api/javax/security/auth/Subject.html#doAs(javax.security.auth.Subject,%20java.security.PrivilegedAction)

Regarding doPriviliged() Now that we are talking about it, I remember how it broke SPNEGO support in Avatica when Jetty added it. I had to add a new ThreadFactory that...

Because you referred 12.0 behaviour, I want to stress that this problem only exists in 12.1.x and the problematic code was added qute recently in: https://github.com/jetty/jetty.project/commit/12db285f178fcaa8d9d6e1a208030eb11a35d751 What I propose is...

Fix has been committed. Thank you.

Has anyone looked at what Hadoop uses this for ?

Looking at https://github.com/apache/hadoop/pull/5087 this seems to have the potential to break Phoenix in rare cases. While I'm not wild about managing versions for transitive dependencies, in this case I would...

We are certainly not referring the classes directly, and based on the test results it is not needed for any of our test cases either. I am not familiar with...