Thanks Sean.
It's a pity we're not permitted to redesign a light weight authorization
mechanism from the ashes of the existing system, something that allowed
the use of PrivilegedAction et al.
The reality is, authorization could be so much simpler and more useful
than it is today, especially
See also https://bugs.openjdk.org/browse/JDK-8296244
--Sean
On 6/16/23 1:48 AM, Alan Bateman wrote:
On 16/06/2023 03:48, Peter Firmstone wrote:
:
As it isn't yet clear how a Subject context will be preserved across
threads in future version of OpenJDK, (currently we use the
AccessControlConte
Thanks Alan,
That's quite interesting. Often we use Executor tasks to perform event
notifications to listeners, context is the same across many, in fact we
do this for distributed garbage collection over TLS connections too.
--
Regards,
Peter
On 16/06/2023 3:48 pm, Alan Bateman wrote:
On 16/06/2023 03:48, Peter Firmstone wrote:
:
As it isn't yet clear how a Subject context will be preserved across
threads in future version of OpenJDK, (currently we use the
AccessControlContext for that), for example we capture the existing
context, to establish TLS connections in call back
Release Note: Alternate Subject.getSubject and doAs APIs Created That
Do Not Depend on Security Manager APIs
https://bugs.openjdk.org/browse/JDK-8280491
Just wondering about the future implementation plans for these new API's?
The implementation depends on deprecated for removal API's in JEP
