Packaging
We are working on a fresh, updated Jakarta EE Tutorial. This section hasn’t yet been updated. |
This chapter describes packaging. 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, and an optional deployment descriptor that describes its content.
Packaging Applications
A Jakarta EE application is delivered in a Java Archive (JAR) file, a Web Archive (WAR) file, or an Enterprise Archive (EAR) file.
A WAR or EAR file is a standard JAR (.jar
) file with a .war
or .ear
extension.
Using JAR, WAR, and EAR files and modules makes it possible to assemble a number of different Jakarta EE applications using some of the same components.
No extra coding is needed; it is only a matter of assembling (or packaging) various Jakarta EE modules into Jakarta EE JAR, WAR, or EAR files.
An EAR file (see Figure 1, “EAR File Structure”) contains Jakarta EE modules and, optionally, deployment descriptors.
A deployment descriptor, an XML document with an .xml
extension, describes the deployment settings of an application, a module, or a component.
Because deployment descriptor information is declarative, it can be changed without the need to modify the source code.
At runtime, the Jakarta EE server reads the deployment descriptor and acts upon the application, module, or component accordingly.
Deployment information is most commonly specified in the source code by annotations. Deployment descriptors, if present, override what is specified in the source code.
The two types of deployment descriptors are Jakarta EE and runtime.
A Jakarta EE deployment descriptor is defined by a Jakarta EE specification and can be used to configure deployment settings on any Jakarta EE-compliant implementation.
A runtime deployment descriptor is used to configure Jakarta EE implementation-specific parameters.
For example, the GlassFish Server runtime deployment descriptor contains such information as the context root of a web application as well as GlassFish Server implementation-specific parameters, such as caching directives.
The GlassFish Server runtime deployment descriptors are named glassfish-moduleType.xml
and are located in the same META-INF
directory as the Jakarta EE deployment descriptor.
A Jakarta EE module consists of one or more Jakarta EE components for the same container type and, optionally, one component deployment descriptor of that type. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. A Jakarta EE module can be deployed as a stand-alone module.
Jakarta EE modules are of the following types:
-
Enterprise bean modules, which contain class files for enterprise beans and, optionally, an enterprise bean deployment descriptor. Enterprise bean modules are packaged as JAR files with a
.jar
extension. -
Web modules, which contain servlet class files, web files, supporting class files, GIF and HTML files, and, optionally, a web application deployment descriptor. Web modules are packaged as JAR files with a
.war
(web archive) extension. -
Application client modules, which contain class files and, optionally, an application client deployment descriptor. Application client modules are packaged as JAR files with a
.jar
extension. -
Resource adapter modules, which contain all Java interfaces, classes, native libraries, and, optionally, a resource adapter deployment descriptor. Together, these implement the Connector architecture (see Jakarta Connectors) for a particular EIS. Resource adapter modules are packaged as JAR files with an
.rar
(resource adapter archive) extension.
Packaging Enterprise Beans
This section explains how enterprise beans can be packaged in enterprise bean JAR or WAR modules. It includes the following sections:
Packaging Enterprise Beans in enterprise bean JAR Modules
An enterprise bean JAR file is portable and can be used for various applications.
To assemble a Jakarta EE application, package one or more modules, such as enterprise bean JAR files, into an EAR file, the archive file that holds the application. When deploying the EAR file that contains the enterprise bean’s JAR file, you also deploy the enterprise bean to GlassFish Server. You can also deploy an enterprise bean JAR that is not contained in an EAR file. Figure 2, “Structure of an Enterprise Bean JAR” shows the contents of an enterprise bean JAR file.
Packaging Enterprise Beans in WAR Modules
Enterprise beans often provide the business logic of a web application. In these cases, packaging the enterprise bean within the web application’s WAR module simplifies deployment and application organization. Enterprise beans may be packaged within a WAR module as Java programming language class files or within a JAR file that is bundled within the WAR module.
To include enterprise bean class files in a WAR module, the class files should be in the WEB-INF/classes
directory.
To include a JAR file that contains enterprise beans in a WAR module, add the JAR to the WEB-INF/lib
directory of the WAR module.
WAR modules that contain enterprise beans do not require an ejb-jar.xml
deployment descriptor.
If the application uses ejb-jar.xml
, it must be located in the WAR module’s WEB-INF
directory.
JAR files that contain enterprise bean classes packaged within a WAR module are not considered enterprise bean JAR files, even if the bundled JAR file conforms to the format of an enterprise bean JAR file.
The enterprise beans contained within the JAR file are semantically equivalent to enterprise beans located in the WAR module’s WEB-INF/classes
directory, and the environment namespace of all the enterprise beans are scoped to the WAR module.
For example, suppose that a web application consists of a shopping cart enterprise bean, a credit card–processing enterprise bean, and a Java servlet front end. The shopping cart bean exposes a local, no-interface view and is defined as follows:
package com.example.cart;
@Stateless
public class CartBean { ... }
The credit card–processing bean is packaged within its own JAR file, cc.jar
, exposes a local, no-interface view, and is defined as follows:
package com.example.cc;
@Stateless
public class CreditCardBean { ... }
The servlet, com.example.web.StoreServlet
, handles the web front end and uses both CartBean
and CreditCardBean
.
The WAR module layout for this application is as follows:
WEB-INF/classes/com/example/cart/CartBean.class
WEB-INF/classes/com/example/web/StoreServlet
WEB-INF/lib/cc.jar
WEB-INF/ejb-jar.xml
WEB-INF/web.xml
Packaging Web Archives
In the Jakarta EE architecture, a web module is the smallest deployable and usable unit of web resources. A web module contains web components and static web content files, such as images, which are called web resources. A Jakarta EE web module corresponds to a web application as defined in the Jakarta Servlet specification.
In addition to web components and web resources, a web module can contain other files:
-
Server-side utility classes, such as shopping carts
-
Client-side classes, such as utility classes
A web module has a specific structure. The top-level directory of a web module is the document root of the application. The document root is where XHTML pages, client-side classes and archives, and static web resources, such as images, are stored.
The document root contains a subdirectory named WEB-INF
, which can contain the following files and directories:
-
classes
, a directory that contains server-side classes: servlets, enterprise bean class files, utility classes, and JavaBeans components -
lib
, a directory that contains JAR files that contain enterprise beans, and JAR archives of libraries called by server-side classes -
Deployment descriptors, such as
web.xml
(the web application deployment descriptor) andejb-jar.xml
(an enterprise bean deployment descriptor)
A web module needs a web.xml
file if it uses Jakarta Faces technology, if it must specify certain kinds of security information, or if you want to override information specified by web component annotations.
You can also create application-specific subdirectories (that is, package directories) in either the document root or the WEB-INF/classes/
directory.
A web module can be deployed as an unpacked file structure or can be packaged in a JAR file known as a Web Archive (WAR) file.
Because the contents and use of WAR files differ from those of JAR files, WAR file names use a .war
extension.
The web module just described is portable; you can deploy it into any web container that conforms to the Jakarta Servlet specification.
You can provide a runtime deployment descriptor (DD) when you deploy a WAR on GlassFish Server, but it is not required under most circumstances.
The runtime DD is an XML file that may contain such information as the context root of the web application, the mapping of the portable names of an application’s resources to GlassFish Server resources, and the mapping of an application’s security roles to users, groups, and principals defined in GlassFish Server.
The GlassFish Server web application runtime DD, if used, is named glassfish-web.xml
and is located in the WEB-INF
directory.
The structure of a web module that can be deployed on GlassFish Server is shown in Figure 3, “Web Module Structure”.
Packaging Resource Adapter Archives
A Resource Adapter Archive (RAR) file stores XML files, Java classes, and other objects for Jakarta EE Connector applications. A resource adapter can be deployed on any Jakarta EE server, much like a Jakarta EE application. A RAR file can be contained in an Enterprise Archive (EAR) file, or it can exist as a separate file.
The RAR file contains
-
A JAR file with the implementation classes of the resource adapter
-
An optional
META-INF/
directory that can store anra.xml
file and/or an application server–specific deployment descriptor used for configuration purposes
A RAR file can be deployed on the application server as a standalone component or as part of a larger application. In both cases, the adapter is available to all applications using a lookup procedure.