Skip to content

Latest commit

 

History

History
2004 lines (1630 loc) · 72.4 KB

ApplicationProgrammingInterface.adoc

File metadata and controls

2004 lines (1630 loc) · 72.4 KB
Raw

Application Programming Interface

This chapter describes API requirements for the Jakarta™ Platform, Enterprise Edition (Jakarta EE). Jakarta EE requires the provision of a number of APIs for use by Jakarta EE applications, starting with the core Java APIs and including many additional Java technologies.

Required APIs

Jakarta EE application components execute in runtime environments provided by the containers that are a part of the Jakarta EE platform. The full Jakarta EE platform supports four types of containers corresponding to Jakarta EE application component types: application client containers; applet containers; web containers for servlets, Jakarta Server Pages, Jakarta Server Faces applications, Jakarta RESTful Web Services applications; and enterprise bean containers. A Jakarta EE profile may support only a subset of these component types, as defined by the individual Jakarta EE profile specification.

The per-technology requirements in this chapter apply to any Jakarta EE product that includes the technology. Note that even though a Jakarta EE profile might not require support for a particular technology, a Jakarta EE product based on that Jakarta EE profile might nonetheless include support for the technology. In such a case, the requirements for that technology described in this chapter would apply.

Java Compatible APIs

The containers provide all application components with at least the Java Platform, Standard Edition, v8 (Java SE) APIs. Containers may provide newer versions of the Java SE platform, provided they meet all the Jakarta EE platform requirements. The Java SE platform includes the following enterprise technologies:

  • Java IDL

  • JDBC

  • RMI-IIOP

  • JNDI

  • JAXP

  • StAX

  • JAAS

  • JMX

  • JAX-WS

  • JAXB

  • JAF

  • SAAJ

  • Common Annotations

In particular, the applet execution environment must be Java SE 8 compatible. Since typical browsers don’t yet provide such support, Jakarta EE products may make use of the Java Plugin to provide the required applet execution environment. Use of the Java Plugin is not required, but is one method of meeting the requirement to provide a Java SE 8 compatible applet execution environment. This specification adds no requirements to the applet container beyond those specified by Java SE.

Some of the enterprise technologies that are included in Java SE 8 are also available independently of the Java SE platform, and this specification requires newer versions of some of these technologies, as described in the following section.

The specifications for the Java SE APIs are available at http://docs.oracle.com/javase/8/docs/ .

Required Java Technologies

The full Jakarta EE platform also provides a number of Java technologies in each of the containers defined by this specification. Jakarta EE Technologies indicates the technologies with their required versions, which containers include the technologies, and whether the technology is required (REQ), proposed optional (POPT), or optional (OPT). Each Jakarta EE profile specification will include a similar table describing which technologies are required for the profile. Note that some technologies are marked Optional, as described in the next section.

Table 1. Jakarta EE Technologies
Java Technology App Client Web Enterprise Beans Status

Enterprise Beans 3.2

Y [1]

Y

Y

REQ, OPT [2], POPT [3]

Servlet 4.0

N

Y

N

REQ

Server Pages 2.3

N

Y

N

REQ

Expression Language 3.0

N

Y

N

REQ

Messaging 2.0

Y

Y

Y

REQ

Transactions 1.3

N

Y

Y

REQ

Mail 1.6

Y

Y

Y

REQ

Connector 1.7

N

Y

Y

REQ

Enterprise Web Services 1.4

Y

Y

Y

REQ

XML RPC 1.1

Y

Y

Y

OPT

RESTful Web Services 2.1

N

Y

N

REQ

WebSocket 1.1

N

Y

N

REQ

JSON Processing 1.1

Y

Y

Y

REQ

JSON Binding 1.0

Y

Y

Y

REQ

Concurrency 1.1

N

Y

Y

REQ

Batch 1.0

N

Y

Y

REQ

XML Registries 1.0

Y

Y

Y

OPT

Management 1.1

Y

Y

Y

REQ

Deployment 1.7 [4]

N

N

N

OPT

Authorization 1.5

N

Y

Y

REQ

Authentication 1.1

N

Y

Y

REQ

Security API 1.0

N

Y

Y

REQ

Server Pages Debugging 1.0

N

Y

N

REQ

Standard Tag Library 1.2

N

Y

N

REQ

Server Faces 2.3

N

Y

N

REQ

Common Annotations 1.3

Y

Y

Y

REQ

Persistence 2.2

Y

Y

Y

REQ

Bean Validation 2.0

Y

Y

Y

REQ

Managed Beans 1.0

Y

Y

Y

REQ

Interceptors 1.2

Y

Y

Y

REQ

Contexts and Dependency Injection 2.0

Y

Y

Y

REQ

Dependency Injection 1.0

Y

Y

Y

REQ

All classes and interfaces required by the specifications for the APIs must be provided by the Jakarta EE containers indicated above. In some cases, a Jakarta EE product is not required to provide objects that implement interfaces intended to be implemented by an application server, nevertheless, the definitions of such interfaces must be included in the Jakarta EE platform. If an implementation includes support for a technology marked as Optional, that technology must be supported in the containers specified above. If a product implementation does not support a technology marked as Optional, it must not include the APIs for that technology.[5]

Pruned Java Technologies

As the Jakarta EE specification has evolved, some of the technologies originally included in Jakarta EE are no longer as relevant as they were when they were introduced to the platform. The Jakarta EE expert group follows a process first defined by the Java SE expert group ( http://mreinhold.org/blog/removing-features ) to prune technologies from the platform in a careful and orderly way that minimizes the impact to developers using these technologies, while allowing the platform to grow even stronger. In short, the process defines two steps:

  1. The Umbrella Expert Group (UEG) for release N of the platform decides to propose that a particular feature be removed. The specification for that release documents the proposal.

  2. The UEG for release N+1 decides whether to remove the feature from that release, retain it as a required component, or leave it in the "proposed removal" state for the next UEG to decide.

The result of successfully applying this policy to a feature is not the actual deletion of the feature but rather the conversion of the feature from a required component of the platform into an optional component. No actual removal from the specification occurs, although the feature may be removed from products at the choice of the product vendor.

Technologies that have been pruned as of Jakarta EE 8 are marked Optional in Jakarta EE Technologies. Technologies that may be pruned in a future release are marked Proposed Optional in Jakarta EE Technologies.

Java Platform, Standard Edition (Java SE) Requirements

Programming Restrictions

The Jakarta EE programming model divides responsibilities between Application Component Providers and Jakarta EE Product Providers: Application Component Providers focus on writing business logic and the Jakarta EE Product Providers focus on providing a managed system infrastructure in which the application components can be deployed.

This division leads to a restriction on the functionality that application components can contain. If application components contain the same functionality provided by Jakarta EE system infrastructure, there are clashes and mis-management of the functionality.

For example, if enterprise beans were allowed to manage threads, the Jakarta EE platform could not manage the life cycle of the enterprise beans, and it could not properly manage transactions.

Since we do not want to subset the Java SE platform, and we want Jakarta EE Product Providers to be able to use Java SE products without modification in the Jakarta EE platform, we use the Java SE security permissions mechanism to express the programming restrictions imposed on Application Component Providers.

In this section, we specify the Java SE security permissions that the Jakarta EE Product Provider must provide for each application component type. We call these permissions the Jakarta EE security permissions set. The Jakarta EE security permissions set is a required part of the Jakarta EE API contract. We also specify the set of permissions that the Jakarta EE Product Provider must be able to restrict from being provided to application components. In addition, we specify the means by which application component providers may declare the need for specific permissions and how these declarations must be processed by Jakarta EE products.

The Java SE security permissions are fully described in http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html .

Jakarta EE Security Manager Related Requirements

Every Jakarta EE product must be capable of running with a Java security manager that enforces Java security permissions and that prevents application components from performing operations for which they have not been provided the required permissions.

Jakarta EE Product Provider’s Responsibilities

A Jakarta EE product may allow application components to run without a security manager, but every Jakarta EE product must be capable of running application components with a security manager that enforces security permissions, as described below.

The set of security permissions provided to application components by a particular installation is a matter of policy outside the scope of this specification, however, every Jakarta EE product must be capable of running with a configuration that provides application classes and packaged libraries the permissions defined in Jakarta EE Security Permissions Set.

All Jakarta EE products must allow the set of permissions available to application classes in a module to be configurable, providing application components in some modules with different permissions than those described in Jakarta EE Security Permissions Set.

As defined in Declaring Permissions Required by Application Components,” a component provider may declare the permissions required by the application classes and libraries packaged in a module. When a component provider has declared the permissions required by a module, on successful deployment of the module, at least the declared permissions must have been granted to the application classes and libraries packaged in the module. If security permissions are declared that conflict with the policy of the product installation, the Jakarta EE product must fail deployment of the application module. If an application module does not contain a declaration of required security permissions and deployment otherwise succeeds, the Jakarta EE product must grant the application classes and libraries the permissions established by the security policy of the installation. The Jakarta EE product must ensure that the system administrator for the installation be able to define the security policy for the installation to include the permissions in Jakarta EE Security Permissions Set.

Note that, on some installations of Jakarta EE products, the security policy of the installation may be such that applications are granted fewer permissions than those defined in

Jakarta EE Security Permissions Set and, as a result, some applications that declare only the permissions defined in Jakarta EE Security Permissions Set may not be deployable. Other applications that require the same permissions but do not declare them may deploy but will encounter runtime failures when the missing permission is required by the application component.

Every Jakarta EE product must be capable of running with a Java security manager and with an installation policy that does not grant the permissions described in Restrictable Jakarta EE Security Permissions to Web, enterprise beans, and resource adapter components. That environment must otherwise fully support the requirements of this specification.

Application Component Provider’s Responsibilities

To ensure that application deployment will only succeed if required permissions are compatible with security policy of the installation environment, application component providers should declare all Java security permissions required by their application components.

Declaring Permissions Required by Application Components,” defines the mechanism(s) by which required permissions may be declared.

Note that, while FilePermissions or SocketPermissions for specific resources may be granted as a result of application components declaring them as required, the local operating system or network security policy may restrict access to the requested resources. This may result in a runtime failure to access these resources even though deployment of the application has succeeded.

System Administrator’s Responsibilities

Security policy requirements differ from one installation environment to another. The system administrator is responsible for configuring the permissions available to application modules to meet the security policy requirements of the installation environment. For example, cloud environments may require greater restrictions on the system resources available to applications than on-premise enterprise installations. Note that restricting the permissions beyond those in Jakarta EE Security Permissions Set may prevent some applications from working correctly.

Care should be taken by the system administrator to ensure that resources that are expected to be available to application components are appropriately represented in the security policy of the operational environment.

In particular, the temporary file directory made available through the ServletContext attribute javax.servlet.context.tempdir should be available to deployed applications. The security policy of the operational environment should grant the application server process access to the corresponding part of the file system. The Jakarta EE Product must be capable of using the security manager to enforce that an application only has access to the part of the filesystem namespace named by the javax.security.context.tempdir attribute, and that that part of the filesystem namespace is separate from the corresponding filesystem namespace available to other applications.

Listing of the Jakarta EE Security Permissions Set

Jakarta EE Security Permissions Set lists the Java permissions that Jakarta EE components (by type) can reliably be granted by a Jakarta EE product, given appropriate local installation configuration.

Table 2. Jakarta EE Security Permissions Set
Security Permissions Target Action

Application Clients

java.awt.AWTPermission

accessClipboard

java.awt.AWTPermission

accessEventQueue

java.awt.AWTPermission

showWindowWithout WarningBanner

java.lang.RuntimePermission

exitVM

java.lang.RuntimePermission

loadLibrary.*

java.lang.RuntimePermission

queuePrintJob

java.net.SocketPermission

*

connect

java.net.SocketPermission

localhost:1024-

accept,listen

java.io.FilePermission

*

read,write

java.util.PropertyPermission

*

read

Applet Clients

java.net.SocketPermission

codebase

connect

java.util.PropertyPermission

limited

read

Web, Enterprise Beans, and Resource Adapter Components

java.lang.RuntimePermission

loadLibrary.*

java.lang.RuntimePermission

queuePrintJob

java.net.SocketPermission

*

connect

java.io.FilePermission

*

read,write [6]

java.io.FilePermission

file:${javax.servlet.context.tempdir}

read, write [7]

java.util.PropertyPermission

*

read
Restrictable Jakarta EE Security Permissions

Restrictable Jakarta EE Security Permissions lists the Java permissions that a Jakarta EE product must be capable of restricting when running a Web or Enterprise Beans application component. If the Target field is empty, a Jakarta EE product must be capable of deploying application modules such that no instances of that permission are granted to the components in the application module.

Table 3. Restrictable Jakarta EE Security Permissions
Security Permissions Target Action

Web, Enterprise Beans, and Resource Adapter Components

java.security.AllPermission

java.security.SecurityPermission

java.security.UnresolvedPermission

java.awt.AWTPermission

java.io.SerializablePermission

java.lang.reflect.ReflectPermission

java.lang.RuntimePermission

<any except loadLibrary.* and queuePrintJob> [8]

java.net.NetPermission

java.sql.SQLPermission

java.util.PropertyPermission

<any>

write [9]

java.util.logging.LoggingPermission

javax.net.ssl.SSLPermission

java.security.auth.AuthPermission

java.security.auth.PrivateCredentialPermission

java.security.auth.kerberos.DelegationPermission

java.security.auth.kerberos.ServicePermission

javax.sound.sampled.AudioPermission
Declaring Permissions Required by Application Components

By declaring the permissions required by an application as described in this section, an application component provider is ensured, through the successful deployment of his or her application, that the Jakarta EE Product has granted at least the declared permissions to the classes and libraries packaged in the application module.

Since the specific set of permissions granted to a successfully deployed application is a function of the security policy for the installation and the permissions declared within the permissions.xml files, the application component provider is ensured that the effective permission set consists of at least those permissions that are declared within the application.

Permission declarations must be stored in META-INF/permissions.xml file within an enterprise beans, web, application client, or resource adapter archive in order for them to be located and subsequently processed by the deployment machinery of the Jakarta EE Product. The Jakarta EE Product is not required to support permissions.xml files that specify permission classes that are packaged in the application.

The permissions for a packaged library are the same as the permissions for the module. Thus, if a library is packaged in a .war file, it gets the permissions of the .war file.

For applications packaged in an .ear file, the declaration of permissions must be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules. Any permissions.xml files within such packaged modules are ignored, regardless of whether a permissions.xml file has been supplied for the .ear file itself.

The fact that these permission declarations are being made from within the context of a particular application implies the codeBase(s) to which the grant should be made. This simplifies the syntax that is needed to just the Permission class name and two String arguments. This aligns the declaration syntax with the default policy language and the constructor signature for permissions that is compliant with the default policy syntax.

permission <class> [<name> [, <action list>]];

The following is an example of a permission set declaration:

...
<permissions>
  <permission>
    <class-name>java.io.FilePermission</class-name>
    <name>/tmp/abc</name>
    <actions>read,write</actions>
  </permission>
  <permission>
    <class-name>java.lang.RuntimePermission</class-name>
    <name>createClassLoader</name>
  </permission>
</permissions>
...

The Jakarta EE permissions XML Schema is located at http://xmlns.jcp.org/xml/ns/javaee/permissions_8.xsd .

Additional Requirements

Networking

The Java SE platform includes a pluggable mechanism for supporting multiple URL protocols through the java.net.URLStreamHandler class and the java.net.URLStreamHandlerFactory interface.

The following URL protocols must be supported:

  • file : Only reading from a file URL need be supported. That is, the corresponding URLConnection object’s getOutputStream method may fail with an UnknownServiceException . File access is restricted according to the permissions described above.

  • http : Version 1.1 of the HTTP protocol must be supported. An http URL must support both input and output.

  • https : SSL version 3.0 and TLS version 1.2 must be supported by https URL objects. Both input and output must be supported.

The Java SE platform also includes a mechanism for converting a URL’s byte stream to an appropriate object, using the java.net.ContentHandler class and java.net.ContentHandlerFactory interface. A ContentHandler object can convert a MIME byte stream to an object. ContentHandler objects are typically accessed indirectly using the getContent method of URL and URLConnection .

When accessing data of the following MIME types using the getContent method, objects of the corresponding Java type listed in Java Type of Objects Returned When Using the getContent Method must be returned.

Table 4. Java Type of Objects Returned When Using the getContent Method
MIME Type Java Type

image/gif

java.awt.Image

image/jpeg

java.awt.Image

image/png

java.awt.Image

Many environments will use HTTP proxies rather than connecting directly to HTTP servers. If HTTP proxies are being used in the local environment, the HTTP support in the Java SE platform should be configured to use the proxy appropriately. Application components must not be required to configure proxy support in order to use an http URL.

Most enterprise environments will include a firewall that limits access from the internal network (intranet) to the public Internet, and vice versa. It is typical for access using the HTTP protocol to pass through such firewalls, perhaps by using proxy servers. It is not typical that general TCP/IP traffic, including RMI-JRMP, and RMI-IIOP, can pass through firewalls.

These considerations have implications on the use of various protocols to communicate between application components. This specification requires that HTTP access through firewalls be possible where local policy allows. Some Jakarta EE products may provide support for tunneling other communication through firewalls, but this is neither specified nor required. Application developers should consider the impact of these issues in the design of applications, particularly in view of cloud environments, where a cloud platform provider might only allow HTTP-based access.

JDBC™ API

The JDBC API, which is part of the Java SE platform, allows for access to a wide range of data storage systems. The Java SE platform, however, does not require that a system meeting the Java Compatible™ quality standards provide a database that is accessible through the JDBC API.

To allow for the development of portable applications, the Jakarta EE specification does require that such a database be available and accessible from a Jakarta EE product through the JDBC API. Such a database must be accessible from web components, enterprise beans, and application clients, but need not be accessible from applets. In addition, the driver for the database must meet the JDBC Compatible requirements in the JDBC specification.

Jakarta EE applications should not attempt to load JDBC drivers directly. Instead, they should use the technique recommended in the JDBC specification and perform a JNDI lookup to locate a DataSource object. The JNDI name of the DataSource object should be chosen as described in Resource Manager Connection Factory References.” The Jakarta EE platform must be able to supply a DataSource that does not require the application to supply any authentication information when obtaining a database connection. Of course, applications may also supply a user name and password when connecting to the database.

When a JDBC API connection is used in an enterprise bean , the transaction characteristics will typically be controlled by the container. The component should not attempt to change the transaction characteristics of the connection, commit the transaction, roll back the transaction, or set autocommit mode. Attempts to make changes that are incompatible with the current transaction context may result in a SQLException being thrown. The Jakarta Enterprise Beans specification contains the precise rules for enterprise beans.

Note that the same restrictions apply when a component creates a transaction using the Jakarta Transactions UserTransaction interface. The component should not attempt the operations listed above on the JDBC Connection object that would conflict with the transaction context.

Drivers supporting the JDBC API in a Jakarta EE environment must meet the JDBC API Compliance requirements as specified in the JDBC specification.

The JDBC API includes APIs for connection naming via JNDI, connection pooling, and distributed transaction support. The connection pooling and distributed transaction features are intended for use by JDBC drivers to coordinate with an application server. Jakarta EE products are not required to support the application server facilities described by these APIs, although they may prove useful.

The Connector architecture defines an SPI that essentially extends the functionality of the JDBC SPI with additional security functionality, and a full packaging and deployment functionality for resource adapters. A Jakarta EE product that supports the Connector architecture must support deploying and using a JDBC driver that has been written and packaged as a resource adapter using the Connector architecture.

The JDBC 4.2 specification is available at https://jcp.org/en/jsr/detail?id=221 .

Jakarta API for XML Web Services (JAX-WS) Requirements

The JAX-WS specification provides support for web services that use the JAXB API for binding XML data to Java objects. The JAX-WS specification defines client APIs for accessing web services as well as techniques for implementing web service endpoints. The Web Services for Jakarta EE specification describes the deployment of JAX-WS-based services and clients. The Enterprise Beans and Servlet specifications also describe aspects of such deployment. It must be possible to deploy JAX-WS-based applications using any of these deployment models.

The JAX-WS 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 JAX-WS client or endpoint component with which they are associated. These message handlers have access to the same JNDI java:comp/env namespace as their associated component. Custom serializers and deserializers, if supported, are treated in the same way as message handlers.

The JAX-WS specification is available at http://jcp.org/en/jsr/summary?id=224 .

Java IDL (Proposed Optional)

The requirements in this section only apply to Jakarta EE products that support interoperability using CORBA.

Java IDL allows applications to access any CORBA object, written in any language, using the standard IIOP protocol. The Jakarta EE security restrictions typically prevent all application component types except application clients from creating and exporting a CORBA object, but all Jakarta EE application component types can be clients of CORBA objects.

A Jakarta EE product must support Java IDL as defined by chapters 1 - 8, 13, and 15 of the CORBA 2.3.1 specification, available at http://www.omg.org/cgi-bin/doc?formal/99-10-07 , and the IDL To Java Language Mapping Specification, available at http://www.omg.org/cgi-bin/doc?ptc/2000-01-08 .

The IIOP protocol supports the ability to multiplex calls over a single connection. All Jakarta EE products must support requests from clients that multiplex calls on a connection to either Java IDL server objects or RMI-IIOP server objects (such as enterprise beans). The server must allow replies to be sent in any order, to avoid deadlocks where one call would be blocked waiting for another call to complete. Jakarta EE clients are not required to multiplex calls, although such support is highly recommended.

A Jakarta EE product must provide support for a CORBA Portable Object Adapter (POA) to support portable stub, skeleton, and tie classes. A Jakarta EE application that defines or uses CORBA objects other than enterprise beans must include such portable stub, skeleton, and tie classes in the application package.

Jakarta EE applications need to use an instance of org.omg.CORBA.ORB to perform many Java IDL and RMI-IIOP operations. The default ORB returned by a call to ORB.init(new String[0], null) must be usable for such purposes; an application need not be aware of the implementation classes used for the ORB and RMI-IIOP support.

In addition, for performance reasons it is often advantageous to share an ORB instance among components in an application. To support such usage, all web, enterprise bean, and application client containers are required to provide an ORB instance in the JNDI namespace under the name java:comp/ORB . The container is allowed, but not required, to share this instance between components. The container may also use this ORB instance itself. To support isolation between applications, an ORB instance should not be shared between components in different applications. To allow this ORB instance to be safely shared between components, portable components must restrict their usage of certain ORB APIs and functionality:

  • Do not call the ORB shutdown method.

  • Do not call the org.omg.CORBA_2_3.ORB methods register_value_factory and unregister_value_factory with an id used by the container.

A Jakarta EE product must provide a COSNaming service to support the Jakarta Enterprise Beans interoperability requirements. It must be possible to access this COSNaming service using the Java IDL COSNaming APIs. Applications with appropriate privileges must be able to lookup objects in the COSNaming service. COSNaming is defined in the Interoperable Naming Service specification, available at http://www.omg.org/cgi-bin/doc?formal/2000-06-19 .

RMI-JRMP

JRMP is the Java technology-specific Remote Method Invocation (RMI) protocol. The Jakarta EE security restrictions typically prevent all application component types except application clients from creating and exporting an RMI object, but all Jakarta EE application component types can be clients of RMI objects.

RMI-IIOP (Proposed Optional)

The requirements in this section only apply to Jakarta EE products that include an Enterprise Beans container and support interoperability using RMI-IIOP.

RMI-IIOP allows objects defined using RMI style interfaces to be accessed using the IIOP protocol. It must be possible to make any remote enterprise bean accessible via RMI-IIOP. Some Jakarta EE products will simply make all remote enterprise beans always (and only) accessible via RMI-IIOP; other products might control this via an administrative or deployment action. These and other approaches are allowed, provided that any remote enterprise bean (or by extension, all remote enterprise beans) can be made accessible using RMI-IIOP.

Components accessing remote enterprise beans may need to use the narrow method of the javax.rmi.PortableRemoteObject class, under circumstances described in the Jakarta Enterprise Beans specification. Because remote enterprise beans may be deployed using other RMI protocols, portable applications must not depend on the characteristics of RMI-IIOP objects (for example, the use of the Stub and Tie base classes) beyond what is specified in the Jakarta Enterprise Beans specification.

The Jakarta EE security restrictions typically prevent all application component types, except application clients, from creating and exporting an RMI-IIOP object. All Jakarta EE application component types can be clients of RMI-IIOP objects. Jakarta EE applications should also use JNDI to lookup non-Enterprise Beans RMI-IIOP objects. The JNDI names used for such non-Enterprise Beans RMI-IIOP objects should be configured at deployment time using the standard environment entries mechanism (see JNDI Naming Context”). The application should fetch a name from JNDI using an environment entry, and use the name to lookup the RMI-IIOP object. Typically such names will be configured to be names in the COSNaming name service.

This specification does not provide a portable way for applications to bind objects to names in a name service. Some products may support use of JNDI and COSNaming for binding objects, but this is not required. Portable Jakarta EE application clients can create non-Enterprise Beans RMI-IIOP server objects for use as callback objects, or to pass in calls to other RMI-IIOP objects.

Note that while RMI-IIOP doesn’t specify how to propagate the current security context or transaction context, the Jakarta Enterprise Beans interoperability specification does define such context propagation. This specification only requires that the propagation of context information as defined in the Jakarta Enterprise Beans specification be supported in the use of RMI-IIOP to access enterprise beans. The propagation of context information is not required in the uses of RMI-IIOP to access objects other than enterprise beans.

The RMI-IIOP specification describes how portable Stub and Tie classes can be created. To be portable to all implementations that use a CORBA Portable Object Adapter (POA), the Tie classes must extend the org.omg.PortableServer.Servant class. This is typically done by using the -poa option to the rmic command. A Jakarta EE product must provide support for these portable Stub and Tie classes, typically using the required CORBA POA. However, for portability to systems that do not use a POA to implement RMI-IIOP, applications should not depend on the fact that the Tie extends the Servant class. A Jakarta EE application that defines or uses RMI-IIOP objects other than enterprise beans must include such portable Stub and Tie classes in the application package. Stub and Tie objects for enterprise beans, however, must not be included with the application: they will be generated, if needed, by the Jakarta EE product at deployment time or at run time.

RMI-IIOP is defined by chapters 5, 6, 13, 15, and section 10.6.2 of the CORBA 2.3.1 specification, available at http://www.omg.org/cgi-bin/doc?formal/99-10-07 , and by the Java™ Language To IDL Mapping Specification, available at http://www.omg.org/cgi-bin/doc?ptc/2000-01-06 .

JNDI

A Jakarta EE product that supports the following types of objects must be able to make them available in the application’s JNDI namespace: EJBHome objects, EJBLocalHome objects, Enterprise Beans business interface objects, Jakarta Transactions UserTransaction objects, JDBC API DataSource objects, JMS ConnectionFactory and Destination objects, JavaMail Session objects, URL objects, resource manager ConnectionFactory objects (as specified in the Connector specification), ORB objects, EntityManagerFactory objects, and other Java language objects as described in Resources, Naming, and Injection.” The JNDI implementation in a Jakarta EE product must be capable of supporting all of these uses in a single application component using a single JNDI InitialContext . Application components will generally create a JNDI InitialContext using the default constructor with no arguments. The application component may then perform lookups on that InitialContext to find objects as specified above.

The names used to perform lookups for Jakarta EE objects are application dependent. The application component’s metadata annotations and/or deployment descriptor are used to list the names and types of objects expected. The Deployer configures the JNDI namespace to make appropriate components available. The JNDI names used to lookup such objects must be in the JNDI java: namespace. See Resources, Naming, and Injection” for details.

Particular names are defined by this specification for the cases when the Jakarta EE product includes the corresponding technology. For all application components that have access to the Jakarta Transaction UserTransaction interface, the appropriate UserTransaction object can be found using the name java:comp/UserTransaction . In all containers except the applet container, application components may lookup a CORBA ORB instance using the name java:comp/ORB . For all application components that have access to the CDI BeanManager interface, the appropriate BeanManager object can be found using the name java:comp/BeanManager . For all application components that have access to the Validation APIs, the appropriate Validator and ValidatorFactory objects can be found using the names java:comp/Validator and java:comp/ValidatorFactory respectively.

The name used to lookup a particular Jakarta EE object may be different in different application components. In general, JNDI names can not be meaningfully passed as arguments in remote calls from one application component to another remote component (for example, in a call to an enterprise bean ).

The JNDI java: namespace is commonly implemented as symbolic links to other naming systems. Different underlying naming services may be used to store different kinds of objects, or even different instances of objects. It is up to a Jakarta EE product to provide the necessary JNDI service providers for accessing the various objects defined in this specification.

This specification requires that the Jakarta EE platform provide the ability to perform lookup operations as described above. Different JNDI service providers may provide different capabilities, for instance, some service providers may provide only read-only access to the data in the name service.

A Jakarta EE product may be required to provide a COSNaming name service to meet the Jakarta Enterprise Beans interoperability requirements. In such a case, a COSNaming JNDI service provider must be available through the web, Enterprise Beans, and application client containers. It will also typically be available in the applet container, but this is not required.

A COSNaming JNDI service provider is a part of the Java SE 8 SDK and JRE from Oracle, but is not a required component of the Java SE specification. The COSNaming JNDI service provider specification is available at http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-cos.html .

See Resources, Naming, and Injection” for the complete naming requirements for the Jakarta EE platform. The JNDI specification is available at http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/index.html .

Context Class Loader

This specification requires that Jakarta EE containers provide a per thread context class loader for the use of system or library classes in dynamically loading classes provided by the application. The Jakarta Enterprise Beans specification requires that all Jakarta Enterprise Beans client containers provide a per thread context class loader for dynamically loading system value classes. The per thread context class loader is accessed using the Thread method getContextClassLoader .

The classes used by an application will typically be loaded by a hierarchy of class loaders. There may be a top level application class loader, an extension class loader, and so on, down to a system class loader. The top level application class loader delegates to the lower class loaders as needed. Classes loaded by lower class loaders, such as portable Jakarta Enterprise Beans system value classes, need to be able to discover the top level application class loader used to dynamically load application classes.

This specification requires that containers provide a per thread context class loader that can be used to load top level application classes as described above. See Dynamic Class Loading” for recommendations for libraries that dynamically load classes.

Jakarta Authentication Requirements

All enterprise beans containers and all web containers must support the use of the Jakarta Authentication APIs as specified in the Connector specification. All application client containers must support use of the Jakarta Authentication APIs.

The Jakarta Authentication specification is available at https://jakarta.ee/specifications/authentication .

Logging API Requirements

The Logging API provides classes and interfaces in the java.util.logging package that are the Java™ platform’s core logging facilities. This specification does not require any additional support for logging. A Jakarta EE application typically will not have the LoggingPermission necessary to control the logging configuration, but may use the logging API to produce log records. A future version of this specification may require that the Jakarta EE containers use the logging API to log certain events.

Preferences API Requirements

The Preferences API in the java.util.prefs package allows applications to store and retrieve user and system preference and configuration data. A Jakarta EE application typically will not have the RuntimePermission("preferences") necessary to use the Preferences API. This specification does not define any relationship between the principal used by a Jakarta EE application and the user preferences tree defined by the Preferences API. A future version of this specification may define the use of the Preferences API by Jakarta EE applications.

Jakarta Enterprise Beans 3.2 Requirements

This specification requires that a Jakarta EE product provide support for enterprise beans as specified in the Jakarta Enterprise Beans specification. The Jakarta Enterprise Beans specification is available at https://jakarta.ee/specifications/enterprise-beans .

This specification does not impose any additional requirements at this time. Note that the Jakarta Enterprise Beans specification includes the specification of the Jakarta Enterprise Beans interoperability protocol based on RMI-IIOP. Support for the Jakarta Enterprise Beans interoperability protocol is Proposed Optional in Jakarta EE 8. All containers that support Jakarta Enterprise Beans clients must be capable of using the Jakarta Enterprise Beans interoperability protocol to invoke enterprise beans. All Jakarta Enterprise Beans containers must support the invocation of enterprise beans using the Jakarta Enterprise Beans interoperability protocol. A Jakarta EE product may also support other protocols for the invocation of enterprise beans.

A Jakarta EE product may support multiple object systems (for example, RMI-IIOP and RMI-JRMP). It may not always be possible to pass object references from one object system to objects in another object system. However, when an enterprise bean is using the RMI-IIOP protocol, it must be possible to pass object references for RMI-IIOP or Java IDL objects as arguments to methods on such an enterprise bean, and to return such object references as return values of a method on such an enterprise bean. In addition, it must be possible to pass a reference to an RMI-IIOP-based enterprise bean’s Home or Remote interface to a method on an RMI-IIOP or Java IDL object, or to return such an enterprise bean object reference as a return value from such an RMI-IIOP or Java IDL object.

In a Jakarta EE product that includes both an enterprise beans container and a web container, both containers are required to support access to local enterprise beans. No support is provided for access to local enterprise beans from the application client container or the applet container.

Jakarta Servlet 4.0 Requirements

The Jakarta Servlet specification defines the packaging and deployment of web applications, whether standalone or as part of a Jakarta EE application. The Servlet specification also addresses security, both standalone and within the Jakarta EE platform. These optional components of the Servlet specification are requirements of the Jakarta EE platform.

The Servlet specification includes additional requirements for web containers that are part of a Jakarta EE product and a Jakarta EE product must meet these requirements as well.

The Servlet specification defines distributable web applications. To support Jakarta EE applications that are distributable, this specification adds the following requirements.

Web containers must support Jakarta EE distributable web applications placing objects of any of the following types (when supported by the Jakarta EE product) into a javax.servlet.http.HttpSession object using the setAttribute or putValue methods:

java.io.Serializable

  • javax.ejb.EJBObject

  • javax.ejb.EJBHome

  • javax.ejb.EJBLocalObject

  • javax.ejb.EJBLocalHome

  • javax.transaction.UserTransaction

  • a javax.naming.Context object for the java:comp/env context

a reference to an Enterprise Bean local or remote business interface or no-interface view

Web containers may support objects of other types as well. Web containers must throw a java.lang.IllegalArgumentException if an object that is not one of the above types, or another type supported by the container, is passed to the setAttribute or putValue methods of an HttpSession object corresponding to a Jakarta EE distributable session. This exception indicates to the programmer that the web container does not support moving the object between VMs. A web container that supports multi-VM operation must ensure that, when a session is moved from one VM to another, all objects of supported types are accurately recreated on the target VM.

The Servlet specification defines access to local enterprise beans as an optional feature. This specification requires that all Jakarta EE products that include both a web container and an Enterprise Beans container provide support for access to local enterprise beans from the web container.

The Jakarta Servlet specification is available at https://jakarta.ee/specifications/servlet .

Jakarta Server Pages 2.3 Requirements

The Jakarta Server Pages specification depends on and builds on the servlet framework. A Jakarta EE product must support the entire Jakarta Server Pages specification.

The Jakarta Server Pages specification is available at https://jakarta.ee/specifications/pages .

Jakarta Expression Language (EL) 3.0 Requirements

The Jakarta Expression Language specification was formerly a part of the Jakarta Server Pages specification. It was split off into its own specification so that it could be used independently of Jakarta Server Pages. A Jakarta EE product must support the Expression Language.

The Jakarta Expression Language specification is available at https://jakarta.ee/specifications/expression-language .

Jakarta Messaging 2.0 Requirements

A Jakarta Messaging provider must be included in a Jakarta EE product that requires support for Jakarta Messaging. The Jakarta Messaging implementation must provide support for both Jakarta Messaging point-to-point and publish/subscribe messaging, and thus must make those facilities available using the ConnectionFactory and Destination APIs.

The Jakarta Messaging specification defines several interfaces intended for integration with an application server. A Jakarta EE product need not provide objects that implement these interfaces, and portable Jakarta EE applications must not use the following interfaces:

  • javax.jms.ServerSession

  • javax.jms.ServerSessionPool

  • javax.jms.ConnectionConsumer

all javax.jms XA interfaces

The following methods may only be used by application components executing in the application client container:

  • javax.jms.MessageConsumer method getMessageListener

  • javax.jms.MessageConsumer method setMessageListener

  • javax.jms.JMSConsumer method getMessageListener

  • javax.jms.JMSConsumer method setMessageListener

  • javax.jms.Connection method setExceptionListener

  • javax.jms.Connection method stop

  • javax.jms.Connection method setClientID

  • javax.jms.JMSContext method stop

  • javax.jms.JMSContext method setClientID

  • javax.jms.JMSContext method setExceptionListener

  • javax.jms.JMSContext method createContext

  • javax.jms.Producer method setAsync

  • javax.jms.MessageProducer method send(Message message, CompletionListener completionListener)

  • javax.jms.MessageProducer method send(Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

  • javax.jms.MessageProducer method send(Destination destination, Message message, CompletionListener completionListener)

  • javax.jms.MessageProducer method send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

The following methods may only be used by application components executing in the application client container. Note, however, that these methods provide an expert facility not used by ordinary applications. See the JMS specification for further detail.

javax.jms.Session method setMessageListener

  • javax.jms.Session method getMessageListener

  • javax.jms.Session method run

  • javax.jms.Connection method createConnectionConsumer

  • javax.jms.Connection method createSharedConnectionConsumer

  • javax.jms.Connection method createDurableConnectionConsumer

javax.jms.Connection method createSharedDurableConnectionConsumer

A Jakarta EE container may throw a JMSException (if allowed by the method) or a JMSRuntimeException (if throwing a JMSException is not allowed by the method) if the application component violates any of the above restrictions.

Application components in the web and enterprise bean containers must not attempt to create more than one active (not closed) Session object per connection. An attempt to use the Connection object’s createSession method when an active Session object exists for that connection should be prohibited by the container. The container should throw a JMSException if the application component violates this restriction. An attempt to use the JMSContext object’s createContext method should be prohibited by the container. The container should throw a JMSRuntimeException , since the first JMSContext already contains a connection and session and this method would create a second session on the same connection. Application client containers must support the creation of multiple sessions for each connection.

The Jakarta Messaging specification defines further restrictions on the use of Jakarta Messaging in the Enterprise Beans and web containers. In general, the behavior of a Jakarta Messaging provider should be the same in both the enterprise beans container and the web container.

The Jakarta Messaging specification is available at _ https://jakarta.ee/specifications/messaging_ .

Jakarta Transaction 1.3 Requirements

Jakarta Transaction defines the UserTransaction interface that is used by applications to start, and commit or abort transactions. Application components get a UserTransaction object through a JNDI lookup using the name java:comp/UserTransaction or by requesting injection of a UserTransaction object.

Jakarta Transaction also defines the TransactionSynchronizationRegistry interface that can be used by system level components such as persistence managers to interact with the transaction manager. These components get a TransactionSynchronizationRegistry object through a JNDI lookup using the name java:comp/TransactionSynchronizationRegistry or by requesting injection of a TransactionSynchronizationRegistry object.

A number of interfaces defined by Jakarta Transaction are used by an application server to communicate with a transaction manager, and for a transaction manager to interact with a resource manager. These interfaces must be supported as described in the Connector specification. In addition, support for other transaction facilities may be provided transparently to the application by a Jakarta EE product.

The Jakarta Transaction specification is available at https://jakarta.ee/specifications/transactions .

Jakarta Mail 1.6 Requirements

The Jakarta Mail API allows for access to email messages contained in message stores, and for the creation and sending of email messages using a message transport. Specific support is included for Internet standard MIME messages. Access to message stores and transports is through protocol providers supporting specific store and transport protocols. The Jakarta Mail API specification does not require any specific protocol providers, but the JavaMail reference implementation includes an IMAP message store provider, a POP3 message store provider, and an SMTP message transport provider.

Configuration of the Jakarta Mail API is typically done by setting properties in a Properties object that is used to create a javax.mail.Session object using a static factory method. To allow the Jakarta EE platform to configure and manage JavaMail API sessions, an application component that uses the JavaMail API should request a Session object using JNDI, and should list its need for a Session object in its deployment descriptor using a resource-ref element, or by using a Resource annotation. A Jakarta Mail API Session object should be considered a resource factory, as described in Resource Manager Connection Factory References.” This specification requires that the Jakarta EE platform support javax.mail.Session objects as resource factories, as described in that section.

The Jakarta EE platform requires that a message transport be provided that is capable of handling addresses of type javax.mail.internet.InternetAddress and messages of type javax.mail.internet.MimeMessage . The default message transport must be properly configured to send such messages using the send method of the javax.mail.Transport class. Any authentication needed by the default transport must be handled without need for the application to provide a javax.mail.Authenticator or to explicitly connect to the transport and supply authentication information.

This specification does not require that a Jakarta EE product support any message store protocols.

Note that the Jakarta Mail API creates threads to deliver notifications of Store , Folder , and Transport events. The use of these notification facilities may be limited by the restrictions on the use of threads in various containers. In Enterprise Beans containers, for instance, it is typically not possible to create threads.

The Jakarta Mail API uses the JavaBeans Activation Framework API to support various MIME data types. The Jakarta Mail API must include javax.activation.DataContentHandlers for the following MIME data types, corresponding to the Java programming language type indicated in JavaMail API MIME Data Type to Java Type Mappings .

Table 5. Jakarta Mail API MIME Data Type to Java Type Mappings
Mime Type Java Type

text/plain

java.lang.String

text/html_

java.lang.String

text/xml

java.lang.String

multipart/*

javax.mail.internet.MimeMultipart

message/rfc822

javax.mail.internet.MimeMessage

The Jakarta Mail API specification is available at https://jakarta.ee/specifications/mail .

Jakarta EE Connectors 1.7 Requirements

In full Jakarta EE products, all Jakarta Enterprise Beans containers and all web containers must support the full set of Connector APIs. All such containers must support Resource Adapters that use any of the specified transaction capabilities. The Jakarta EE deployment tools must support deployment of Resource Adapters, as defined in the Connector specification, and must support the deployment of applications that use Resource Adapters.

The Jakarta EE Connectors specification is available at https://jakarta.ee/specifications/connectors .

Jakarta XML RPC 1.1 Requirements (Optional)

The Jakarta XML RPC specification defines client APIs for accessing web services as well as techniques for implementing web service endpoints. The Web Services for Jakarta EE specification describes the deployment of Jakarta XML RPC-based services and clients. The Jakarta Enterprise Beans and Servlet specifications also describe aspects of such deployment. In Jakarta EE products that support Jakarta XML RPC, it must be possible to deploy Jakarta XML RPC-based applications using any of these deployment models.

The Jakarta XML RPC 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 RPC client or endpoint component with which they are associated. These message handlers have access to the same JNDI java:comp/env namespace as their associated component. Custom serializers and deserializers, if supported, are treated in the same way as message handlers.

Note that neither web service annotations nor injection is supported for Jakarta XML RPC service endpoints and handlers. New applications are encouraged to use Jakarta XML Web Services to take advantage of these new facilities that make it easier to write web services.

The Jakarta XML RPC specification is available at https://jakarta.ee/specifications/xml-rpc .

Jakarta RESTful Web Services 2.1 Requirements

Jakarta RESTful Web Services defines APIs for the development of Web services built according to the Representational State Transfer (REST) architectural style.

In a full Jakarta EE product, all Jakarta EE web containers are required to support applications that use Jakarta RESTful Web Services technology.

The specification describes the deployment of services as a servlet. It must be possible to deploy Jakarta RESTful Web Services-based applications using this deployment model with the servlet-class element of the web.xml descriptor naming the application-supplied extension of the Jakarta RESTful Web Services Application abstract class.

The specification defines a set of optional container-managed facilities and resources that are intended to be available in a Jakarta EE container — all such features and resources must be made available.

The Jakarta RESTful Web Services specification is available at https://jakarta.ee/specifications/restful-ws .

Jakarta WebSocket 1.1 (WebSocket) Requirements

The Jakarta WebSocket (WebSocket) is a standard API for creating WebSocket applications. In a full Jakarta EE product, all Jakarta EE web containers are required to support the WebSocket API.

The Jakarta WebSocket specification can be found at https://jakarta.ee/specifications/websocket .

Jakarta JSON Processing 1.1 (JSON-P) Requirements

JSON (JavaScript Object Notation) is a lightweight data-interchange format used by many web services. The Jakarta JSON Processing (JSON-P) provides a convenient way to process (parse, generate, transform, and query) JSON text.

In a full Jakarta EE product, all Jakarta EE application client containers, web containers, and enterprise beans containers are required to support the JSON-P API.

The Jakarta JSON Processing specification can be found at https://jakarta.ee/specifications/jsonp .

Jakarta JSON Binding 1.0 (JSON-B) Requirements

The Jakarta JSON Binding API for JSON Binding (JSON-B) provides a convenient way to map between JSON text and Java objects.

In a full Jakarta EE product, all Jakarta EE application client containers, web containers, and enterprise beans containers are required to support the JSON-B API.

The Jakarta JSON Binding specification can be found at https://jakarta.ee/specifications/jsonb.

Jakarta Concurrency 1.1 (Concurrency Utilities) Requirements

Jakarta Concurrency Utilities for Jakarta EE 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. In a full Jakarta EE product, all web containers and enterprise beans containers are required to support the Concurrency Utilities API. The Jakarta EE Product Provider must provide preconfigured default managed executor service, managed scheduled executor service, managed thread factory, and context service objects for use by the application in the containers in which the Concurrency Utilities API is required to be supported.

The Jakarta Concurrency specification can be found at https://jakarta.ee/specifications/concurrency .

Jakarta Batch 1.0 Specification Requirements

The Jakarta Batch provides a programming model for batch applications and a runtime for scheduling and executing jobs.

In a full Jakarta EE product, all Jakarta EE web containers and Jakarta Enterprise Beans containers are required to support the Batch API.

The Jakarta Batch specification can be found at https://jakarta.ee/specifications/batch .

Jakarta XML Registries 1.0 Requirements (Optional)

The Jakarta XML Registries specification defines APIs for client access to XML-based registries such as ebXML registries and UDDI registries. Jakarta EE products that support Jakarta XML Registries must include a Jakarta XML registry provider that meets at least the Jakarta XML Registries level 0 requirements.

The Jakarta XML Registries specification is available at https://jakarta.ee/specifications/xml-registries .

Jakarta Management 1.1 Requirements

Jakarta Management provides APIs for management tools to query a Jakarta EE application server to determine its current status, applications deployed, and so on. All Jakarta EE products must support this API as described in its specification.

The Jakarta Management specification is available at https://jakarta.ee/specifications/management .

Jakarta Deployment API 1.7 Requirements (Optional)

The Jakarta Deployment API defines the interfaces between the runtime environment of a deployment tool and plug-in components provided by a Jakarta EE application server. These plug-in components execute in the deployment tool and implement the Jakarta EE product-specific deployment mechanisms. Jakarta EE products that support the Jakarta Deployment API are required to supply these plug-in components for use in tools from other vendors.

Note that the Jakarta Deployment specification does not define new APIs for direct use by Jakarta EE applications. However, it would be possible to create a Jakarta EE application that acts as a deployment tool and provides the runtime environment required by the Jakarta Deployment The Jakarta EE Deployment API specification is available at https://jakarta.ee/specifications/deployment .

Jakarta Authorization 1.5 Requirements

The Jakarta Authorization specification defines a contract between a Jakarta EE application server and an authorization policy provider. In a full Jakarta EE product, all Jakarta EE web containers and enterprise bean containers are required to support this contract.

The Jakarta Authorization specification can be found at https://jakarta.ee/specifications/authorization .

Jakarta Authentication 1.1 Requirements

The Jakarta Authentication specification defines a service provider interface (SPI) by which authentication providers implementing 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 container. They transform outgoing messages such that the source of the message may be authenticated by the receiving container, and the recipient of the message may be authenticated by the message sender. They authenticate incoming messages and return to their calling container the identity established as a result of the message authentication.

In a full Jakarta EE product, all Jakarta EE web containers and enterprise bean containers are required to support the baseline compatibility requirements as defined by the Jakarta Authentication specification. In a full Jakarta EE product, all web containers must also support the Servlet Container Profile as defined in the Jakarta Authentication specification. In a Jakarta EE profile product that includes Servlet and Jakarta Authentication, all web containers must also support the Servlet Container Profile as defined in the Jakarta Authentication specification. Support for the Jakarta Authentication SOAP Profile is not required.

The Jakarta Authentication specification can be found at https://jakarta.ee/specifications/authentication .

Jakarta Security 1.0 Requirements

Jakarta Security leverages Jakarta Authentication , but provides an easier to use SPI for authentication of users of web applications and defines identity store APIs for authentication and authorization.

In a full Jakarta EE product, all Jakarta EE web containers and enterprise bean containers are required to support the requirements defined by the Jakarta Security specification.

The Jakarta Security Specification can be found at https://jakarta.ee/specifications/security .

Jakarta Debugging Support for Other Languages Requirements 1.0

Jakarta Server Pages pages are usually translated into Java language pages and then compiled to create class files. The Jakarta Debugging Support for Other Languages specification describes information that can be included in a class file to relate class file data to data in the original source file. All Jakarta EE products are required to be able to include such information in class files that are generated from Jakarta Server Pages.

The Jakarta Debugging Support for Other Languages specification can be found at https://jakarta.ee/specifications/debugging .

Jakarta Standard Tag Library for Jakarta Server Pages 1.2 Requirements

Jakarta Standard Tag Library specification defines a standard tag library that makes it easier to develop Jakarta Server Pages Pages. All Jakarta EE products are required to provide a Jakarta Standard Tag Library for use by all Jakarta Server Pages.

The Jakarta Standard Tag Library for Jakarta Server Pages specification can be found at https://jakarta.ee/specifications/tags .

Jakarta Server Faces 2.3 Requirements

Jakarta Server Faces technology simplifies building user interfaces for Jakarta applications. Developers of various skill levels can quickly build web applications by: assembling reusable UI components in a page; connecting these components to an application data source; and wiring client-generated events to server-side event handlers. In a full Jakarta EE product, all Jakarta EE web containers are required to support applications that use the Jakarta Server Faces technology.

The Jakarta Server Faces specification can be found at https://jakarta.ee/specifications/faces .

Jakarta Annotations 1.3 Requirements

The Jakarta Annotations specification defines Java language annotations that are used by several other specifications, including this specification. The specifications that use these annotations fully define the requirements for these annotations. The applet container need not support any of these annotations. All other containers must provide definitions for all of these annotations, and must support the semantics of these annotations as described in the corresponding specifications and summarized in the following table.

Table 6. Common Annotations Support by Container
Annotation App Client Web Enterprise Beans

Resource

Y

Y

Y

Resources

Y

Y

Y

PostConstruct

Y

Y

Y

PreDestroy

Y

Y

Y

Generated

N

N

N

RunAs

N

Y

Y

DeclareRoles

N

Y

Y

RolesAllowed

N

Y

Y

PermitAll

N

Y

Y

DenyAll

N

Y

Y

ManagedBean

Y

Y

Y

DataSourceDefinition

Y

Y

Y

DataSourceDefinitions

Y

Y

Y

Priority

Y

Y

Y

The Jakarta Annotations specification can be found at https://jakarta.ee/specifications/annotations .

Jakarta Persistence 2.2 Requirements

Jakarta Persistence is the standard API for the management of persistence and object/relational mapping. The Jakarta Persistence specification provides an object/relational mapping facility for application developers using a Java domain model to manage a relational database.

As mandated by the Jakarta Persistence specification, in a Jakarta EE environment the classes of the persistence unit should not be loaded by the application class loader or any of its parent class loaders until after the entity manager factory for the persistence unit has been created.

The Jakarta Persistence specification can be found at https://jakarta.ee/specifications/persistence .

Bean Validation 2.0 Requirements

The Bean Validation specification defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the metadata through the use of XML validation descriptors.

The Jakarta EE platform requires that web containers make an instance of ValidatorFactory available to Jakarta Server Faces implementations by storing it in a servlet context attribute named javax.faces.validator.beanValidator.ValidatorFactory.

The Jakarta EE platform also requires that an instance of ValidatorFactory be made available to Jakarta Persistence providers as a property in the map that is passed as the second argument to the createContainerEntityManagerFactory(PersistenceUnitInfo, Map) method of the PersistenceProvider interface, under the name javax.persistence.validation.factory .

Additional requirements on Jakarta EE platform containers are specified in the Bean Validation specification, which can be found at https://jakarta.ee/specifications/bean-validation .

Managed Beans 1.0 Requirements

The Managed Beans specification defines a lightweight component model that supports the basic lifecycle model, resource injection facility and interceptor service present in the Jakarta EE platform.

The Managed Beans specification can be found at https://jakarta.ee/specifications/managed-beans .

Interceptors 1.2 Requirements

The Interceptors specification makes more generally available the interceptor facility originally defined as part of the Jakarta Enterprise Beans 3.0 specification.

The Interceptors specification can be found at https://jakarta.ee/specifications/interceptors .

Contexts and Dependency Injection for the Jakarta EE Platform 2.0 Requirements

The Contexts and Dependency Injection (CDI) specification defines a set of contextual services, provided by Jakarta EE containers, aimed at simplifying the creation of applications that use both web tier and business tier technologies.

The CDI specification can be found at https://jakarta.ee/specifications/cdi .

Dependency Injection for Java 1.0 Requirements

The Dependency Injection for Java (DI) specification defines a standard set of annotations (and one interface) for use on injectable classes.

In the Jakarta EE platform, support for Dependency Injection is mediated by CDI. See Support for Dependency Injection” for more detail.

The DI specification can be found at https://jakarta.ee/specifications/dependency-injection .

Enterprise Web Services 1.4 Requirements

The Enterprise Web Services specification defines the integration between the various Web Service technologies in Jakarta EE, including XML-RPC, XMl Web Services and XML Web Service Metadata.

The Enterprise Web Services specification can be found at https://jakarta.ee/specifications/enterprise-ws .

1. Client APIs only.
2. Jakarta™ Enterprise Beans entity beans and associated query language only.
3. IIOP interoperability, including Jakarta™ Enterprise Beans 2.x and 1.x client view.
4. See Jakarta™ Enterprise Edition Deployment API 1.7 Requirements (Optional) for details.
5. Note that a component specification is permitted to specify an exception to this in order to accommodate interface type dependencies—for example, the Jakarta™ Enterprise Beans SessionContext dependency on the javax.xml.rpc.handler.MessageContext type.
6. The FilePermission * specifically refers to all files under the current directory.
7. (For Web components only.) It must be possible to grant FilePermission for the tempdir provided to web components through the ServletContext regardless of its physical location. In addition, it must be possible to grant FilePermission for the tempdir without granting it for all files under the current directory.
8. It must be possible to deploy an application module such that no instances of java.lang.RuntimePermission are granted to the components in the application module except those with a target of loadlibrary.* for any specific library or a target of queuePrintJob. Ideally a container would be capable of restricting those as well, but that is not a requirement.
9. It must be possible to deploy an application module such that no instances of java.util.PropertyPermission are granted that allow writing any property.