| 
Hi Arjan, 
 
As per context of the current email thread, Please advice me on the following: 
 
Question 1: 
 
Can the Jakarta Security Authorization API be used by an application server to enforce the default set of permissions specified in the Connector Specification 2.1, without relying on a SecurityManager? 
 
Question 2: 
 
Are there Authorization APIs available that can help enforce the SecurityPermission SPI, as defined in the Connector Specification, without the need for a SecurityManager? 
 
connector 2.1 annotation:  
 
 
regards, 
Guru 
 From: Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>Sent: 20 November 2024 18:11
 To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
 Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
 Subject: Re: [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency
   
 
Connector 2.1 specification violates Jakarta EE 11 Platform specification by stating that  "An application server must provide a set of security permissions for executing a resource adapter in a managed runtime environment. A resource adapter must be granted
 explicit permissions to access system resources". 
 
These specific requirements in Platform EE 11 Spec and Connector 2.1 are conflicting with each other. 
 
regards, 
Guru 
 
 
 From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Brian Stansberry via jakartaee-platform-dev
 <jakartaee-platform-dev@xxxxxxxxxxx>Sent: 13 November 2024 23:01
 To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
 Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
 Subject: Re: [jakartaee-platform-dev] [External] : Re: Jakarta Connectors removal of Security Manager dependency
   If a spec, xsd etc is discussing behavior that is driven by the Security Manager it seems to me that that behavior is only relevant when there is a working SM in the runtime. Specs may not
 have explicitly stated that, because it was just understood. This is nothing new as most EE workloads are executed in runtimes without the SM enabled. 
 JEP 486 is saying there won't be a working SM anymore in SE 24, but it's not going to cause calls to the SM APIs to fail. So applications running on SE 24 are working in the same basic situation
 as those that have been running for decades now in runtimes that don't have the SM enabled. So I don't see a problem here when it comes to specs, xsds etc. Something to clean up in the future, but not a problem now. 
 TCKs are a different matter. If an EE 11 implementation needs to run a particular TCK in order to certify, then there needs to be a way to exclude tests that require an SM. AIUI such tests
 are being removed from the EE 11 platform TCK. 
 
Jakarta EE 11 requires Java 17 as a baseline, but we can not prevent end users from using a newer JDK in their environment. JDK 24 includes a couple of new language features, which are very attractive for developers. And when JDK
 24 is released, all Jakarta EE providers should be ready for the new product for Jakarta EE 11. 
 I remember the *removal of the Security Manager* was a task in the initial discussion of Jakarta EE 11.  Now that WildFly/OpenLiberty is aligned with the Jakarta EE 11 core profile,  the Jakarta
 EE platform profile is not finalized yet, there is still some room to do the cleanup of the Security Manager. --- Regards, Hantsy Bai Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker GitHub: 
https://github.com/hantsy Twitter: 
https://twitter.com/@hantsy 
 
 
Jakarta EE  releases are open-ended, Jakarta EE 11 release minimum Java  SE is  17. 
 
 
regards, 
Guru 
 Thanks for pointing this out.  It will be important for Jakarta EE 12.  I do not believe it impacts Jakarta EE 11 because Jakarta EE 11 aligns with Java SE 21 and
 17, not 24.   
 
 -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His |