Glassfish server open source edition là gì
GlassFish Server Open Source Edition 5.0 provides an environment for developing and deploying Java applications and web services. GlassFish Server applications include Java Platform, Enterprise Edition (Java EE platform) standard features as well as features specific to GlassFish Server. This guide explains the tools and processes used for deploying applications and modules in the GlassFish Server environment. Only GlassFish Server features are described in detail in this document. Information and instructions on deploying from the command line are provided in this document. Information and instructions for accomplishing the deployment tasks by using the Administration Console are contained in the Administration Console online help. About Application DeploymentAssembly, also known as packaging, is the process of combining discrete components of an application or module into a single unit that can be installed on an application server. The GlassFish Server assembly process conforms to the customary Java EE specifications. The only difference is that when you assemble applications or modules in GlassFish Server, you can include optional GlassFish Server deployment descriptors that enhance functionality. Deployment is the process of installing an application or module on GlassFish Server, optionally specifying location-specific information, such as a list of local users that can access the application, or the name of the local database. GlassFish Server deployment tools expand the archive file into an open directory structure that is ready for users. GlassFish Server deployment tools are described in About Deployment Tools. The following topics are addressed here:
General Deployment FunctionalityVarious Java EE module types, such as connector module, web module, EJB module, application client module, can be deployed in the following ways:
A deployment plan, which deploys a portable archive along with a deployment plan containing GlassFish Server deployment descriptors, can apply to any of these deployment techniques. For instructions, see To Deploy an Application or Module by Using a Deployment Plan. There are two work situations that require different safeguards and processes:
Some deployment methods that are used effectively in a development environment should not be used in production. In addition, whenever a reload is done, the sessions that are in transit become invalid, which might not be a concern for development, but can be a serious matter in production. The client must restart the session, another negative in a production environment. For production environments, any upgrade should be performed as a rolling upgrade, which upgrades applications and modules without interruption in service. For more information, see Upgrading Applications Without Loss of Availability in GlassFish Server Open Source Edition High Availability Administration Guide. Deployment Descriptors and AnnotationsA deployment descriptor is an XML file that describes how a Java EE application or module should be deployed. Each deployment descriptor XML file has a corresponding Document Type Definition (DTD) file or schema (XSD) file, which defines the elements, data, and attributes that the deployment descriptor file can contain. The deployment descriptor directs a deployment tool to deploy a module or application with specific container options, and also describes specific configuration requirements that you must resolve. Because the information in a deployment descriptor is declarative, it can be changed without requiring modifications to source code. During deployment, GlassFish Server reads the information in the deployment descriptor and deploys the application or module as directed. The following types of deployment descriptors are associated with GlassFish Server:
An annotation, also called metadata, enables a declarative style of programming. You can specify information within a class file by using annotations. When the application or module is deployed, the information can either be used or overridden by the deployment descriptor. GlassFish Server supports annotation according to the following specifications:
The following annotation and deployment descriptor combinations are supported:
Modules and ApplicationsAn application is a logical collection of one or more modules joined by application annotations or deployment descriptors. You assemble components into JAR, WAR, or RAR files, then combine these files and, optionally, deployment descriptors into an Enterprise archive (EAR) file which is deployed. A module is a collection of one or more Java EE components that run in the same container type, such as a web container or EJB container. The module uses annotations or deployment descriptors of that container type. You can deploy a module alone or as part of an application. The following topics are addressed here:
Types of ModulesGlassFish Server supports the following types of modules:
Module-Based DeploymentYou can deploy web, EJB, and application client modules separately, outside of any application. Module-based deployment is appropriate when components need to be accessed by other modules, applications, or application clients. Module-based deployment allows shared access to a bean from a web, EJB, or application client component. The following figure shows separately-deployed EJB, web, and application client modules. Figure 1-1 Module-Based Assembly and Deployment Application-Based DeploymentApplication-based deployment is appropriate when components need to work together as one unit. The following figure shows EJB, web, application client, and connector modules assembled into a Java EE application.
Figure 1-2 Application-Based Assembly and Deployment Access to Shared Framework ClassesIf you assemble a large, shared library into every module that uses it, the result is a huge file that takes too long to register with the server. In addition, several versions of the same class could exist in different class loaders, which is a waste of resources. When Java EE applications and modules use shared framework classes (such as utility classes and libraries), the classes can be put in the path for the common class loader or an application-specific class loader rather than in an application or module. To specify an application-specific library file during deployment, use the For more information about class loaders, see Class Loaders in GlassFish Server Open Source Edition Application Development Guide.
Naming StandardsNames of applications and individually-deployed modules must be unique within a GlassFish Server domain. Modules within an application must have unique names. In addition, for enterprise beans that use container-managed persistence (CMP), the You should use a hierarchical naming scheme for module file names, EAR file names, module names as found in
the The following topics are addressed here:
Portable NamingStarting in Java EE 6, the Java EE specification defines the portable
The Java EE specification also defines the portable GlassFish Server determines the application registration name according to the following order of precedence:
JNDI NamingJava Naming and Directory Interface (JNDI) lookup names for
EJB components must also be unique. Establishing a consistent naming convention can help. For example, appending the application name and the module name to the EJB name is a way to guarantee unique names, such as, Directory StructureApplication and module directory structures must follow the structure outlined in the Java EE specification. During deployment, the application or module is expanded from the archive file to an open
directory structure. The directories that hold the individual modules are named with JSR 88 NamingThere are two JSR 88 APIs that can be used to deploy applications in GlassFish Server. If you are using the following JSR 88 API, there is no file name:
Because there is no file name, the name of the application is taken from the If you are using the following preferred JSR 88 API, the name is derived from the
For more information
about JSR 88, see Module and Application VersionsApplication and module versioning allows multiple versions of the same application to exist in a GlassFish Server domain, which simplifies upgrade and rollback tasks. At most one version of an application or module can be enabled on a server any given time. Versioning provides extensions to tools for deploying, viewing, and managing multiple versions of modules and
applications, including the Administration Console and deployment-related The following topics are addressed here:
Version Identifiers and ExpressionsThe version identifier is a suffix to the module or application name. It is
separated from the name by a colon (
A module or application without a version identifier is called the untagged version. This version can coexist with other versions of the same module or application that have version identifiers. In some deployment-related
The following table summarizes which
The The Choosing the Enabled VersionAt most one version of a module or application can be enabled on a server instance. All other versions are disabled. Enabling one version automatically disables all others. You can disable all versions of a module or application, leaving none enabled. The To enable a version that has been deployed previously, use the Versioning Restrictions and LimitationsModule and application versioning in GlassFish Server is subject to the following restrictions and limitations:
About Assembly and Deployment EventsThe deployment tools that are provided by GlassFish Server can be used by any user authorized as an administrator to deploy applications and modules into any GlassFish Server environment. However, effective application deployment requires planning and care. Only the developer knows exactly what is required by an application, so the developer is responsible for initial assembly and deployment.
About Deployment ToolsGlassFish Server provides tools for assembling and deploying a module or application. The following topics are addressed here:
Administration ConsoleThe GlassFish Server Administration Console is a browser-based utility that features a graphical interface that includes extensive online help for the administrative tasks. The format for starting the Administration Console in a web browser is Step-by-step instructions for using the Administration Console for deployment are provided in the Administration Console online help. You can display the help material for a page by clicking the Help button. The initial help page describes the functions and fields of the page itself. To find instructions for performing associated tasks, click a link in the See Also list. The |