Messaging ServerText is not SVG - cannot display
\ No newline at end of file
diff --git a/src/main/antora/modules/intro/images/multitier-app.vsdx b/src/main/antora/modules/intro/images/multitier-app.vsdx
new file mode 100644
index 00000000..1a30ab7c
Binary files /dev/null and b/src/main/antora/modules/intro/images/multitier-app.vsdx differ
diff --git a/src/main/antora/modules/intro/images/simple-app.drawio b/src/main/antora/modules/intro/images/simple-app.drawio
new file mode 100644
index 00000000..1b3c635b
--- /dev/null
+++ b/src/main/antora/modules/intro/images/simple-app.drawio
@@ -0,0 +1,41 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/main/antora/modules/intro/images/simple-app.svg b/src/main/antora/modules/intro/images/simple-app.svg
new file mode 100644
index 00000000..f2a6d263
--- /dev/null
+++ b/src/main/antora/modules/intro/images/simple-app.svg
@@ -0,0 +1,4 @@
+
+
+
+
Jakarta EE Server or Executable "fat" JAR file
Jakarta EE Server or...
Container (Web, CDI, Enterprise Bean services)
Container (Web, CDI, Enterpr...
Application Code
Application C...
Data Store
Data Store
Client (Web Service, Browser, so on)
Client...Text is not SVG - cannot display
\ No newline at end of file
diff --git a/src/main/antora/modules/intro/images/simple-app.vsdx b/src/main/antora/modules/intro/images/simple-app.vsdx
new file mode 100644
index 00000000..1d04fb22
Binary files /dev/null and b/src/main/antora/modules/intro/images/simple-app.vsdx differ
diff --git a/src/main/antora/modules/intro/pages/overview/overview-containers.adoc b/src/main/antora/modules/intro/pages/overview/overview-containers.adoc
new file mode 100644
index 00000000..b031f5bc
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-containers.adoc
@@ -0,0 +1,45 @@
+== Jakarta EE Containers and Servers
+
+The services we discussed in <<_jakarta_ee_services>> section are provided by *container{empty}footnote:[Technically, there are multiple containers (Web, CDI, Enterprise Beans), but the distinction about which container is providing the services isn't terribly important. Jakarta EE also supports an Application Client container for Java clients, but this is rarely used. ]*.
+A *Jakarta EE Server* is software that runs the container, deploys applications into into it, and provides administration and additional features.
+Jakarta EE Servers run stand-alone, but many implementations also support the ability to generate a single "fat",
+executable Java Archive (JAR) file that includes all the code necessary to run the application.
+
+.Jakarta EE Containers vs Docker Containers
+****
+_Container_ is a commonly used term in computing, but it basically means "that which holds something".
+In the case of Jakarta EE, the container "holds," or more accurately,
+executes your code and provides low-level application services,
+such as dependency injection, transactions, HTTP request handling, REST support, and so on.
+In the case of Docker container (which is technically an Object Computing Initiative,
+or OCI container) your application is executed inside it,
+but the container provides operating system services, such as disk and network I/O.
+
+While the two container types are different,
+it's entirely possible (and common) to run a Jakarta EE application inside a Docker container.
+****
+The figure below shows how the application code, container, and Jakarta EE Server are related:
+
+image::container-services.svg[ "Relationship between containers, serveris, and your code."]
+
+In a simple case, an application might look like this:
+
+image::simple-app.svg[ "Simple Jakarta EE Application"]
+
+However, a single Jakarta EE Server can run multiple applications,
+and applications can communicate with each other remotely.
+So you can create more complicated scenarios, as shown below:
+
+image::multitier-app.svg[ "More Complex Jakarta EE Application"]
+
+NOTE: Even though the figures above show communication between multiple Jakarta EE applications,
+they can and often do communicate with non-Jakarta EE applications via messaging or streaming servers, REST, and so on.
+
+Regardless of how simple or complicated your system architecture is,
+a key benefit of Jakarta EE is that container services are configurable.
+This means the same component can behave differently based on where it's deployed.
+The container also manages non-configurable services, such as the lifecycle of components,
+database connection resource pooling, data persistence, and access to the Jakarta EE APIs.
+
+
+
diff --git a/src/main/antora/modules/intro/pages/overview/overview-highlights.adoc b/src/main/antora/modules/intro/pages/overview/overview-highlights.adoc
new file mode 100644
index 00000000..4d152ee7
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-highlights.adoc
@@ -0,0 +1,30 @@
+// This file should always contain the highlights for the current version of Jakarta EE.
+
+== Jakarta EE 10 Platform Highlights
+
+Jakarta EE 10 is the first feature release of the platform since it moved to the Eclipse Foundation in 2017.
+The key emphasis of this release is better alignment with Java SE and creation of a new lightweight Core profile,
+which can be easily consumed by other standards such as https://microprofile.io/[MicroProfile^].
+
+Here are some highlights:
+
+* CDI Alignment
+** `@Asynchronous` in Jakarta Concurrency
+** Better CDI support in Jakarta Batch
+* Java SE Alignment
+** Support for Java SE 11 and 17
+** `CompletionStage`, `ForkJoinPool`, parallel streams in Jakarta Concurrency
+** Bootstrap APIs for Jakarta REST
+* Closing standardization gaps
+** OpenID Connect support in Jakarta Security
+** UUID as entity keys, more SQL support in Jakarta Persistence queries
+** Multipart/form-data support in Jakarta REST
+** `@ClientWindowScoped` and Facelet pure Java views in Jakarta Faces
+** New Core Profile that includes Jakarta CDI Light to enable next generation cloud native runtimes; used by MicroProfile
+** Jakarta Concurrency has moved to the Web Profile
+* Deprecation/removal
+** `@Context` annotation in Jakarta REST
+** EJB Entity Beans
+** Embeddable EJB container
+** Deprecated features in Jakarta Servlet, Jakarta Faces, and Jakarta CDI
+
diff --git a/src/main/antora/modules/intro/pages/overview/overview-how-do-i-get-it.adoc b/src/main/antora/modules/intro/pages/overview/overview-how-do-i-get-it.adoc
new file mode 100644
index 00000000..3d5835bf
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-how-do-i-get-it.adoc
@@ -0,0 +1,13 @@
+== How do I get Jakarta EE?
+
+Since Jakarta EE is an open-source industry standard, there are multiple implementations.
+A good place to start is the https://start.jakarta.ee/[Jakarta EE Starter],
+which lets you quickly generate a sample starter app using one of the supported Jakarta EE servers.
+You can also find the most recent list of servers on the https://jakarta.ee/compatibility/[Jakarta EE website].
+
+If you are working with a Open Container Initiative (OCI)-compliant (i.e., Docker-compatible) containers,
+most of these vendors also provide images.
+
+If you are using a cloud provider,
+you may also want to check to see if they have additional support, guides, or managed Jakarta EE servers.
+
diff --git a/src/main/antora/modules/intro/pages/overview/overview-jakartaee-components.adoc b/src/main/antora/modules/intro/pages/overview/overview-jakartaee-components.adoc
new file mode 100644
index 00000000..c55c2dda
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-jakartaee-components.adoc
@@ -0,0 +1,21 @@
+=== Jakarta EE Components
+
+Jakarta EE applications are made up of components. A *Jakarta EE component* is a self-contained functional unit that
+makes use of one or more container services.
+That usage could be as simple as injecting a single dependency
+or responding to REST requests, or as complicated as
+injecting multiple dependencies, querying a database, firing and event, and participating in distributed transactions.
+
+Jakarta EE supports the following components:
+
+* *Web components{empty}footnote:[Not to be confused with the web browser standard, https://developer.mozilla.org/en-US/docs/Web/API/Web_Components[Web Components], or user interface widgets in general, which are often called UI components.]* interact with web standards (HTTPS, HTML, WebSocket, and so on) using Jakarta Servlet, Jakarta Faces, Jakarta WebSocket, and related technologies.
+* Business components implement logic necessary to support the business domain using either *Enterprise bean components (enterprise beans)*{empty}footnote:[Enterprise Beans previously supported persistence via Entity Beans, but that has been deprecated in favor of Jakarta Persistence] or CDI managed beans.
+** For new applications, business components should be implemented using CDI managed beans,
+unless you need Enterprise bean-specific features such as transactions, role-based security,
+messaging driven beans, or remote execution.
+The two technologies play well together.
+
+All of these components run on the *server{empty}footnote:[Application Clients are
+technically supported as well, although they are rarely used.]*,
+and are ordinary Java classes written with Jakarta EE annotations (or optionally,
+external configuration files called deployment descriptors).
diff --git a/src/main/antora/modules/intro/pages/overview/overview-jakartaee-services.adoc b/src/main/antora/modules/intro/pages/overview/overview-jakartaee-services.adoc
new file mode 100644
index 00000000..308b0a3f
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-jakartaee-services.adoc
@@ -0,0 +1,86 @@
+== Jakarta EE Services
+
+Jakarta EE provides a wide range of services, organized into three main categories.
+Each category is implemented by one of three profiles.
+The Core profile contains the foundational services.
+The Web profile contains the Core profile plus services for writing web applications.
+The Platform contains the Core and Web profiles, plus additional services for mail, batch processing,
+and messaging, and more.
+
+The table below lists each high-level service, the specification that provides it, and the profile that contains it:
+
+[cols="1,1,1"]
+|===
+|Service |Specification |Profile
+
+|Dependency injection
+|Jakarta Contexts and Dependency Injection (CDI) Lite
+|Core
+
+|RESTful web services
+|Jakarta REST (formerly JAX-RS)
+|Core
+
+|JSON processing
+|Jakarta JSON Binding (JSON-B) and Jakarta JSON Processing (JSON-P)
+|Core
+
+|Advanced dependency injection
+|Jakarta Contexts and Dependency Injection (CDI) Full
+|Web
+
+|Validation
+|Jakarta Validation (Bean Validation)
+|Web
+
+|Security
+|Jakarta Security
+|Web
+
+|HTTP request handling
+|Jakarta Servlet
+|Web
+
+|Server-side web applications
+|Jakarta Faces (formerly JavaServer Faces, or JSF)
+|Web
+
+|WebSocket request handling
+|Jakarta WebSocket
+|Web
+
+|Relational data persistence
+|Jakarta Persistence (formerly JPA)
+|Web
+
+|Application components
+|Jakarta Enterprise Beans Lite (formerly EJB Lite)
+|Web
+
+|Transactions
+|Jakarta Transactions
+|Web
+
+|Managed concurrency
+|Jakarta Concurrency
+|Web
+
+|Email handling
+|Jakarta Mail
+|Platform
+
+|Messaging
+|Jakarta Messaging
+|Platform
+
+|Batch processing
+|Jakarta Batch
+|Platform
+
+|===
+
+As you work with Jakarta EE, you'll encounter other services that support the ones listed above.
+
+Each service is provided by one or more APIs, which are defined in Jakarta EE specifications.
+The specifications provide details for users and implementors of the service.
+You can find a https://jakarta.ee/specifications/[full list of the Jakarta EE specifications] on the Jakarta EE site.
diff --git a/src/main/antora/modules/intro/pages/overview/overview-javase-dependencies.adoc b/src/main/antora/modules/intro/pages/overview/overview-javase-dependencies.adoc
new file mode 100644
index 00000000..63af4d7c
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-javase-dependencies.adoc
@@ -0,0 +1,31 @@
+== Usage of Java Standard Edition (SE) APIs
+
+In addition to many of the core Java programming language APIs,
+there are a couple of key APIs you may encounter when working with Jakarta EE:
+Java Database Connectivity (JDBC) and Java Naming and Directory Interface (JNDI).
+
+=== Java Database Connectivity API
+
+The Java Database Connectivity (JDBC) API lets you work with SQL databases.
+You can use the JDBC API directly from within a Jakarta EE component,
+but most Jakarta EE applications use xref:persist:persistence-intro/persistence-intro.adoc[Jakarta Persistence]
+to map between objects and database tables.
+Jakarta EE servers also support managed JDBC data sources, which can be configured for one or more applications.
+
+=== Java Naming and Directory Interface API
+
+The Java Naming and Directory Interface (JNDI) API allows you to work with multiple naming and directory services,
+such as LDAP, DNS, and NIS.
+The API has methods for performing standard directory operations,
+such as associating attributes with objects and searching for objects using their attributes.
+Using JNDI, a Jakarta EE application can store and retrieve any type of named Java object, allowing Jakarta EE applications to coexist with many legacy applications and systems.
+
+Jakarta EE servers provide a naming environment for Jakarta EE components.
+This environment allows a component to be customized without the need to access or change the component's source code.
+A container implements the component's environment and provides it to the component as a JNDI naming context.
+
+The naming environment provides four logical namespaces: `java:comp`, `java:module`, `java:app`, and `java:global` for objects available to components, modules, or applications or shared by all deployed applications.
+A Jakarta EE component can access named system-provided and user-defined objects. The names of some system-provided objects, such as a default JDBC `DataSource` object, a default Messaging connection factory, and a Transactions `UserTransaction` object, are stored in the `java:comp` namespace.
+
+You can also create your own objects, such as enterprise beans, environment entries, JDBC `DataSource` objects, and messaging destinations.
+
diff --git a/src/main/antora/modules/intro/pages/overview/overview-what-is-jakarta-ee.adoc b/src/main/antora/modules/intro/pages/overview/overview-what-is-jakarta-ee.adoc
new file mode 100644
index 00000000..239e803d
--- /dev/null
+++ b/src/main/antora/modules/intro/pages/overview/overview-what-is-jakarta-ee.adoc
@@ -0,0 +1,28 @@
+== What is Jakarta EE?
+
+Jakarta EE is a collection of services that help you write enterprise applications that run on the Java Platform.
+It provides the infrastructure often required for these applications
+so you that you can focus on core features and business logic.
+
+*Enterprise applications* support the high levels of security,
+scalability, and reliability that large organizations typically require.
+They can be web services, web applications, batch processes, and so on.
+
+The *Java Platform* consists of the Java Virtual Machine, compiler,
+standard APIs, and several tools that help you build, deploy, and debug Java applications.
+Java is the primary programming language, although the Java Platform supports several others, including Kotlin and Scala.
+Most Jakarta EE applications, however, are written in Java. The *Java Platform* is also called *Java Standard Edition (SE)*.
+
+With Jakarta EE, you can pick and choose which services you need,
+and you use them with or without other frameworks and libraries.
+One framework commonly used with Jakarta EE is https://microprofile.io[MicroProfile^],
+which provides additional features commonly used in microservices.
+
+A key benefit of Jakarta EE is that it's a set of open source standards supported by multiple vendors.
+Each vendor has their own implementation of the standards,
+and the vendors work together to update the standards over time.
+This means that you aren't locked into a particular vendor,
+and each standard is well-thought-out and based on existing patterns and practices.
+
+Jakarta EE is stable and mature, and used in tens of thousands of mission-critical enterprises applications worldwide;
+yet it has evolved over time to keep up with modern computing trends, such as cloud computing.
diff --git a/src/main/antora/modules/intro/pages/overview/overview.adoc b/src/main/antora/modules/intro/pages/overview/overview.adoc
index a9c50f0f..9b36726c 100644
--- a/src/main/antora/modules/intro/pages/overview/overview.adoc
+++ b/src/main/antora/modules/intro/pages/overview/overview.adoc
@@ -1,26 +1,26 @@
= Overview
-include::ROOT:partial$not_updated.adoc[]
+include::ROOT:partial$draft.adoc[]
-This chapter introduces you to Jakarta EE enterprise application development.
-Here you will review development basics, learn about the Jakarta EE architecture and APIs, become acquainted with important terms and concepts, and find out how to approach Jakarta EE application programming, assembly, and deployment.
+This chapter explains what Jakarta EE is, what features it provides, common terms,
+and how Jakarta EE applications are structured.
-include::overview001.adoc[]
+include::overview-highlights.adoc[]
-include::overview002.adoc[]
+include::overview-what-is-jakarta-ee.adoc[]
-include::overview003.adoc[]
+include::overview-jakartaee-services.adoc[]
-include::overview004.adoc[]
+include::overview-containers.adoc[]
-include::overview005.adoc[]
+include::overview-jakartaee-components.adoc[]
-include::overview006.adoc[]
+include::overview-javase-dependencies.adoc[]
-include::overview007.adoc[]
+include::overview-how-do-i-get-it.adoc[]
-include::overview008.adoc[]
+== Further Reading
-include::overview009.adoc[]
-
-include::overview010.adoc[]
+* https://jakarta.ee/[Jakarta EE Home Page]
+* https://jakarta.ee/about/jesp/[Jakarta EE Specification Process]
+* https://jakarta.ee/specifications/[Jakarta EE Specifications]
diff --git a/src/main/antora/modules/intro/pages/overview/overview001.adoc b/src/main/antora/modules/intro/pages/overview/overview001.adoc
deleted file mode 100644
index 860e2142..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview001.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-== Introduction to Jakarta EE
-
-Developers today increasingly recognize the need for distributed, transactional, and portable applications that leverage the speed, security, and reliability of server-side technology.
-Enterprise applications provide the business logic for an enterprise.
-They are centrally managed and often interact with other enterprise software.
-In the world of information technology, enterprise applications must be designed, built, and produced for less money, with greater speed, and with fewer resources.
-
-With Jakarta EE, development of Java enterprise applications has never been easier or faster.
-The aim of the Jakarta EE platform is to provide developers with a powerful set of APIs while shortening development time, reducing application complexity, and improving application performance.
-
-The Jakarta EE platform is developed through the Jakarta EE Specification Process.
-Expert groups composed of interested parties have created Jakarta Specifications to define the various Jakarta EE technologies.
-The work of the Jakarta Community under the Jakarta EE Specification Process program helps to ensure Java technology's standards of stability and cross-platform compatibility.
-
-The Jakarta EE platform uses a simplified programming model. XML deployment descriptors are optional.
-Instead, a developer can simply enter the information as an annotation directly into a Java source file, and the Jakarta EE server will configure the component at deployment and runtime.
-These annotations are generally used to embed in a program data that would otherwise be furnished in a deployment descriptor.
-With annotations, you put the specification information in your code next to the program element affected.
-
-In the Jakarta EE platform, dependency injection can be applied to all resources a component needs, effectively hiding the creation and lookup of resources from application code.
-Dependency injection can be used in enterprise bean containers, web containers, and application clients.
-Dependency injection allows the Jakarta EE container to automatically insert references to other required components or resources, using annotations.
-
-This tutorial uses examples to describe the features available in the Jakarta EE platform for developing enterprise applications.
-Whether you are a new or experienced enterprise developer, you should find the examples and accompanying text a valuable and accessible knowledge base for creating your own solutions.
diff --git a/src/main/antora/modules/intro/pages/overview/overview002.adoc b/src/main/antora/modules/intro/pages/overview/overview002.adoc
deleted file mode 100644
index a9c21fe3..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview002.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-== Jakarta EE 9 Platform Highlights
-
-The goal of the Jakarta EE 9 release is to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*.
-
-In addition, the Jakarta EE 9 release removes a small set of specifications from Jakarta EE 8 that were old, optional, or deprecated in order to reduce the surface area of the APIs to ensure that it is easier for new vendors to enter the ecosystem – as well as reduce the burden on implementation, migration, and maintenance of these old APIs.
-
-The following Jakarta EE Technologies were removed from the Jakarta EE Platform:
-
-* XML Registries 1.0
-
-* XML RPC 1.1
-
-* Deployment 1.7
-
-* Management 1.1
-
-* Distributed Interoperability (EJB 3.2 Core Specification, Chapter 10)
-
-Aside from the removed technologies, some technologies in Jakarta EE 9 release are marked as optional.
-The reason for this is that some of the technologies originally included in Jakarta EE are no longer as relevant as they were when they were introduced to the platform.
-
-Platform Specification Project can decide to officially "remove" the "optional" feature from the Platform in the next (or beyond) releases.
-
-The following technologies are optional:
-
-* Jakarta Enterprise Beans 3.2 and earlier entity beans and associated Jakarta Enterprise Beans QL
-
-* Jakarta Enterprise Beans 2.x API group
-
-* Jakarta Enterprise Web Services 2.0
-
-* Jakarta SOAP with Attachments 2.0
-
-* Jakarta Web Services Metadata 3.0
-
-* Jakarta XML Web Services 3.0
-
-* Jakarta XML Binding 3.0
diff --git a/src/main/antora/modules/intro/pages/overview/overview003.adoc b/src/main/antora/modules/intro/pages/overview/overview003.adoc
deleted file mode 100644
index 5c523392..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview003.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-== Jakarta EE Application Model
-
-The Jakarta EE application model begins with the Java programming language and the Java virtual machine.
-The proven portability, security, and developer productivity they provide form the basis of the application model.
-Jakarta EE is designed to support applications that implement enterprise services for customers, employees, suppliers, partners, and others who make demands on or contributions to the enterprise.
-Such applications are inherently complex, potentially accessing data from a variety of sources and distributing applications to a variety of clients.
-
-To better control and manage these applications, the business functions to support these various users are conducted in the middle tier.
-The middle tier represents an environment that is closely controlled by an enterprise's information technology department.
-The middle tier is typically run on dedicated server hardware and has access to the full services of the enterprise.
-
-The Jakarta EE application model defines an architecture for implementing services as multitier applications that deliver the scalability, accessibility, and manageability needed by enterprise-level applications.
-This model partitions the work needed to implement a multitier service into the following parts:
-
-* The business and presentation logic to be implemented by the developer
-
-* The standard system services provided by the Jakarta EE platform
-
-The developer can rely on the platform to provide solutions for the hard systems-level problems of developing a multitier service.
diff --git a/src/main/antora/modules/intro/pages/overview/overview004.adoc b/src/main/antora/modules/intro/pages/overview/overview004.adoc
deleted file mode 100644
index 346f0a9c..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview004.adoc
+++ /dev/null
@@ -1,134 +0,0 @@
-== Distributed Multitiered Applications
-
-The Jakarta EE platform uses a distributed multitiered application model for enterprise applications.
-Application logic is divided into components according to function, and the application components that make up a Jakarta EE application are installed on various machines depending on the tier in the multitiered Jakarta EE environment to which the application component belongs.
-
-<<_multitiered_applications>> shows two multitiered Jakarta EE applications divided into the tiers described in the following list. The Jakarta EE application parts shown in <<_multitiered_applications>> are presented in <<_jakarta_ee_components>>.
-
-* Client-tier components run on the client machine.
-
-* Web-tier components run on the Jakarta EE server.
-
-* Business-tier components run on the Jakarta EE server.
-
-* Enterprise information system (EIS)-tier software runs on the EIS server.
-
-Although a Jakarta EE application can consist of all tiers shown in <<_multitiered_applications>>, Jakarta EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three locations: client machines, the Jakarta EE server machine, and the database or legacy machines at the back end.
-Three-tiered applications that run in this way extend the standard two-tiered client-and-server model by placing a multithreaded application server between the client application and back-end storage.
-
-[[_multitiered_applications]]
-.Multitiered Applications
-image::common:jakartaeett_dt_001.svg[ "Diagram of multitiered application structure, including client tier, web tier, business tier, and EIS tier."]
-
-=== Security
-
-Although other enterprise application models require platform-specific security measures in each application, the Jakarta EE security environment enables security constraints to be defined at deployment time.
-The Jakarta EE platform makes applications portable to a wide variety of security implementations by shielding application developers from the complexity of implementing security features.
-
-The Jakarta EE platform provides standard declarative access control rules that are defined by the developer and interpreted when the application is deployed on the server.
-Jakarta EE also provides standard login mechanisms so that application developers do not have to implement these mechanisms in their applications.
-The same application works in a variety of security environments without changing the source code.
-
-=== Jakarta EE Components
-
-Jakarta EE applications are made up of components.
-A Jakarta EE component is a self-contained functional software unit that is assembled into a Jakarta EE application with its related classes and files and that communicates with other components.
-
-The Jakarta EE specification defines the following Jakarta EE components:
-
-* Application clients and applets are components that run on the client.
-
-* Jakarta Servlet, Jakarta Faces, and Jakarta Server Pages technology components are web components that run on the server.
-
-* Enterprise bean components (enterprise beans) are business components that run on the server.
-
-Jakarta EE components are written in the Java programming language and are compiled in the same way as any program in the language.
-The differences between Jakarta EE components and "standard" Java classes are that Jakarta EE components are assembled into a Jakarta EE application, they are verified to be well formed and in compliance with the Jakarta EE specification, and they are deployed to production, where they are run and managed by the Jakarta EE server.
-
-=== Jakarta EE Clients
-
-A Jakarta EE client is usually either a web client or an application client.
-
-==== Web Clients
-
-A web client consists of two parts:
-
-* Dynamic web pages containing various types of markup language (HTML, XML, and so on), which are generated by web components running in the web tier
-
-* A web browser, which renders the pages received from the server
-
-A web client is sometimes called a thin client.
-Thin clients usually do not query databases, execute complex business rules, or connect to legacy applications.
-When you use a thin client, such heavyweight operations are off-loaded to enterprise beans executing on the Jakarta EE server, where they can leverage the security, speed, services, and reliability of Jakarta EE server-side technologies.
-
-==== Application Clients
-
-An application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language.
-An application client typically has a graphical user interface (GUI) created from the Swing API or the Abstract Window Toolkit (AWT) API, but a command-line interface is certainly possible.
-
-Application clients directly access enterprise beans running in the business tier.
-However, if application requirements warrant it, an application client can open an HTTP connection to establish communication with a servlet running in the web tier.
-Application clients written in languages other than Java can interact with Jakarta EE servers, enabling the Jakarta EE platform to interoperate with legacy systems, clients, and non-Java languages.
-
-==== Applets
-
-A web page received from the web tier can include an embedded applet.
-Written in the Java programming language, an applet is a small client application that executes in the Java virtual machine installed in the web browser.
-However, client systems will likely need the Java Plug-in and possibly a security policy file for the applet to successfully execute in the web browser.
-
-Web components are the preferred API for creating a web client program because no plug-ins or security policy files are needed on the client systems.
-Also, web components enable cleaner and more modular application design because they provide a way to separate applications programming from web page design.
-Personnel involved in web page design thus do not need to understand Java programming language syntax to do their jobs.
-
-==== The JavaBeans Component Architecture
-
-The server and client tiers might also include components based on the JavaBeans component architecture (JavaBeans components) to manage the data flow between the following:
-
-* An application client or applet and components running on the Jakarta EE server
-
-* Server components and a database
-
-JavaBeans components are not considered Jakarta EE components by the Jakarta EE specification.
-
-JavaBeans components have properties and have `get` and `set` methods for accessing those properties.
-JavaBeans components used in this way are typically simple in design and implementation but should conform to the naming and design conventions outlined in the JavaBeans component architecture.
-
-==== Jakarta EE Server Communications
-
-<<_server_communication>> shows the various elements that can make up the client tier.
-The client communicates with the business tier running on the Jakarta EE server either directly or, as in the case of a client running in a browser, by going through web pages or servlets running in the web tier.
-
-[[_server_communication]]
-.Server Communication
-image::common:jakartaeett_dt_002.svg["Diagram of client-server communication. Application clients access the business tier directly. Browsers, web pages, and applets access the web tier."]
-
-=== Web Components
-
-Jakarta EE web components are either servlets or web pages created using Jakarta Faces technology and/or Jakarta Server Pages technology.
-Servlets are Java programming language classes that dynamically process requests and construct responses.
-Jakarta Server Pages are text-based documents that execute as servlets but allow a more natural approach to creating static content.
-Jakarta Faces technology builds on servlets and Jakarta Server Pages technology and provides a user interface component framework for web applications.
-
-Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the Jakarta EE specification.
-Server-side utility classes can also be bundled with web components and, like HTML pages, are not considered web components.
-
-As shown in <<_web_tier_and_jakarta_ee_applications>>, the web tier, like the client tier, might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.
-
-[[_web_tier_and_jakarta_ee_applications]]
-.Web Tier and Jakarta EE Applications
-image::common:jakartaeett_dt_003.svg["Diagram of client-server communication showing detail of JavaBeans components and web pages in the web tier."]
-
-=== Business Components
-
-Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in either the business tier or the web tier.
-<<_business_and_eis_tiers>> shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage.
-An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.
-
-[[_business_and_eis_tiers]]
-.Business and EIS Tiers
-image::common:jakartaeett_dt_004.svg["Diagram of client-server communication showing detail of entities, session beans, and message-driven beans in the business tier."]
-
-=== Enterprise Information System Tier
-
-The enterprise information system tier handles EIS software and includes enterprise infrastructure systems, such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems.
-For example, Jakarta EE application components might need access to enterprise information systems for database connectivity.
diff --git a/src/main/antora/modules/intro/pages/overview/overview005.adoc b/src/main/antora/modules/intro/pages/overview/overview005.adoc
deleted file mode 100644
index 2e0e77be..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview005.adoc
+++ /dev/null
@@ -1,54 +0,0 @@
-== Jakarta EE Containers
-
-Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details.
-The component-based and platform-independent Jakarta EE architecture makes applications easy to write because business logic is organized into reusable components.
-In addition, the Jakarta EE server provides underlying services in the form of a container for every component type.
-Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand.
-
-=== Container Services
-
-Containers are the interface between a component and the low-level, platform-specific functionality that supports the component.
-Before it can be executed, a web, enterprise bean, or application client component must be assembled into a Jakarta EE module and deployed into its container.
-
-The assembly process involves specifying container settings for each component in the Jakarta EE application and for the Jakarta EE application itself.
-Container settings customize the underlying support provided by the Jakarta EE server, including such services as security, transaction management, Java Naming and Directory Interface (JNDI) API lookups, and remote connectivity.
-Here are some of the highlights.
-
-* The Jakarta EE security model lets you configure a web component or enterprise bean so that system resources are accessed only by authorized users.
-
-* The Jakarta EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit.
-
-* JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access these services.
-
-* The Jakarta EE remote connectivity model manages low-level communications between clients and enterprise beans.
-After an enterprise bean is created, a client invokes methods on it as if it were in the same virtual machine.
-
-Because the Jakarta EE architecture provides configurable services, components within the same application can behave differently based on where they are deployed.
-For example, an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment.
-
-The container also manages nonconfigurable services, such as enterprise bean and servlet lifecycles, database connection resource pooling, data persistence, and access to the Jakarta EE platform APIs (see xref:overview/overview.adoc#_jakarta_ee_apis[Jakarta EE APIs]).
-
-=== Container Types
-
-The deployment process installs Jakarta EE application components in the Jakarta EE containers, as illustrated in <<_jakarta_ee_server_and_containers>>.
-
-[[_jakarta_ee_server_and_containers]]
-.Jakarta EE Server and Containers
-image::common:jakartaeett_dt_005.svg["Diagram of client-server communication showing servlets and web pages in the web tier and enterprise beans in the business tier."]
-
-The server and containers are as follows:
-
-* Jakarta EE server: The runtime portion of a Jakarta EE product.
-A Jakarta EE server provides enterprise and web containers.
-
-* Jakarta Enterprise Bean container: Manages the execution of enterprise beans for Jakarta EE applications.
-Jakarta Enterprise Beans and their container run on the Jakarta EE server.
-
-* Web container: Manages the execution of web pages, servlets, and some enterprise bean components for Jakarta EE applications.
-Web components and their container run on the Jakarta EE server.
-
-* Application client container: Manages the execution of application client components.
-Application clients and their container run on the client.
-
-* Applet container: Manages the execution of applets.
-Consists of a web browser and a Java Plug-in running on the client together.
diff --git a/src/main/antora/modules/intro/pages/overview/overview006.adoc b/src/main/antora/modules/intro/pages/overview/overview006.adoc
deleted file mode 100644
index 8498dfd8..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview006.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-== Web Services Support
-
-Web services are web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients.
-The Jakarta EE platform provides the XML APIs and tools you need to quickly design, develop, test, and deploy web services and clients that fully interoperate with other web services and clients running on Java-based or non-Java-based platforms.
-
-To write web services and clients with the Jakarta EE XML APIs, all you need to do is pass parameter data to the method calls and process the data returned; for document-oriented web services, you send documents containing the service data back and forth.
-No low-level programming is needed because the XML API implementations do the work of translating the application data to and from an XML-based data stream that is sent over the standardized XML-based transport protocols.
-These XML-based standards and protocols are introduced in the following sections.
-
-The translation of data to a standardized XML-based data stream is what makes web services and clients written with the Jakarta EE XML APIs fully interoperable.
-This does not necessarily mean that the data being transported includes XML tags, because the transported data can itself be plain text, XML data, or any kind of binary data, such as audio, video, maps, program files, computer-aided design (CAD) documents, and the like.
-The next section introduces XML and explains how parties doing business can use XML tags and schemas to exchange data in a meaningful way.
-
-=== XML
-
-Extensible Markup Language (XML) is a cross-platform, extensible, text-based standard for representing data.
-Parties that exchange XML data can create their own tags to describe the data, set up schemas to specify which tags can be used in a particular kind of XML document, and use XML style sheets to manage the display and handling of the data.
-
-For example, a web service can use XML and a schema to produce price lists, and companies that receive the price lists and schema can have their own style sheets to handle the data in a way that best suits their needs. Here are examples.
-
-* One company might put XML pricing information through a program to translate the XML into HTML so that it can post the price lists to its intranet.
-
-* A partner company might put the XML pricing information through a tool to create a marketing presentation.
-
-* Another company might read the XML pricing information into an application for processing.
-
-=== SOAP Transport Protocol
-
-Client requests and web service responses are transmitted as Simple Object Access Protocol (SOAP) messages over HTTP to enable a completely interoperable exchange between clients and web services, all running on different platforms and at various locations on the Internet.
-HTTP is a familiar request-and-response standard for sending messages over the Internet, and SOAP is an XML-based protocol that follows the HTTP request-and-response model.
-
-The SOAP portion of a transported message does the following:
-
-* Defines an XML-based envelope to describe what is in the message and explain how to process the message
-
-* Includes XML-based encoding rules to express instances of application-defined data types within the message
-
-* Defines an XML-based convention for representing the request to the remote service and the resulting response
-
-=== WSDL Standard Format
-
-The Web Services Description Language (WSDL) is a standardized XML format for describing network services.
-The description includes the name of the service, the location of the service, and ways to communicate with the service.
-WSDL service descriptions can be published on the Web.
-Eclipse GlassFish Server provides a tool for generating the WSDL specification of a web service that uses remote procedure calls to communicate with clients.
diff --git a/src/main/antora/modules/intro/pages/overview/overview007.adoc b/src/main/antora/modules/intro/pages/overview/overview007.adoc
deleted file mode 100644
index 3ee7e79b..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview007.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-== Jakarta EE Application Assembly and Deployment
-
-A Jakarta EE application is packaged into one or more standard units for deployment to any Jakarta EE platform-compliant system.
-Each unit contains
-
-* A functional component or components, such as an enterprise bean, web page, servlet, or applet
-
-* An optional deployment descriptor that describes its content
-
-Once a Jakarta EE unit has been produced, it is ready to be deployed.
-Deployment typically involves using a platform's deployment tool to specify location-specific information, such as a list of local users who can access it and the name of the local database.
-Once deployed on a local platform, the application is ready to run.
diff --git a/src/main/antora/modules/intro/pages/overview/overview008.adoc b/src/main/antora/modules/intro/pages/overview/overview008.adoc
deleted file mode 100644
index 02272167..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview008.adoc
+++ /dev/null
@@ -1,370 +0,0 @@
-== Jakarta EE APIs
-
-
-<<_jakarta_ee_containers_2>> shows the relationships among the Jakarta EE
-containers.
-
-[[_jakarta_ee_containers_2]]
-.Jakarta EE Containers
-image::common:jakartaeett_dt_006.svg["Diagram of Jakarta EE containers and their relationships"]
-
-<<_jakarta_ee_apis_in_the_web_container>> shows the availability of the Jakarta EE APIs in the web container.
-
-[[_jakarta_ee_apis_in_the_web_container]]
-.Jakarta EE APIs in the Web Container
-image::common:jakartaeett_dt_007.svg["Diagram of Jakarta EE APIs in the web container"]
-
-<<_jakarta_ee_apis_in_the_enterprise_bean_container>> shows the availability of the Jakarta EE APIs in the enterprise bean container.
-
-[[_jakarta_ee_apis_in_the_enterprise_bean_container]]
-.Jakarta EE APIs in the enterprise bean Container
-image::common:jakartaeett_dt_008.svg[ "Diagram of Jakarta EE APIs in the enterprise bean container"]
-
-<<_jakarta_ee_apis_in_the_application_client_container>> shows the availability of the Jakarta EE APIs in the application client container.
-
-[[_jakarta_ee_apis_in_the_application_client_container]]
-.Jakarta EE APIs in the Application Client Container
-image::common:jakartaeett_dt_009.svg["Diagram of Jakarta EE APIs in the application client container"]
-
-The following sections give a brief summary of the technologies required by the Jakarta EE platform and the APIs used in Jakarta EE applications.
-
-=== Jakarta Enterprise Beans Technology
-
-An enterprise bean component, or enterprise bean, is a body of code that has fields and methods to implement modules of business logic.
-You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Jakarta EE server.
-
-Enterprise beans are either session beans or message-driven beans.
-
-* A session bean represents a transient conversation with a client.
-When the client finishes executing, the session bean and its data are gone.
-
-* A message-driven bean combines features of a session bean and a message listener, allowing a business component to receive messages asynchronously.
-Commonly, these are Jakarta Messaging messages.
-
-The Jakarta EE 9 platform requires Jakarta Enterprise Beans 4.0 and Jakarta Interceptors 2.0.
-
-=== Jakarta Servlet Technology
-
-Jakarta Servlet technology lets you define HTTP-specific servlet classes.
-A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers.
-
-In the Jakarta EE 8 platform, new Jakarta Servlet technology features include the following:
-
-* Server Push
-
-* HTTP Trailer
-
-The Jakarta EE 9 platform requires Servlet 5.0.
-
-=== Jakarta Faces Technology
-
-Jakarta Faces technology is a user interface framework for building web applications.
-The main components of Jakarta Faces technology are as follows:
-
-* A GUI component framework.
-
-* A flexible model for rendering components in different kinds of HTML or different markup languages and technologies.
-A `Renderer` object generates the markup to render the component and converts the data stored in a model object to types that can be represented in a view.
-
-* A standard `RenderKit` for generating HTML 4.01 markup.
-
-The following features support the GUI components:
-
-* Input validation
-
-* Event handling
-
-* Data conversion between model objects and components
-
-* Managed model object creation
-
-* Page navigation configuration
-
-* Jakarta Expression Language
-
-All this functionality is available using standard Java APIs and XML-based configuration files.
-
-In the Jakarta EE 8 platform, new features of Jakarta Faces technology include the following:
-
-* Direct support for WebSockets via the new `` tag
-
-* Class-level bean validation via the new `` tag
-
-* A Jakarta Contexts and Dependency Injection compatible `@ManagedProperty` annotation
-
-* Enhanced component search expression framework
-
-The Jakarta EE 9 platform requires Jakarta Faces 3.0 and Jakarta Expression Language 4.0.
-
-=== Jakarta Server Pages Technology
-
-Jakarta Server Pages technology lets you put snippets of servlet code directly into a text-based document.
-A Jakarta Server Pages page is a text-based document that contains two types of text:
-
-* Static data, which can be expressed in any text-based format, such as HTML or XML
-
-* JSP elements, which determine how the page constructs dynamic content
-
-The Jakarta Server Pages technology is derived from and compatible with the JavaServer Pages (JSP) technology.
-
-For information about JSP technology, see _The Java EE 5 Tutorial_ at https://docs.oracle.com/javaee/5/tutorial/doc/[^].
-
-The Jakarta EE 9 platform requires Jakarta Server Pages 3.0 for compatibility with earlier releases but recommends the use of Facelets as the display technology in new applications.
-
-=== Jakarta Standard Tag Library
-
-The Jakarta Standard Tag Library encapsulates core functionality common to many Jakarta Server Pages applications.
-Instead of mixing tags from numerous vendors in your Jakarta Server Pages applications, you use a single, standard set of tags.
-This standardization allows you to deploy your applications on any Jakarta Server Pages container that supports Jakarta Standard Tag Library and makes it more likely that the implementation of the tags is optimized.
-
-Jakarta Standard Tag Library has iterator and conditional tags for handling flow control, tags for manipulating XML documents, internationalization tags, tags for accessing databases using SQL, and tags for commonly used functions.
-
-The Jakarta EE 9 platform requires Jakarta Standard Tag Library 2.0.
-
-=== Jakarta Persistence
-
-Jakarta Persistence is a Java standards–based solution for persistence.
-Persistence uses an object/relational mapping approach to bridge the gap between an object-oriented model and a relational database.
-The Jakarta Persistence can also be used in Java SE applications outside of the Jakarta EE environment.
-Jakarta Persistence consists of the following areas:
-
-* The Jakarta Persistence
-
-* The query language
-
-* Object/relational mapping metadata
-
-The Jakarta EE 9 platform requires Jakarta Persistence 3.0.
-
-=== Jakarta Transactions
-
-Jakarta Transactions provides a standard interface for demarcating transactions.
-The Jakarta EE architecture provides a default auto commit to handle transaction commits and rollbacks.
-An auto commit means that any other applications that are viewing data will see the updated data after each database read or write operation.
-However, if your application performs two separate database access operations that depend on each other, you will want to use the Jakarta Transactions to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.
-
-The Jakarta EE 9 platform requires Jakarta Transactions 2.0.
-
-=== Jakarta RESTful Web Services
-
-Jakarta RESTful Web Services defines APIs for the development of web services built according to the Representational State Transfer (REST) architectural style.
-A Jakarta RESTful application is a web application that consists of classes packaged as a servlet in a WAR file along with required libraries.
-
-In the Jakarta EE 8 platform, new RESTful web services features include the following:
-
-* Reactive Client API +
-When the results of an invocation on a target resource are received, enhancements to the completion stage APIs in Java SE allow the sequence of those results to be specified, prioritized, combined, or concatenated, and how exceptions can be handled.
-
-* Enhancements in support for server-sent events +
-Clients may subscribe to server-issued event notifications using a long-running connection. Support for a new media type, text/event-stream, has been added.
-
-* Support for Jakarta JSON Binding objects, and improved integration with Jakarta Contexts and Dependency Injection, Jakarta Servlet, and Jakarta Bean Validation technologies
-
-The Jakarta EE 9 platform requires Jakarta RESTful Web Services 3.0.
-
-=== Jakarta Managed Beans
-
-Jakarta Managed Beans, lightweight container-managed objects (POJOs) with minimal requirements, support a small set of basic services, such as resource injection, lifecycle callbacks, and interceptors.
-
-The Jakarta Managed Beans specification is part of the Jakarta EE 9 platform specification.
-The Jakarta EE 9 platform requires Jakarta Managed Beans 2.0.
-
-=== Jakarta Contexts and Dependency Injection
-
-Jakarta Contexts and Dependency Injection (CDI) defines a set of contextual services, provided by Jakarta EE containers, that make it easy for developers to use enterprise beans along with Jakarta Faces technology in web applications.
-Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but typesafe way.
-
-In the Jakarta EE 8 platform, new CDI features include the following:
-
-* An API for bootstrapping a CDI container in Java SE 8
-
-* Support for observer ordering, which determines the order in which the observer methods for a particular event are invoked, and support for firing events asynchronously
-
-* Configurators interfaces, which are used for dynamically defining and modifying CDI objects
-
-* Built-in annotation literals, a convenience feature for creating instances of annotations, and more
-
-The Jakarta EE 9 platform requires Jakarta Contexts and Dependency Injection 3.0.
-
-=== Jakarta Dependency Injection
-
-Jakarta Dependency Injection defines a standard set of annotations (and one interface) for use on injectable classes.
-
-In the Jakarta EE platform, CDI provides support for Dependency Injection.
-Specifically, you can use injection points only in a CDI-enabled application.
-
-The Jakarta EE 9 platform requires Jakarta Dependency Injection 2.0.
-
-=== Jakarta Bean Validation
-
-The Jakarta Bean Validation specification defines a metadata model and API for validating data in JavaBeans components.
-Instead of distributing validation of data over several layers, such as the browser and the server side, you can define the validation constraints in one place and share them across the different layers.
-
-In the Jakarta EE 8 platform, new Jakarta Bean Validation features include the following:
-
-* Support for new features in Java SE 8, such as the Date-Time API
-
-* Addition of new built-in Jakarta Bean Validation constraints
-
-The Jakarta EE 9 platform requires Jakarta Bean Validation 3.0.
-
-=== Jakarta Messaging
-
-Jakarta Messaging is a messaging standard that allows Jakarta EE application components to create, send, receive, and read messages.
-It enables distributed communication that is loosely coupled, reliable, and asynchronous.
-
-The Jakarta EE 9 platform requires Jakarta Messaging 3.0.
-
-=== Jakarta Connectors
-
-The Jakarta Connectors is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Jakarta EE product.
-A resource adapter is a software component that allows Jakarta EE application components to access and interact with the underlying resource manager of the EIS.
-Because a resource adapter is specific to its resource manager, a different resource adapter typically exists for each type of database or enterprise information system.
-
-The Jakarta Connectors also provides a performance-oriented, secure, scalable, and message-based transactional integration of Jakarta EE platform-based web services with existing EISs that can be either synchronous or asynchronous.
-Existing applications and EISs integrated through the Jakarta Connectors into the Jakarta EE platform can be exposed as XML-based web services by using Jakarta XML Web Services and Jakarta EE component models.
-Thus Jakarta XML Web Services and the Jakarta Connectors are complementary technologies for enterprise application integration (EAI) and end-to-end business integration.
-
-The Jakarta EE 9 platform requires Jakarta Connectors 2.0.
-
-=== Jakarta Mail
-
-Jakarta EE applications use the Jakarta Mail to send email notifications.
-The Jakarta Mail has two parts:
-
-* An application-level interface used by the application components to send mail
-
-* A service provider interface
-
-The Jakarta EE platform includes the Jakarta Mail with a service provider that allows application components to send Internet mail.
-
-The Jakarta EE 9 platform requires Jakarta Mail 2.0.
-
-=== Jakarta Authorization
-
-The Jakarta Authorization specification defines a contract between a Jakarta EE application server and an authorization policy provider.
-All Jakarta EE containers support this contract.
-
-The Jakarta Authorization specification defines `java.security.Permission` classes that satisfy the Jakarta EE authorization model.
-The specification defines the binding of container-access decisions to operations on instances of these permission classes.
-It defines the semantics of policy providers that use the new permission classes to address the authorization requirements of the Jakarta EE platform, including the definition and use of roles.
-
-The Jakarta EE 9 platform requires Jakarta Authorization 2.0.
-
-=== Jakarta Authentication
-
-The Jakarta Authentication specification defines a service provider interface (SPI) by which authentication providers that implement message authentication mechanisms may be integrated in client or server message-processing containers or runtimes.
-Authentication providers integrated through this interface operate on network messages provided to them by their calling containers.
-The authentication providers transform outgoing messages so that the source of each message can be authenticated by the receiving container, and the recipient of the message can be authenticated by the message sender.
-Authentication providers authenticate each incoming message and return to their calling containers the identity established as a result of the message authentication.
-
-The Jakarta EE 9 platform requires Jakarta Authentication 2.0.
-
-=== Jakarta Security
-
-Jakarta Security specification defines portable, plug-in interfaces for HTTP authentication and identity stores, and an injectable `SecurityContext` interface that provides an API for programmatic security.
-
-Implementations of the `HttpAuthenticationMechanism` interface can be used to authenticate callers of web applications.
-An application can supply its own `HttpAuthenticationMechanism`, or use one of the default implementations provided by the container.
-
-Implementations of the `IdentityStore` interface can be used to validate user credentials and retrieve group information.
-An application can provide its own `IdentityStore`, or use the built in LDAP or Database store.
-
-The `HttpAuthenticationMechanism` and `IdentityStore` APIs provide an advantage over container-provided implementations in that they allow an application to control the authentication process, and the identity stores used for authentication, in a standard, portable way.
-
-The `SecurityContext` API is intended for use by application code to query and interact with the current security context.
-The specification also provides for default group-to-role mapping, and defines a principal type called `CallerPrincipal` that can represent the identity of an application caller.
-
-The Jakarta EE 9 platform requires Jakarta Security 2.0.
-
-=== Jakarta WebSocket
-
-WebSocket is an application protocol that provides full-duplex communications between two peers over TCP.
-Jakarta WebSocket enables Jakarta EE applications to create endpoints using annotations that specify the configuration parameters of the endpoint and designate its lifecycle callback methods.
-
-The Jakarta EE 9 platform requires Jakarta WebSocket 2.0.
-
-=== Jakarta JSON Processing
-
-JavaScript Object Notation (JSON) is a text-based data exchange format derived from JavaScript that is used in web services and other connected applications.
-Jakarta JSON Processing enables Jakarta EE applications to parse, transform, and query JSON data using the object model or the streaming model.
-
-In the Jakarta EE 8 platform, new features of Jakarta JSON Processing include support for the following:
-
-* JSON Pointer +
-Defines a string syntax for referencing a specific value within a JSON document. JSON Pointer includes APIs for extracting values from a target document and transforming them to create a new JSON document.
-
-* JSON Patch +
-Defines a format for expressing a sequence of operations to be applied to a JSON document.
-
-* JSON Merge Patch +
-Defines a format and processing rules for applying operations to a JSON document that are based upon specific content of the target document.
-
-* The addition of editing and transformation functions to basic JSON document processing.
-
-* Helper classes and methods, called JSON Collectors, which leverage features of the Stream API that was introduced in Java SE 8.
-
-The Jakarta EE 9 platform requires Jakarta JSON Processing 2.0.
-
-=== Jakarta JSON Binding
-
-Jakarta JSON Binding provides a binding layer for converting Java objects to and from JSON messages.
-Jakarta JSON Binding also supports the ability to customize the default mapping process used in this binding layer through the use of Java annotations for a given field, JavaBean property, type or package, or by providing an implementation of a property naming strategy.
-
-The Jakarta EE 9 platform requires Jakarta JSON Binding 2.0.
-
-=== Jakarta Concurrency
-
-Jakarta Concurrency is a standard API for providing asynchronous capabilities to Jakarta EE application components through the following types of objects: managed executor service, managed scheduled executor service, managed thread factory, and context service.
-
-The Jakarta EE 9 platform requires Jakarta Concurrency 2.0.
-
-=== Jakarta Batch
-
-Batch jobs are tasks that can be executed without user interaction.
-The Batch Applications for the Java Platform specification is a batch framework that provides support for creating and running batch jobs in Java applications.
-The batch framework consists of a batch runtime, a job specification language based on XML, a Java API to interact with the batch runtime, and a Java API to implement batch artifacts.
-
-The Jakarta EE 9 platform requires Jakarta Batch 2.0.
-
-=== Jakarta Activation
-
-The Jakarta Activation is used by the Jakarta Mail.
-Jakarta Activation provides standard services to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and create the appropriate JavaBeans component to perform those operations.
-
-The Jakarta EE 9 platform requires Jakarta Activation 2.0.
-
-=== Jakarta XML Binding
-
-The Jakarta XML Binding provides a convenient way to bind an XML schema to a representation in Java language programs.
-XML Binding can be used independently or in combination with Jakarta XML Web Services, in which case it provides a standard data binding for web service messages.
-All Jakarta EE application client containers, web containers, and Jakarta Enterprise Beans containers support the XML Binding API.
-
-The Jakarta EE 9 platform requires Jakarta XML Binding 3.0.
-
-=== Jakarta XML Web Services
-
-The Jakarta XML Web Services specification provides support for web services that use the Jakarta XML Binding API for binding XML data to Java objects.
-The Jakarta XML Web Services specification defines client APIs for accessing web services as well as techniques for implementing web service endpoints.
-The Enterprise Web Services specification describes the deployment of Jakarta XML Web Services based services and clients.
-The Jakarta Enterprise Beans and Jakarta Servlet specifications also describe aspects of such deployment.
-Jakarta XML Web Services based applications can be deployed using any of these deployment models.
-
-The Jakarta XML Web Services specification describes the support for message handlers that can process message requests and responses.
-In general, these message handlers execute in the same container and with the same privileges and execution context as the Jakarta XML Web Services client or endpoint component with which they are associated.
-These message handlers have access to the same JNDI namespace as their associated component.
-Custom serializers and deserializers, if supported, are treated in the same way as message handlers.
-
-The Jakarta EE 9 platform requires Jakarta XML Web Services 3.0.
-
-=== Jakarta SOAP with Attachments
-
-The Jakarta SOAP with Attachments is a low-level API on which Jakarta XML Web Services depends.
-Jakarta SOAP with Attachments enables the production and consumption of messages that conform to the SOAP 1.1 and 1.2 specifications and the Jakarta SOAP with Attachments note.
-Most developers do not use the Jakarta SOAP with Attachments, instead using the higher-level Jakarta XML Web Services API.
-
-=== Jakarta Annotations
-
-Annotations enable a declarative style of programming in the Java platform.
-
-The Jakarta EE 9 platform requires Jakarta Annotations 2.0.
diff --git a/src/main/antora/modules/intro/pages/overview/overview009.adoc b/src/main/antora/modules/intro/pages/overview/overview009.adoc
deleted file mode 100644
index 157942c0..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview009.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-== Jakarta EE 9 APIs in the Java Platform, Standard Edition 8
-
-Several APIs that are required by the Jakarta EE 9 platform are included in the Java Platform, Standard Edition 8 (Java SE 8) and are thus available to Jakarta EE applications.
-
-=== Java Database Connectivity API
-
-The Java Database Connectivity (JDBC) API lets you invoke SQL commands from Java programming language methods.
-You use the JDBC API in an enterprise bean when you have a session bean access the database.
-You can also use the JDBC API from a servlet or a JSP page to access the database directly without going through an enterprise bean.
-
-The JDBC API has two parts:
-
-* An application-level interface used by the application components to access a database
-
-* A service provider interface to attach a JDBC driver to the Jakarta EE platform
-
-The Jakarta EE 9 platform requires JDBC 4.1.
-
-=== Java Naming and Directory Interface API
-
-The Java Naming and Directory Interface (JNDI) API provides naming and directory functionality, enabling applications to access multiple naming and directory services, such as LDAP, DNS, and NIS.
-The JNDI API provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes.
-Using JNDI, a Jakarta EE application can store and retrieve any type of named Java object, allowing Jakarta EE applications to coexist with many legacy applications and systems.
-
-Jakarta EE naming services provide application clients, enterprise beans, and web components with access to a JNDI naming environment.
-A naming environment allows a component to be customized without the need to access or change the component's source code.
-A container implements the component's environment and provides it to the component as a JNDI naming context.
-
-The naming environment provides four logical namespaces: `java:comp`, `java:module`, `java:app`, and `java:global` for objects available to components, modules, or applications or shared by all deployed applications.
-A Jakarta EE component can access named system-provided and user-defined objects. The names of some system-provided objects, such as a default JDBC `DataSource` object, a default Messaging connection factory, and a Transactions `UserTransaction` object, are stored in the `java:comp` namespace.
-The Jakarta EE platform allows a component to name user-defined objects, such as enterprise beans, environment entries, JDBC `DataSource` objects, and messaging destinations.
-
-A Jakarta EE component can also locate its environment naming context by using JNDI interfaces.
-A component can create a `javax.naming.InitialContext` object and look up the environment naming context in `InitialContext` under the name `java:comp/env`.
-A component's naming environment is stored directly in the environment naming context or in any of its direct or indirect subcontexts.
-
-=== Java API for XML Processing
-
-The Java API for XML Processing (JAXP), part of the Java SE platform, supports the processing of XML documents using Document Object Model (DOM), Simple API for XML (SAX), and Extensible Stylesheet Language Transformations (XSLT).
-JAXP enables applications to parse and transform XML documents independently of a particular XML-processing implementation.
-
-JAXP also provides namespace support, which lets you work with schemas that might otherwise have naming conflicts.
-Designed to be flexible, JAXP lets you use any XML-compliant parser or XSL processor from within your application and supports the Worldwide Web Consortium (W3C) schema.
-You can find information on the W3C schema at https://www.w3.org/XML/Schema[^].
-
-=== Java Authentication and Authorization Service
-
-The Java Authentication and Authorization Service (JAAS) provides a way for a Jakarta EE application to authenticate and authorize a specific user or group of users to run it.
-
-JAAS is a Java programming language version of the standard Pluggable Authentication Module (PAM) framework, which extends the Java platform security architecture to support user-based authorization.
diff --git a/src/main/antora/modules/intro/pages/overview/overview010.adoc b/src/main/antora/modules/intro/pages/overview/overview010.adoc
deleted file mode 100644
index 1d99df96..00000000
--- a/src/main/antora/modules/intro/pages/overview/overview010.adoc
+++ /dev/null
@@ -1,41 +0,0 @@
-== Eclipse GlassFish Server Tools
-
-Eclipse GlassFish Server is a compliant implementation of the Jakarta EE platform.
-In addition to supporting all the APIs described in the previous sections, Eclipse GlassFish Server includes a number of Jakarta EE tools that are not part of the Jakarta EE platform but are provided as a convenience to the developer.
-
-This section briefly summarizes the tools that make up Eclipse GlassFish Server.
-Instructions for starting and stopping Eclipse GlassFish Server, starting the Administration Console, and starting and stopping Apache Derby are in xref:usingexamples/usingexamples.adoc#_using_the_tutorial_examples[Using the Tutorial Examples].
-
-Eclipse GlassFish Server contains the tools listed in <<_glassfish_server_tools>>.
-Basic usage information for many of the tools appears throughout the tutorial.
-For detailed information, see the online help in the GUI tools.
-
-[[_glassfish_server_tools]]
-.Eclipse GlassFish Server Tools
-[width="85%" cols="20%,65%"]
-|===
-|Tool |Description
-
-|Administration Console |A web-based GUI Eclipse GlassFish Server administration utility.
-Used to stop Eclipse GlassFish Server and to manage users, resources, and applications.
-
-|`asadmin` |A command-line Eclipse GlassFish Server administration utility.
-Used to start and stop Eclipse GlassFish Server and to manage users, resources, and applications.
-
-|`appclient` |A command-line tool that launches the application client container and invokes the client application packaged in the application client JAR file.
-
-|`capture-schema` |A command-line tool to extract schema information from a database, producing a schema file that Eclipse GlassFish Server can use for container-managed persistence.
-
-|`package-appclient` |A command-line tool to package the application client container libraries and JAR files.
-
-|Apache Derby |A copy of Apache Derby database.
-
-|`xjc` |A command-line tool to transform, or bind, a source XML schema to a set of JAXB content classes in the Java programming language.
-
-|`schemagen` |A command-line tool to create a schema file for each namespace referenced in your Java classes.
-
-|`wsimport` |A command-line tool to generate Jakarta XML Web Services portable artifacts for a given WSDL file.
-After generation, these artifacts can be packaged in a WAR file with the WSDL and schema documents, along with the endpoint implementation, and then deployed.
-
-|`wsgen` |A command-line tool to read a web service endpoint class and generate all the required Jakarta XML Web Services portable artifacts for web service deployment and invocation.
-|===
diff --git a/src/main/antora/modules/security/images/authentication-mvc.drawio b/src/main/antora/modules/security/images/authentication-mvc.drawio
new file mode 100644
index 00000000..1bc76a31
--- /dev/null
+++ b/src/main/antora/modules/security/images/authentication-mvc.drawio
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/main/antora/modules/security/images/authentication-mvc.svg b/src/main/antora/modules/security/images/authentication-mvc.svg
new file mode 100644
index 00000000..74a2a3ab
--- /dev/null
+++ b/src/main/antora/modules/security/images/authentication-mvc.svg
@@ -0,0 +1,4 @@
+
+
+
+
Authentication Mechanism (Controller)
Authentication Mecha...
Login Form/Dialog (View)
Login Form/Dialog...
Identity Store (Model)
Identity Store...
HTTP Cookies Headers URLs
HTTP...
Credentials Caller name Groups
Credentials...Text is not SVG - cannot display
\ No newline at end of file
diff --git a/src/main/antora/modules/security/images/authentication-mvc.vsdx b/src/main/antora/modules/security/images/authentication-mvc.vsdx
new file mode 100644
index 00000000..c84406c7
Binary files /dev/null and b/src/main/antora/modules/security/images/authentication-mvc.vsdx differ
diff --git a/src/main/antora/modules/security/pages/security.adoc b/src/main/antora/modules/security/pages/security.adoc
index a35bf0ca..76e365e4 100644
--- a/src/main/antora/modules/security/pages/security.adoc
+++ b/src/main/antora/modules/security/pages/security.adoc
@@ -32,7 +32,7 @@ Some examples of identity stores are services that contact SQL or NoSQL database
[[_mechanism_store_in_mvc]]
.Mechanism Store in MVC
-image::common:authentication_mvc.svg["Diagram illustrating the role of the authentication mechanism and identity store in an MVC like structure"]
+image::authentication-mvc.svg["Diagram illustrating the role of the authentication mechanism and identity store in an MVC like structure"]
The third one is used for the authorization process:
@@ -65,7 +65,7 @@ The https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0.html[
A Servlet authentication mechanism, however, will not necessarily consult a Jakarta Security identity store. This is server dependent. The identity store that is called is server dependent as well. Calling this server-dependent identity store is possible from Jakarta Security, but as an advanced feature.
-Likewise, programmatic role checks can be done from various APIs, including Jakarta Security, Jakarta REST, and Jakarta Servlet. These all return the same outcome, independent of whether authentication took place with a Jakarta Security Authentication Mechanism or a Servlet Authentication Mechanism. Within a Jakarta EE environment the usage of Jakarta Security for this is encouraged, and the usage of those other APIs is discouraged.
+Likewise, programmatic role checks can be done from various APIs, including Jakarta Security, Jakarta REST, and Jakarta Servlet. These all return the same outcome, independent of whether authentication took place with a Jakarta Security Authentication Mechanism or a Servlet Authentication Mechanism. Within a Jakarta EE environment the usage of Jakarta Security for this is encouraged, and the usage of those other APIs is discouraged.
NOTE: Programmatic role checks in Jakarta REST, Jakarta Servlet and various other APIs are not being deprecated for the time being, as those APIs are also used stand-alone (outside Jakarta EE). Future versions of those APIs may contain warnings about their usage within Jakarta EE.
@@ -758,31 +758,31 @@ We'll now write the identity store handler:
@Priority(APPLICATION) <2>
@ApplicationScoped
public class CustomIdentityStoreHandler implements IdentityStoreHandler {
-
+
@Inject
Instance identityStores; <3>
-
+
@Override
public CredentialValidationResult validate(Credential credential) {
CredentialValidationResult result = null;
Set groups = new HashSet<>();
-
+
for (IdentityStore identityStore : identityStores) {
result = identityStore.validate(credential);
if (result.getStatus() == NOT_VALIDATED) {
// Identity store probably doesn't handle our credential type
continue;
}
-
+
if (result.getStatus() == INVALID) {
// Identity store handled our credential type and determined its
// invalid. End the loop.
return INVALID_RESULT;
}
-
+
groups.addAll(result.getCallerGroups());
}
-
+
return new CredentialValidationResult(
result.getCallerPrincipal(), groups);
}
@@ -792,7 +792,7 @@ public class CustomIdentityStoreHandler implements IdentityStoreHandler {
<2> To make `@Alternative` actually work, we additionally have to annotate with `@Priority(APPLICATION)`
<3> With `@Inject` `Instance identityStores` CDI will give us a collection of all identity stores in the application. In the case of this example that will be the store behind `@DatabaseIdentityStoreDefinition` and our `CustomIdentityStore`. We can the iterate over those stores in our code, and offer the credentials (the username and password in this example) to each of them.
-There are various result outcomes possible.
+There are various result outcomes possible.
`NOT_VALIDATED` means the store did not try to validate the credentials at all. In most situations that status is set when the store in question doesnt't handle a given credential. I.e. it only handles say `JWTCredentials` and not `UsernamePasswordCredential`.
@@ -846,35 +846,35 @@ Let's now define a simple authentication mechanism that the security system can
----
@ApplicationScoped
public class CustomAuthenticationMechanism implements HttpAuthenticationMechanism {
-
+
@Inject
private IdentityStoreHandler identityStoreHandler;
@Override
public AuthenticationStatus validateRequest(
- HttpServletRequest request,
- HttpServletResponse response,
+ HttpServletRequest request,
+ HttpServletResponse response,
HttpMessageContext httpMessageContext) throws AuthenticationException {
-
+
var callerName = request.getHeader("callername"); <1>
var password = request.getHeader("callerpassword");
-
+
if (callerName == null || password == null) { <2>
return httpMessageContext.doNothing();
}
var result = identityStoreHandler.validate( <4>
new UsernamePasswordCredential(callerName, password)); <3>
-
+
if (result.getStatus() != VALID) {
return httpMessageContext.responseUnauthorized();
}
return httpMessageContext.notifyContainerAboutLogin( <5>
- result.getCallerPrincipal(),
+ result.getCallerPrincipal(),
result.getCallerGroups());
}
-
+
}
----
@@ -926,7 +926,7 @@ public class RestCustomAuthCustomStoreIT extends ITBase {
public void testRestCall() throws Exception {
webClient.addRequestHeader("callername", "john");
webClient.addRequestHeader("callerpassword", "secret1");
-
+
TextPage page = webClient.getPage(baseUrl + "rest/resource");
String content = page.getContent();
@@ -987,11 +987,11 @@ For this example, we'll add the CDI extension interface (1) to our application c
)
)
@ApplicationPath("/rest")
-public class ApplicationConfig extends Application
+public class ApplicationConfig extends Application
implements BuildCompatibleExtension { <1>
-
+
@Enhancement(
- types = HttpAuthenticationMechanism.class,
+ types = HttpAuthenticationMechanism.class,
withSubtypes = true) <2>
public void addRememberMe(ClassConfig httpAuthenticationMechanism) {
httpAuthenticationMechanism.addAnnotation(
@@ -1017,16 +1017,16 @@ The following shows an example:
@ApplicationScoped
public class CustomRememberMeIdentityStore implements RememberMeIdentityStore {
- private final Map tokenToIdentityMap =
+ private final Map tokenToIdentityMap =
new ConcurrentHashMap<>();
-
+
@Override
public String generateLoginToken(
CallerPrincipal callerPrincipal, Set groups) { <1>
var token = UUID.randomUUID().toString();
tokenToIdentityMap.put(
- token,
+ token,
new CredentialValidationResult(callerPrincipal, groups));
return token;
@@ -1050,19 +1050,19 @@ public class CustomRememberMeIdentityStore implements RememberMeIdentityStore {
}
-----
-The `RememberMeIdentityStore` needs to perform 3 tasks.
+The `RememberMeIdentityStore` needs to perform 3 tasks.
It first needs to generate a token representing a caller principal and a set of groups. The caller principal and the set of groups are the ones set by the authentication mechanism right after the caller successfully authenticated. In our example (1) here we're generating a random UUID that's used as a key in an application scoped map.
NOTE: Storing the authenticated identity (principal and groups) in an application scoped map is just an example. Other options could be storing it in a database or key-value store, encrypting the principal and groups, or generating some kind of JSON Web Token (JWT).
-NOTE: When storing the Principal, care must be taken that the Principal could be an elaborate custom Principal containing many more fields than just `name`.
+NOTE: When storing the Principal, care must be taken that the Principal could be an elaborate custom Principal containing many more fields than just `name`.
The next thing that must be done is essentially similar to what a normal identity store does: validating a `Credential`. For a `RememberMeIdentityStore` this will always be of type `RememberMeCredential` with `getToken()` returning a token of the kind that was generated in `generateLoginToken()`. In our example (2) we're just using the token as key in our map.
-Finally we can provide behaviour to remove the login token (and essentially invalidate it) via the `removeLoginToken` method. This method is called when a caller explicitly logs out. In our example (3) we just remove the token from our map.
+Finally we can provide behaviour to remove the login token (and essentially invalidate it) via the `removeLoginToken` method. This method is called when a caller explicitly logs out. In our example (3) we just remove the token from our map.
-NOTE: When storing the principal and groups in a token that we send to the client we can't always easily invalidate it when the caller logs out; the caller can always keep the token and send it again.
+NOTE: When storing the principal and groups in a token that we send to the client we can't always easily invalidate it when the caller logs out; the caller can always keep the token and send it again.
==== Define the identity store
@@ -1119,7 +1119,7 @@ public class RestFormAuthCustomStoreRememberMeIT extends ITBase {
.click();
System.out.println(page.getContent());
-
+
// Remove all cookies (specially the JSESSONID), except for the
// JREMEMBERMEID cookie which carries the token to login again
for (Cookie cookie : webClient.getCookieManager().getCookies()) {
@@ -1127,10 +1127,10 @@ public class RestFormAuthCustomStoreRememberMeIT extends ITBase {
webClient.getCookieManager().removeCookie(cookie);
}
}
-
+
// Should get the resource response, and not the login form
TextPage pageAgain = webClient.getPage(baseUrl + "/rest/resource");
-
+
System.out.println(pageAgain.getContent());
}
}
@@ -1173,35 +1173,35 @@ Let's now define a simple authentication mechanism that the security system can
@RememberMe <6>
@ApplicationScoped
public class CustomAuthenticationMechanism implements HttpAuthenticationMechanism {
-
+
@Inject
private IdentityStoreHandler identityStoreHandler;
@Override
public AuthenticationStatus validateRequest(
- HttpServletRequest request,
- HttpServletResponse response,
+ HttpServletRequest request,
+ HttpServletResponse response,
HttpMessageContext httpMessageContext) throws AuthenticationException {
-
+
var callerName = request.getHeader("callername"); <1>
var password = request.getHeader("callerpassword");
-
+
if (callerName == null || password == null) { <2>
return httpMessageContext.doNothing();
}
var result = identityStoreHandler.validate( <4>
new UsernamePasswordCredential(callerName, password)); <3>
-
+
if (result.getStatus() != VALID) {
return httpMessageContext.responseUnauthorized();
}
return httpMessageContext.notifyContainerAboutLogin( <5>
- result.getCallerPrincipal(),
+ result.getCallerPrincipal(),
result.getCallerGroups());
}
-
+
}
----
@@ -1281,7 +1281,7 @@ public class RestFormAuthCustomStoreRememberMeIT extends ITBase {
.click();
System.out.println(page.getContent());
-
+
// Remove all cookies (specially the JSESSONID), except for the
// JREMEMBERMEID cookie which carries the token to login again
for (Cookie cookie : webClient.getCookieManager().getCookies()) {
@@ -1289,10 +1289,10 @@ public class RestFormAuthCustomStoreRememberMeIT extends ITBase {
webClient.getCookieManager().removeCookie(cookie);
}
}
-
+
// Should get the resource response, and not the login form
TextPage pageAgain = webClient.getPage(baseUrl + "/rest/resource");
-
+
System.out.println(pageAgain.getContent());
}
}
@@ -1302,7 +1302,7 @@ include::partial$inspect-app.adoc[]
The `webClient.addRequestHeader()` calls used here make sure that the headers for our custom authentication mechanism are added to the request. The authentication mechanism that we defined for our applications reads those headers, extracts the username and password from them, and consults our identity store with them.
-The test sends a request here to the protected resource along with the headers we mentioned above, and the server responds with the right content.
+The test sends a request here to the protected resource along with the headers we mentioned above, and the server responds with the right content.
Then we delete all cookies, except for the `JREMEMBERMEID` cookie, and we unset all headers that we used before. The test then does another request, and this time the value from the `JREMEMBERMEID` cookie is used to login.
@@ -1351,7 +1351,7 @@ include::partial$declare-authentication-mechanism.adoc[]
Contrary to the Basic HTTP authentication mechanism and the Form authentication mechanism, the OpenID Connect authentication mechanism requires a third party server that performs the actual authentication. Such third party server is called the OpenID Connect Provider (OIDC provider or OpenID Provider are also used). After authentication this provider handles user consent and and issues a token. The client requesting a user's authentication is called a Relying Party. In the case of Jakarta EE and Jakarta Security, the Jakarta EE server running the OpenID Connect authentication mechanism is a Relying Party.
-To use this authentication mechanism, Jakarta Security provides the `@OpenIdAuthenticationMechanismDefinition` annotation, for which we typically need 3 mandatory configuration items as shown in the example code above.
+To use this authentication mechanism, Jakarta Security provides the `@OpenIdAuthenticationMechanismDefinition` annotation, for which we typically need 3 mandatory configuration items as shown in the example code above.
The first is the `providerURI` (1), which points to the third party OpenID Connect Provider. In this example we use `https://localhost:8443/openid-connect-server-webapp`, which is the URL on which the example code has installed and started a local OpenID Connect provider called "Mitre". Whenever a caller accesses a protected resource, that caller is redirected to that OpenID Connect Provider.
@@ -1374,7 +1374,7 @@ NOTE: Despite not being typical, Jakarta Security supports getting the groups vi
@ApplicationScoped
public class AuthorizationIdentityStore implements IdentityStore {
- private Map> groupsPerCaller =
+ private Map> groupsPerCaller =
Map.of("user", Set.of("user")); <2>
@Override
@@ -1385,7 +1385,7 @@ public class AuthorizationIdentityStore implements IdentityStore {
@Override
public Set getCallerGroups(
CredentialValidationResult validationResult) { <3>
- return groupsPerCaller.get(validationResult.getCallerPrincipal().getName());
+ return groupsPerCaller.get(validationResult.getCallerPrincipal().getName());
}
}
@@ -1404,10 +1404,10 @@ Installing and configuring the OpenID Connect provider Mitre is outside the scop
[source,xml]
----
-
-
maven-dependency-plugin
@@ -1442,12 +1442,12 @@ Mitre is a Spring application that uses the `javax.*` namespace. We therefore ne
[source,xml]
----
-
@@ -1460,17 +1460,17 @@ Mitre is a Spring application that uses the `javax.*` namespace. We therefore ne
Replacing in ${tomcat.dir}
-
+
-
+
-
+
@@ -1525,7 +1525,7 @@ public class RestOpenIdConnectAuthIT extends ITBase {
public void testRestCall() throws Exception {
HtmlPage page = webClient.getPage(baseUrl + "/rest/resource"); <1>
- // Authenticate with the OpenId Provider using the
+ // Authenticate with the OpenId Provider using the
// username and password for a default user
page.getElementById("j_username")
.setAttribute("value", "user");
@@ -1534,12 +1534,12 @@ public class RestOpenIdConnectAuthIT extends ITBase {
.setAttribute("value", "password"); <2>
// Submit
- HtmlPage confirmationPage =
+ HtmlPage confirmationPage =
page.getElementByName("submit")
.click(); <3>
-
+
// Confirm
- TextPage originalResource =
+ TextPage originalResource =
confirmationPage.getElementByName("authorize")
.click(); <4>
@@ -1770,14 +1770,14 @@ For this example we'll use a Faces view with a backing bean:
-
+