Change Java EE to Jakarta EE

Signed-off-by: Jonathan Coustick <jonathan.coustick@payara.fish>

spec/src/main/asciidoc/authenticationMechanism.asciidoc

@@ -12,9 +12,9 @@ During authentication, the caller presents proof of identity -- a token or crede
 
 In some cases (for example, username/password authentication) the interaction between the caller and the application is simple. In other cases, a lengthier dialog is required -- an application may send a random nonce to the caller, which must then use that nonce in the construction of an authentication token, or there may be interactions with a third party that vouches for the caller's identity, or the authenticity of the provided credential.
 
-The Java EE Platform already specifies mechanisms for authenticating users of web applications. JSR-340, "Java Servlet Specification", version 3.1 [https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html[SERVLET31]] specifies a declarative mechanism for configuring an application to provide BASIC, DIGEST, FORM, or CERT authentication, with authentication performed automatically by the container based on the application's configuration, which, in the case of FORM authentication, can include custom form pages.
+The Jakarta EE Platform already specifies mechanisms for authenticating users of web applications. JSR-340, "Java Servlet Specification", version 3.1 [https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html[SERVLET31]] specifies a declarative mechanism for configuring an application to provide BASIC, DIGEST, FORM, or CERT authentication, with authentication performed automatically by the container based on the application's configuration, which, in the case of FORM authentication, can include custom form pages.
 
-In addition, [https://jcp.org/aboutJava/communityprocess/mrel/jsr196/index2.html[JASPIC]] specifies a general-purpose mechanism for securing messages sent between Java EE clients and servers. JASPIC defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. [https://jcp.org/aboutJava/communityprocess/mrel/jsr196/index2.html[JASPIC]] also defines the Servlet Container Profile, which specifies how JASPIC mechanisms, including _ServerAuthModules_, are integrated with the servlet container.
+In addition, [https://jcp.org/aboutJava/communityprocess/mrel/jsr196/index2.html[JASPIC]] specifies a general-purpose mechanism for securing messages sent between Jakarta EE clients and servers. JASPIC defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. [https://jcp.org/aboutJava/communityprocess/mrel/jsr196/index2.html[JASPIC]] also defines the Servlet Container Profile, which specifies how JASPIC mechanisms, including _ServerAuthModules_, are integrated with the servlet container.
 
 While both existing mechanisms are important and useful, each has limitations from the point of view of an application developer. The servlet container's _login-config_ mechanism is limited to the _auth-method_ types defined by [https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html[SERVLET31]] -- it doesn't support other credential types, or complex interactions with callers. It also relies on unspecified container mechanisms to associate identity stores with applications. There is no way for an application to ensure that callers are authenticated against the desired identity store, or, indeed, against _any_ identity store.
 
@@ -69,7 +69,7 @@ See javadoc for a detailed description of _HttpMessageContext_ and _HttpMessageC
 
 === Installation and Configuration
 
-An _HttpAuthenticationMechanism_ must be a CDI bean, and is therefore visible to the container through CDI if it is packaged in a bean archive, which generally includes Java EE modules and application archives, as well as other archives and classes that are not part of an application, but are required by the Java EE specification to be visible to applications. See the CDI specification for details on bean archives and bean discovery. An _HttpAuthenticationMechanism_ is assumed to be normal scoped.
+An _HttpAuthenticationMechanism_ must be a CDI bean, and is therefore visible to the container through CDI if it is packaged in a bean archive, which generally includes Jakarta EE modules and application archives, as well as other archives and classes that are not part of an application, but are required by the Java EE specification to be visible to applications. See the CDI specification for details on bean archives and bean discovery. An _HttpAuthenticationMechanism_ is assumed to be normal scoped.
 
 It MUST be possible for the definition of an _HttpAuthenticationMechanism_ to exist within the application archive. Alternatively such definition MAY also exists outside the application archive, for example in a jar added to the classpath of an application server.
 
@@ -91,7 +91,7 @@ When an _HttpAuthenticationMechanism_ is placed in service, the container MUST N
 
 === Annotations and Built-In HttpAuthenticationMechanism Beans
 
-A Java EE container MUST support built-in beans for the following _HttpAuthenticationMechanism_ types, to be made available via configuration:
+A Jakarta EE container MUST support built-in beans for the following _HttpAuthenticationMechanism_ types, to be made available via configuration:
 
 * BASIC - Authenticates according to the mechanism as described in 13.6.1, "HTTP Basic Authentication", in [https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html[SERVLET31]]. See also RFC 7617, "The 'Basic' HTTP Authentication Scheme" [https://tools.ietf.org/html/rfc7617[RFC7617]]. This bean is activated and configured via the _@BasicAuthenticationMechanismDefinition_ annotation.
 * FORM - Authenticates according to the mechanism as described in 13.6.3, "Form Based Authentication", in [https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html[SERVLET31]]. This bean is activated and configured via the _@FormAuthenticationMechanismDefinition_ annotation.
@@ -353,7 +353,7 @@ If an application provides an _HttpAuthenticationMechanism_, and also configures
 
 ==== Custom FORM Notes ====
 
-The Custom FORM variant is intended to align better with modern Java EE technologies such as CDI, Expression Language, Bean Validation and specifically JSF.
+The Custom FORM variant is intended to align better with modern Jakarta EE technologies such as CDI, Expression Language, Bean Validation and specifically JSF.
 
 Below is an example showing how the mechanism can be used with those technologies.
 
@@ -462,7 +462,7 @@ httpMessageContext.getHandler().handle(new Callback[] {
 
 === Relationship to other specifications
 
-An _HttpAuthenticationMechanism_ is a CDI bean, as defined by JSR-346, "Contexts and Dependency Injection for the Java EE platform", version 1.2 [https://jcp.org/aboutJava/communityprocess/mrel/jsr346/index.html[CDI12]].
+An _HttpAuthenticationMechanism_ is a CDI bean, as defined by JSR-346, "Contexts and Dependency Injection for the Jakarta EE platform", version 1.2 [https://jcp.org/aboutJava/communityprocess/mrel/jsr346/index.html[CDI12]].
 
 The methods defined by the _HttpAuthenticationMechanism_ closely map to the methods and semantics of a _ServerAuthModule_, as defined by the Servlet Container Profile of [https://jcp.org/aboutJava/communityprocess/mrel/jsr196/index2.html[JASPIC]]. (But an _HttpAuthenticationMechanism_ is itself not a _ServerAuthModule_.) The servlet container MUST use JASPIC mechanisms to arrange for an _HttpAuthenticationMechanism_ to be placed in service.
 

spec/src/main/asciidoc/concepts.asciidoc

@@ -35,17 +35,17 @@ The following general requirements are defined by this specification.
 
 ==== Group-To-Role Mapping
 
-Various Java EE specifications define how roles are declared for an application, and how access to application resources can be restricted to users that have a specific role. The specifications are largely silent on the question of how users are assigned to roles, however. Most application servers have proprietary mechanisms for determining the roles a user has.
+Various Jakarta EE specifications define how roles are declared for an application, and how access to application resources can be restricted to users that have a specific role. The specifications are largely silent on the question of how users are assigned to roles, however. Most application servers have proprietary mechanisms for determining the roles a user has.
 
 Application servers MUST provide a default mapping from group names to roles. That is, a caller who is a member of group "foo" is considered to have role "foo". This default mapping MAY be overridden by explicit proprietary configuration, but, when not overridden, provides sensible and predictable behavior for portable applications.
 
 An application server MAY provide a default mapping from caller principal names to roles. That is, a caller with the name "bar" is considered to have role "bar". This default mapping MAY be overridden by proprietary configuration.
 
 ==== Caller Principal Types
 
-This specification defines a principal type called _CallerPrincipal_ to represent the identity of an application caller. Historically, application servers have used different principal types to represent an application's callers, and various Java EE specifications (e.g., JASPIC), provide abstractions to accommodate, "the container's representation of the caller principal".
+This specification defines a principal type called _CallerPrincipal_ to represent the identity of an application caller. Historically, application servers have used different principal types to represent an application's callers, and various Jakarta EE specifications (e.g., JASPIC), provide abstractions to accommodate, "the container's representation of the caller principal".
 
-This specification RECOMMENDS that Java EE application servers that rely on container-specific caller principal types derive those types by extending _CallerPrincipal_, so that portable applications can rely on a consistent representation of the caller principal.
+This specification RECOMMENDS that Jakarta EE application servers that rely on container-specific caller principal types derive those types by extending _CallerPrincipal_, so that portable applications can rely on a consistent representation of the caller principal.
 
 However, we also distinguish here between a "container caller principal" and an "application caller principal", and explicitly allow for each to be represented by a different _Principal_ type.
 

spec/src/main/asciidoc/identityStore.asciidoc

@@ -8,7 +8,7 @@ This chapter describes the _IdentityStore_ and _IdentityStoreHandler_ interfaces
 
 _IdentityStore_ provides an abstraction of an identity store, which is a database or directory (store) of identity information about a population of users that includes an application's callers. An identity store holds caller names, group membership information, and information sufficient to allow it to validate a caller's credentials. An identity store may also contain other information, such as globally unique caller identifiers (if different from caller name), or other caller attributes.
 
-Implementations of the _IdentityStore_ interface are used to interact with identity stores to authenticate users (i.e., validate their credentials), and to retrieve caller groups. _IdentityStore_ is roughly analogous to the JAAS _LoginModule_ interface, which is often integrated into Java EE products (albeit in vendor-specific ways). Unlike _LoginModule_, _IdentityStore_ is intended specifically for Java EE, and provides only credential validation and group retrieval functions (i.e., functions that require interaction with an identity store). An _IdentityStore_ does not collect caller credentials, or manipulate __Subject__s.
+Implementations of the _IdentityStore_ interface are used to interact with identity stores to authenticate users (i.e., validate their credentials), and to retrieve caller groups. _IdentityStore_ is roughly analogous to the JAAS _LoginModule_ interface, which is often integrated into Jakarta EE products (albeit in vendor-specific ways). Unlike _LoginModule_, _IdentityStore_ is intended specifically for Java EE, and provides only credential validation and group retrieval functions (i.e., functions that require interaction with an identity store). An _IdentityStore_ does not collect caller credentials, or manipulate __Subject__s.
 
 _IdentityStore_ is intended primarily for use by _HttpAuthenticationMechanism_ implementations, but could in theory be used by other types of authentication mechanisms (e.g., a JASPIC _ServerAuthModule_, or a container's built-in authentication mechanisms). _HttpAuthenticationMechanism_ implementations are not required to use _IdentityStore_ -- they can authenticate users in any manner they choose -- but _IdentityStore_ will often be a useful and convenient mechanism.
 
@@ -265,7 +265,7 @@ As described above, in the "<<Declaring Capabilities>>" section, the _IdentitySt
 
 === Annotations and Built-In IdentityStore Beans
 
-A Java EE container MUST support built-in beans for the following _IdentityStore_ types, to be configured and made available via corresponding annotations:
+A Jakarta EE container MUST support built-in beans for the following _IdentityStore_ types, to be configured and made available via corresponding annotations:
 
 * LDAP -- Supports caller data that is stored in an external LDAP server. This bean is activated and configured via the _@LdapIdentityStoreDefinition_ annotation.
 * Database -- Supports caller data that is stored in an external database accessible via a DataSource bound to JNDI. This bean is activated and configured via the _@DatabaseIdentityStoreDefinition_ annotation.

spec/src/main/asciidoc/preface.asciidoc

@@ -5,7 +5,7 @@
 
 == Preface
 
-This document is the Java EE Security API Specification, version 1.0.
+This document is the Jakarta EE Security API Specification, version 1.0.
 
 === Notational Conventions
 

spec/src/main/asciidoc/securityContext.asciidoc

@@ -6,7 +6,7 @@ This chapter describes the _SecurityContext_ interface and contract.
 
 === Introduction
 
-The Java EE platform defines a declarative security model for protecting application resources. The declared constraints on access are then enforced by the container. In some cases the declarative model is not sufficient; for example, when a combination of tests and constraints is needed that is more complex than the declarative model allows for. Programmatic security allows an application to perform tests and grant or deny access to resources. 
+The Jakarta EE platform defines a declarative security model for protecting application resources. The declared constraints on access are then enforced by the container. In some cases the declarative model is not sufficient; for example, when a combination of tests and constraints is needed that is more complex than the declarative model allows for. Programmatic security allows an application to perform tests and grant or deny access to resources. 
 
 This specification provides an access point for programmatic security -- a security context -- represented by the _SecurityContext_ interface.
 
@@ -87,7 +87,7 @@ The _authenticate()_ method allows an application to signal to the container tha
 
 The _SecurityContext_ implementation is a CDI bean, as defined by [https://jcp.org/aboutJava/communityprocess/mrel/jsr346/index.html[CDI12]].
 
-Various specifications in Java EE provide similar or even identical methods to those provided be the _SecurityContext_. It is the intention of this specification to eventually supersede those methods and provide a cross-specification, platform alternative. The following gives an overview:
+Various specifications in Jakarta EE provide similar or even identical methods to those provided be the _SecurityContext_. It is the intention of this specification to eventually supersede those methods and provide a cross-specification, platform alternative. The following gives an overview:
 
 * Servlet - _HttpServletRequest#getUserPrincipal_, _HttpServletRequest#isUserInRole_
 * EJB - _EJBContext#getCallerPrincipal_, _EJBContext#isCallerInRole_