Application Management in a Domain Environment
This chapter describes how to manage and deploy applications in a domain environment. It also explains how to deploy applications on a managed server (MS).
1. Application Management
The Master Server is a server that manages domains. Since applications need to be managed at the domain-level, the Master Server manages all applications existing in the domain.
Executing deploy and search for applications can only be performed from the Master Server. When the Master Server starts up, a service that manages applications starts. Through this service, applications can be deployed to servers or clusters. Not only deploy, but also any other application-related commands can be executed only from the Master Server. If a MS goes into the INDEPENDENT state due to an error in the Master Server, the deploy command cannot be executed. But you can use the console tool (jeusadmin) to connect to the MS and get the application information.
|
Viewing the application information by directly connecting to a MS is only possible when the MS is in the INDEPENDENT state. If a MS is in the INDEPENDENT state, it cannot access to the Master Server or the latter cannot manage the MS. In this case therefore, you need to view the application information by connecting directly to the MS. |
To deploy and run an application, the application must be installed on a domain. Installing an application means installing application files on the Master Server, and deploying an application means making the application available for use.
-
install
Application files are uploaded to the Master Server. Only the applications installed on the Master Server can be deployed.
Installing an application involves the following:
-
Uploading the application file to APPLICATION_INSTALL_HOME in the domain by using a JEUS-provided tool. APPLICATION_INSTALL_HOME is the repository of applications installed in the domain. This repository cannot be modified nor accessed manually. Any attempts to dynamically delete an installed application or add a new application to the repository will not succeed. Such changes to the repository can only be applied after the Master Server is restarted, but this is strongly discouraged.
-
Placing an application manually in a user-specified directory. The user can add this directory as an application repository to manually upload application files. You can add or delete an application repository in the domain by using the console tool commands add-application-repository and remove-application-repository.
-
-
deploy
Applications are deployed to a server and ready to run.
When the user sends the command to deploy an application to the Master Server, the Master Server deploys the application to target servers or clusters using the two-phase deployment protocol. For more information about the two-phase deployment, refer to 2 Phase Deployment.
1.1. 2 Phase Deployment
Application files are distributed to each target server, and preparation tasks are performed. After the jobs are completed successfully, the application is ready to start. These jobs are performed in two steps on the Master Server. All deployment-related commands are executed on the Master Server, and the Master Server sends the commands to each target server. When a user sends a deploy request, the deploy command is considered successful only when all target servers have successfully completed the deployment.
The request is handled in two steps, Distribute and Start. If the first step (distribution) fails, the deployment request will fail, and the application will be undeployed from all the servers.
-
If the first step is successful, deployment is potentially successful, since the application is successfully distributed and verified. However, the application cannot be started yet.
-
If the second step is successful, the application is ready to start. When there is a failed server, this step is retried on that server to guarantee that the application can run on it.
You can execute these two steps individually using the 'distribute' and 'start' commands, instead of using a single 'deploy' command.
Step 1 (Distribution Step)
In the application distribution step in JEUS, an application is distributed to target servers or clusters, and then verified. In this step, application files are distributed to each server, and preparation and verification tasks are executed.
When all jobs are completed successfully, an application is ready to run. If the application is an EJB module, a service port is opened, and if it is a web module, its context gets connected to the web listener’s context. However, the application is in the DISTRIBUTED state, where the application cannot be started.
If an application in the DISTRIBUTED state receives a request to run, an exception or an error will occur. If the application is an EJB module, the exception stating that the Bean does not exist will occur, and if the application is a web module, the "503 Service Unavailable" error will occur.
[2016.08.10 15:28:35][1] [t-1] [JNDI.Context-0073] exception occurred during JNDI operation <<__Exception__>> javax.naming.NamingException: jakarta.ejb.EJBException: java.rmi.RemoteException: EJB object is not read at jeus.ejb.client.BusinessObjectFactory.getObjectInstance(BusinessObjectFactory.java:89) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at jeus.jndi.JNSContext.lookupInternal(JNSContext.java:594) at jeus.jndi.JNSContext.lookup(JNSContext.java:549) at jeus.jndi.JNSContext.lookup(JNSContext.java:538) at jeus.jndi.JEUSFailoverContext.lookup(JEUSFailoverContext.java:314) at javax.naming.InitialContext.lookup(InitialContext.java:392) at test.HelloTest.testHelloBean(HelloTest.java:29) ...... Caused by: java.rmi.RemoteException: EJB object is not ready at jeus.ejb.container.RemoteInvocationManagerImpl.beforeInvoke(RemoteInvocationManagerImpl.java:72 at jeus.ejb.baseimpl.RemoteInvokerServer.preInvoke(RemoteInvokerServer.java:118) at jeus.ejb.baseimpl.RemoteInvokerServer.invoke(RemoteInvokerServer.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662)
When an application is successfully distributed to all target servers or clusters, this step is completed successfully. If the distribution job fails even on a single server, the user’s deploy command will fail. In such a case, the undeploy command will be sent to all successful servers, and all jobs in this step will be rolled back. If some of target servers are in a failed or shutdown state, this step will also fail. At this time, the user needs to run the deployment command again on all other successful target servers.
When the distribution target is a cluster, even if some of the servers in the cluster is in a failed or shutdown state, the distribution step can be successful. If all other servers, besides the failed servers, are successful, this step is also considered successful.
Step 2 (Start Step)
An application, which is already distributed on the target servers or clusters, is started in this step, which is referred as the application start step in JEUS. In this step, the application becomes available for service.
Unlike the distribution step, the start step is considered successful when even just a single server out of all target servers, or in an entire cluster, is successful. This is because, with the successful completion of the distribution step, the application is already verified and ready to run.
If the start step fails, it indicates that a server is in a failed state temporarily. Once the server’s status returns to normal, the start step has the potential to succeed and become available for service. In the event of a server failure during this step, the Master Server retries the operation on the failed server up to 10 times, with a 5-second interval between attempts, using different threads.
If all retries fail, the server must be manually restored, because the server will remain in the failed state. If this step is retried for an application after the server is restored, it will execute successfully on the server.
1.2. Application ID
From JEUS 7 onwards, an ID is assigned to each application to allow a domain to identify and manage the application. An application ID must be unique within a domain, because it is used to identify the application in the domain. It is recommended to use alphanumeric characters for application IDs.
You can specify the ID when installing an application. If no ID is specified during installation, the name of the application file will be used to create an ID. For example, if you did not specify the ID for an application file named 'examples.ear' during the installation, 'examples_ear' will become the application ID.
The ID of an application is needed when executing commands to deploy/undeploy or find the application. If the application is located within a separate repository in the domain, the application file name is used as the ID.
When the Master Server receives an application file, it creates a directory using the application’s ID in the application’s INSTALL_HOME directory, which is located under the domain directory. It then locates the file in the created directory.
When an application is installed, it is placed in the following directory. For detailed information about the INSTALL_HOME directory, see INSTALL_HOME Directory in Domain.
INSTALL_HOME/<APPLICATION_ID>/<APPLICATION_FILE>
When a server receives or decompresses an application file, it locates the file in the APPLICATION_ID directory, under the DEPLOYED subdirectory.
|
From Java EE 6, an application name can be defined in the standard DD. A name is required to start an application. Note that the name is different from the application ID. An application name must be unique on a server, where the application is running, but an application ID must be unique within a domain. If an application name is not specified, the application’s file name without the extension becomes the application name. For more information about how to set an application name, refer to "Jakarta EE 9 Platform Specification". |
1.3. Application Status
Because a domain controls commands over applications, the application status shows the statuses of all the target servers. Each server shows statuses of applications, which are running on it.
Status of Applications in a Domain
The following illustrates the life cycle of an application in a domain. In other words, it is the status progress of an application in the Master Server.
INSTALLED → DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING
The following describes each status.
| Status | Description |
|---|---|
INSTALLED |
The application file is uploaded to a domain. In this status, a command to deploy or distribute the application can be run by specifying the targets. |
DISTRIBUTED |
The application is successfully distributed. At this point, even if all the target servers shut down, the application’s status is displayed as DISTRIBUTED. |
RUNNING |
The application is running. If the application is running on even just a single server out of all target servers, the application’s status is RUNNING. |
|
In a domain, another status titled DEPLOYED exists other than those three states described above. If all the target deployment servers of an application are not in the RUNNING state, the status of the application is displayed as DEPLOYED. This means that the application is not running on any server. |
Status of Applications in a Server
The following illustrates the life cycle of an application in a server. In other words, it is the status progress of an application within a server.
DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING
The following describes each status.
| Status | Description |
|---|---|
DISTRIBUTED |
The distribute command from the Master Server is executed successfully. The application is ready to run, and can now be started with the start command. |
RUNNING |
The application is running on the server. |
1.4. Directory Structure to Manage Applications
The directory structure used to deploy an application is as follows:
INSTALL_HOME Directory in Domain
When an application is installed on a domain, it is placed in the APPLICATION_INSTALL_HOME directory.
APPLICATION_INSTALL_HOME
|--application_id
|--[J]application file(.jar, .war, .ear, .rar)
* Legend
- [01]: binary or executable file
- [X] : XML document
- [J] : JAR file
- [T] : Text file
- [C] : Class file
- [V] : java source file
- [DD] : deployment descriptor
- APPLICATION_INSTALL_HOME
-
This directory refers to the DOMAIN_HOME/.applications directory and is called INSTALL_HOME, in short. It is only created on a machine where the Master Server resides. A directory is created under this directory using the application ID, assigned when the application was installed, as its name. Actual application files are placed in the newly created directory.
Application Repository Managed by a Domain
The following shows an application repository that is added to a domain.
application repository |--application file (exploded module) |--[J]application file(.jar, .war, .ear, .rar) * Legend - [01]: binary or executable file - [X] : XML document - [J] : JAR file - [T] : Text file - [C] : Class file - [V] : java source file - [DD] : deployment descriptor
An application repository includes both applications in the form of a directory and an archive. When applications are included in an application repository by a user, an application ID cannot be specified by the user, and is always created using the file name. For information about how to add and delete an application repository, see Adding, Deleting, and Searching Application Repositories.
Image Directory of an Application Deployed on a Server
A server receives an application from the Master Server and places it in the following path to deploy it.
SERVER_HOME/.workspace/deployed
The path is called DEPLOYED_HOME. A directory is created under the DEPLOYED_HOME directory using the application ID as its name. Received application files are placed in the new directory.
When deployed, an archived application is decompressed in a directory called the application’s deployment image directory. The directory is named with the application file’s name. For example, the name of the image directory where myApp.ear is decompressed is 'myApp_ear___'.
If the extension of an application file is ear, the file’s modules also need to be decompressed under the ear image directory. The directory where the modules are decompressed is named in the same way as an image directory. For example, the name of the directory where ejb.jar is decompressed is 'ejb_jar'.
The following illustrates the image directory structure of an ear application deployed on a server.
DEPLOYED_HOME
|--_generated_
|--myApp
|--myApp_ear__
|--appclient_jar__
|--ejb_jar__
|--lib
|--META-INF
|--web_war__
|--[J]appclient.jar
|--[J]ejb.jar
|--[J]web.war
* Legend
- [01]: binary or executable file
- [X] : XML document
- [J] : JAR file
- [T] : Text file
- [C] : Class file
- [V] : java source file
- [DD] : deployment descriptor
gen Directory of an Application
In some cases, when an application is deployed on a server, the necessary files for the application are created.
For EJB or web applications, those files need to be created in a directory under the '_generated_' directory, in the DEPLOYED_HOME directory. The directory is created using an application ID, so that each application has its own directory. The directory is called an application’s gen directory.
The following files are created in the gen directory of each application.
-
For EJB applications, stub and skel files are created when EJB 2.x type Bean is used with the stub method, and not with the dynamic proxy method.
-
For web applications, Java source is generated for JSP, and stub files for embeddable EJB. An EJB module embedded in a web application is called an embeddable EJB in Java EE6.
-
The file '_appdat.ser' is created. It is a serializable file containing the information about the time when the applications are deployed. When a server is shut down and restarted, if the application has not been changed, this file prevents recreation of deployment image files and already generated files for faster booting.
The following illustrates the gen directory structure for an ear application deployed on a server.
DEPLOYED_HOME
|--_generated_
|--myApp
|--ejb_jar
| |--classes
|--web_war
|--__embedded_ejb
| |--classes
|--__jspwork
|--__ws
|--_appdat.ser
* Legend
- [01]: binary or executable file
- [X] : XML document
- [J] : JAR file
- [T] : Text file
- [C] : Class file
- [V] : java source file
- [DD] : deployment descriptor
1.5. Application Deployment Targets
To deploy an application, specify the target servers where the application will run on. The targets can be one or more servers and/or clusters. You can also add a virtual host to deploy and start the web module on a specific host.
Server
Since a server is the minimum unit for running an application, it can be a target where the application is deployed on. When the deploy command is sent to multiple servers, if the deployment fails on one or more servers or one or more servers are shut down, the distribution step will fail. If the distribution step fails, take an appropriate action for the servers and run the deploy command again, or exclude the failed servers and run the deploy command again.
When a server is in the STANDBY or SUSPENDED state, it can’t start an application, because this means that the server is not running normally.
When a server is in the RUNNING state after the server has restarted or resumed, it can start an application. For detailed information about server statuses, see Lifecycle of Managed Server in JEUS Server Guide.
If a user runs only the distribute command, not the deploy command, an application will not start. Even after the server restarts, the status needs to be maintained. Therefore, the Master Server records the status of the application, in the '.deployInfo.ser' file under the INSTALL_HOME directory. When the server restarts, a status notification is sent to the user in order to continue processing the previously started jobs.
|
If a user manually modifies a configuration file, the status of an application may not be maintained. Therefore, it is recommended to use JEUS-provided management tools (e.g. jeusadmin) when modifying a configuration file. |
Cluster
If an application’s target is a cluster, the application can only be deployed on the cluster, and not on a particular server within the cluster. If an application fails to be distributed on even a single server in a cluster, the application will fail to be deployed on the cluster. However, unlike using a list of servers as a target for deployment, an application can be successfully deployed on the cluster even if some servers in a cluster are not alive. If the application is successfully deployed on all live servers in the cluster, it is successfully deployed on the cluster.
|
A cluster represents a group to operate a service, not merely a list of individual servers. If an application is successfully deployed on all live servers in a cluster, there is high probability that the application can be successfully deployed on servers which are not alive. The application must be deployed on the servers which are not alive, when the servers become live, restarted, restored, or dynamically added to the cluster. |
An application cannot be deployed on a specific server that is included in a cluster. If attempted, the following warning message will be displayed for the user to run the undeploy or the remove-application-target command:
WARNING: The server[server1] is part of the cluster[cluster1], so this application[examples] can only be deployed to the cluster. Deploy again this application to the cluster target.
Since it is not possible to execute the deploy command while targeting an individual server within a cluster, the previous warning will not occur when using the deploy command. It will occur when the user manually modifies the configuration file.
If an independently running server is dynamically added to a cluster, applications currently running on the server will be undeployed, and the server will be removed from the target list. Also, applications which need to be deployed on the cluster will be dynamically deployed, since the user probably intends to use the applications in the cluster.
However, it is not recommended to dynamically add an existing server to a cluster, even if it is intended by the user. This may cause a problem for services already running on the server. Therefore, to expand a cluster, add the new server, and then add the server as a member of the cluster.
Virtual Host
Web engine allows a web context to run on a specific host registered as a virtual host. A virtual host cannot be used alone, but can be used along with server or cluster targets. If there is no virtual host, an application is deployed on the default virtual host.
For more information about virtual hosts, see Virtual Hosts in JEUS Web Engine Guide. For more information about the deploy command, see Deploying Applications.
2. Deployment to Managed Servers
This section describes how to deploy an application or a module on a managed server (MS).
2.1. Run-time Deploy
Run-time deployment is deploying an application or a module on a running server. It can be executed by accessing the Master Server using JEUS-provided tools.
In JEUS 7 or later versions, runtime deployment indicates permanent deployment. Permanent deployment means that if an application is successfully distributed with the deploy or distribute command, the details are recorded in the domain.xml file to save the application information. When the Master Server or MS reboots, it reads information about the application, and the application is deployed via boot-time deployment. The domain.xml is the configuration file for JEUS domains.
Because deployment can be executed only by using the Master Server, only the Master Server can write information about the applications in domain.xml. MS receives application settings from the Master Server when it boots, downloads application files registered in the settings, and executes boot-time deployment according to the domain.xml file. For information about how to execute runtime deployment, see Deploying Applications.
2.2. Boot-time Deploy
Boot-time deployment is deploying an application registered in domain.xml when MS boots. Because permanent deployment is the default setting for JEUS 7 or later versions, applications, which were deployed once already, are deployed again when MS boots.
Boot-time Deployment in the DEPENDENT State
When MS boots, it receives the file, domain.xml, from the Master Server. If there are applications registered in the file, MS checks to see if the applications need to be deployed on itself. The applications are not deployed individually on the MS. All applications are distributed first, and if the distribution is successful, the start step is executed.
|
If an individual server in a cluster is a target to deploy an application, boot-time deployment will not be executed for the application. An application can be deployed on a server in a cluster only at the entire cluster level. This is guaranteed when deployment is executed with a JEUS tool, but not for when the domain.xml file is manually modified. Therefore, it is recommended to use JEUS tools for deployment. |
The execution of the distribution step during boot-time is similar as during run-time. First, the server receives application files from the Master Server. If the application files already exist on the server, these files and the application files installed on the Master Server are compared to see if the application files need to be sent to the server. Then, the server decompresses the application files, loads the relevant classes, and executes the distribution step to configure the environment for the applications to run in.
If one or more applications fail to be distributed when a server boots, the server goes into the STANDBY state and stops the booting process.
When the applications are successfully distributed during boot-time deployment, MS checks with the Master Server to see if the application can be started.
If the applications are in the DEPLOYED or RUNNING states in the Master Server, they are ready to start. If MS fails to get the status of the application, it does not execute the start step. At this point, the MS stops booting and goes into the STANDBY state.
To start an application, regardless of the status of the application in the Master Server, run the start-server command with the -force option to force the server into the RUNNING state.
|
If an application is in the DISTRIBUTED state in the Master Server, only the distribution step for the application can be executed on the server. To maintain the status of the application when the Master Server restarts, the Master Server records the status in a separate file. |
If an application stops and starts when a server is in the SUSPENDED state, the application’s status needs to be maintained for when the server resumes again and goes into the RUNNING state. At this point, the server does not retrieve the status information from the Master Server again. Even if the server is in the SUSPENDED state, the server can get the start and stop commands from the Master Server. The server remembers the commands and is able to maintain the application status when it resumes, even if the application cannot execute the commands.
|
If a server which is in the SUSPENDED state receives the stop command for an application, ApplicationAlreadyStoppedException occurs, because all the applications in the server have already stopped running. the Master Server does not treat this exception as a failure of stopping an application. If a server which is in the SUSPENDED state receives the start command for an application, it cannot execute the command. If the application is in the DISTRIBUTED state when the server goes into the SUSPENDED state, it needs to restart when the server resumes. |
Boot-time Deployment in the INDEPENDENT State
When a server boots in the INDEPENDENT state, it is not managed by the Master Server. Because the server cannot access the Master Server, it cannot receive application files from the Master Server. Therefore, if the previously received application files do not exist on the server or are damaged, boot-time deployment cannot be executed.
When a server boots in the INDEPENDENT state, deployment can be executed only when the server is able to access application files. A server can access the application files in the following cases:
-
The server can access the application files installed on the Master Server, because the server and Master Server exist on the same machine.
-
The server can access the application files, because the files exist on a network-attached server (NAS).
-
There remains a decompressed deployed image of the files.
If none of these conditions are met, the application deployment fails since no files for the application to deploy can be found. At this time, the server goes into the STANDBY state and stops booting.
When a server boots in the INDENDENT state, it cannot retrieve a list of applications, which only needs to be distributed, from the Master Server. Therefore, the server starts all applications which have been successfully distributed.
If a server booting in the INDEPENDENT state goes into the DEPENDENT state by being connected to the Master Server, it tries to redistribute all applications that failed to distribute according to the specified options. If all the applications are successfully distributed, the server will get the list of applications, which need to be started from the Master Server, and starts the applications in the same way as during the boot-time deployment.
If there is a running application that only needs to be distributed, the server stops the application. However, if a server goes into the DEPENDENT state during booting because the Master Server is restored, the server does not handle these tasks.
2.3. Application Synchronization
One of the major roles of the Master Server is synchronizing the application files. The application files in the Master Server and MS need to be synchronized when:
-
Runtime deployment is executed.
MS receives the application files to be deployed from the Master Server.
-
Boot-time deployment is executed.
If the application files to be deployed in MS are modified, MS will receive the updated application files from the Master Server.
-
The status of MS is changed from INDEPENDENT to DEPENDENT.
If the status of MS is changed from INDEPENDENT to DEPENDENT, MS is managed by the Master Server. MS synchronizes the applications only when the 'enable-to-resynchronize-applications' is set to true in the domain configuration. By default, 'enable-to-resynchronize-applications' is set to false, and applications are not synchronized. If the option is set to true, the application files that failed to be deployed are sent to the MS. Any successfully deployed application files managed by the Master Server that have been modified are also sent to the MS.
The Master Server synchronizes not only the application files, but also the statuses of applications in the domain.
When boot-time deployment is executed, if an application is in the DISTRIBUTED status in the Master Server, the application will be in the DISTRIBUTED status in MS. To start this application, the user needs to run the start-application command. If MS goes into the DEPENDENT state from the INDEPENDENT state, application statuses as well as the application files are synchronized in MS. The statuses of applications that have become DEPENDENT in MS are changed according to the statuses of applications managed by the Master Server.
The statuses of all the applications in MS, in the INDEPENDENT state, need to be in the RUNNING state for the applications to run. If the MS goes into the DEPENDENT state, the statuses of the applications in MS will be changed according to those in the Master Server.
If the status of an application is DISTRIBUTED in the Master Server, the application in MS will be stopped and changed to the DISTRIBUTED state. If MS has an application which is already undeployed in the Master Server, the application will also be undeployed in MS.
3. Boot-time Auto Deployment
When booting a server, a specified path is explored to automatically deploy the application files located in that path. Unlike manually deployed applications, automatically deployed applications feature the following characteristics:
-
The application ID is automatically generated from the file name, excluding the file extension. If the ID is already in use by another application, an error occurs during server boot-up.
-
The deployed application information is not stored in domain.xml. Therefore, all behaviors of automatically deployed applications are effective only during runtime.
-
Application files are not centrally managed by the Master Server. Therefore, no synchronization occurs.
-
Automatically deployed applications always target individual servers, not clusters. Consequently, even if a target server belongs to a cluster, the application will still target that specific server. This is because application files are not centrally managed, and, as a result, it is difficult to perform synchronization between different servers in the cluster.
-
Unlike manually deployed applications, automatically deployed applications are considered undeployed when all target servers are shut down, leading to the deletion of their associated information.
You can configure the system properties on the JVM Options of individual servers to specify whether to use the auto-deployment feature and the location of applications.
-
Use jeus.server.enable.auto-deploy to specify whether to use the auto-deployment feature. The default value is true (enable).
-
Use jeus.server.auto-deploy.dir to specify the location of applications to be deployed automatically. The default value is DOMAIN_HOME/auto-deploy.
4. Auto Redeploy
Up to JEUS 6, specified directories or applications have been checked periodically. When there are changes, corresponding applications are automatically deployed. Applications do not need to be manually deployed with this function. This is beneficial for developing and servicing frequently updated applications. JEUS 7 or later versions no longer support the automatic deployment feature provided by JEUS 6 or earlier versions. Instead, it provides a redeployment function that automatically redeploys applications by detecting changes made to the applications in the domain.
|
Since the Master Server centrally manages applications, the automatic deployment function is no longer supported. The entire domain cannot be targeted to deploy applications, and exploded modules cannot be transferred to a separate machine, which is why automatic deployment is no longer provided. Instead, applications can be automatically redeployed, if you can manually set a cycle in place that checks for the application target and automatic redeployment, when the application is deployed for the first time. In this way, changes to application files can be detected for automatic redeployment. |
Application files with automatic redeployment enabled are checked for any changes at the specified interval, using the following methods:
-
For archive modules, changes are detected using the last modified time of the archive file.
-
For exploded modules, changes are detected using the last modified time of the standard deployment descriptor (DD) file.
The Master Server sends the redeploy command to the target servers. Automatic redeployment and general redeployment are executed in the same way. When redeployment is successful on all servers, the Master Server regards the redeployment as a success.
When application files are changed, redeployment may not be executed immediately, because the changes are checked periodically. The default interval for the check is 10 seconds.
5. Deployment for Directory Type Applications
An application must be packaged into a file of an appropriate type according to the Jakarta EE specification. However, a non-packaged application can also be deployed to streamline the development process. In JEUS, this directory type application is called an exploded module.
An exploded module can be deployed on the servers or clusters that reside on the same machine as the Master Server or on a different machine that is in an accessible location like Network Attached Storage (NAS). A module on a different machine is not installed under the INSTALL_HOME directory in the Master Server through the install-application command. It must be deployed by specifying the parent directory of the application as 'Application Repository', or by using the deploy command with the -path option. When deploying an application of this type with the deploy command, the application ID can also be given as an option. Otherwise, the application file name becomes the application ID.
|
JEUS does not perform the synchronization or management of applications that were deployed in directory mode. Those directories must be managed by a user. |
6. Application Repositories
Since the Master Server manages all applications running on a domain, the application files need to be installed on the Master Server before the applications are deployed. However, applications can be deployed without installing the application files when an application repository is added.
6.1. Adding, Deleting, and Searching Application Repositories
The applications installed on the Master Server are gathered and managed in a directory. The applications cannot be manually located in this directory. Multiple directories can be set as repositories, which are regarded as application repositories. To add, delete, and find application repositories, use the JEUS tools.
Jakarta EE applications, both archive modules and exploded modules, can be placed in a directory specified as an application repository in a domain.
The application files cannot be added to or deleted from an application repository, registered in a domain, with the install-application and uninstall-application commands, respectively. If the files are manually added or deleted, this can be automatically detected in the domain. The manually added applications are in the INSTALLED status, and the manually deleted applications are no longer managed by the domain.
Because an application ID is the application filename, the name is specified by using the -id option of the deploy command. To update the application files, manually update the files, which are located in a repository. If a cycle for automatic redeployment is set when an application is deployed, the application can be automatically redeployed by automatically detecting changes in the files.
If a filename in an application repository is the same as an application ID in the domain, the application cannot be recognized in the domain. In this case, the following log message is displayed:
[2016.08.08 12:37:40.625][1] [adminServer-68] [Deploy-0005] WARNING: The application[myApp] already exists on /JEUS_HOME/.applications/myApp.ear. Change the file name of [/home/user1/apps/myApp].
When a duplicated ID is used, if the application information is requested or the Master Server starts, the same log message will be generated.
If a valid application does not exist in an application repository, where you are trying to add to, the following log message is displayed:
[2016.08.08 12:37:40.625][1] [adminServer-68] [Deploy-0062] WARNING: The repository(/home/user1/apps) does not contain any valid applications, but new applications can be added.
If the application files, distributed or deployed on a domain, exist in an application repository to be deleted, the application continues to be managed by the domain, even after the application repository is deleted. In this case, the following log message is displayed:
[2016.08.08 12:44:04.328][1] [adminServer-93] [Deploy-0124] WARNING: The application[myApp] is RUNNING in repository[/home/user1/apps]. To remove this application from the domain, undeploy it.
|
JEUS cannot determine whether to delete running applications from the domain when deleting an application repository. To delete a running application, you need to undeploy it before deleting the repository. |
Using the Console Tool
An application repository can be added to a domain with the add-application-repository command, and can be deleted from the domain with the remove-application-repository command. A subdirectory is created under the directory, where the applications installed on the Master Server reside, with an application ID that is assigned to it during the application installation. The application’s archive files are placed in this new directory.
The following example adds, deletes, and searches for application repositories using the console tool.
[MASTER]domain1.adminServer>add-application-repository /apps/test Successfully performed the ADD operation for An application repository. Check the results using "add-application-repository or list-application-repositories" [MASTER]domain1.adminServer>list-application-repositories Application Repositories ================================================================================ +------------------------------------------------------------------------------+ | Path to Application Repository | +------------------------------------------------------------------------------+ | /apps/test | +------------------------------------------------------------------------------+ ================================================================================ [MASTER]domain1.adminServer>remove-application-repository /apps/test Successfully performed the REMOVE operation for An application repository. Check the results using "remove-application-repository or list-application-repositories" [MASTER]domain1.adminServer>list-application-repositories Application Repositories ================================================================================ +------------------------------------------------------------------------------+ | Path to Application Repository | +------------------------------------------------------------------------------+ (No data available) ================================================================================
|
For detailed information on commands for adding, deleting, and querying application repositories using the console tools, see add-application-repository, remove-application-repository, and list-application-repositories in JEUS Reference Guide. |
6.2. Deploying Applications in an Application Repository
After adding an application repository, you can deploy applications that exist in the repository. For more information, see Deploying Applications in an Application Repository.
7. Application Deployment by Specifying a Path
There are two ways to manage application files on a domain.
To configure the domain to manage the application files, it is recommended to install the applications in the INSTALL_HOME directory. If users want to directly manage the application files, it is recommended to set up application repositories. Even if the application files are directly managed by the user, in a production environment, it is recommended to group the application files by tasks and distribute them to multiple directories in the domain. In the development environment, applications do not need to be placed in the same path, but each in different paths. In such a case, applications in each directory can be deployed using the -path option.
You cannot use the -id option when deploying applications using the -path option. You can deploy both archive and exploded modules. If the -path option is used, applications are registered with the Master Server and then deployed, without being copied to the application’s INSTALL_HOME directory. In such cases, an application ID becomes the name of the application file.
For more information on how to deploy by specifying a path, see Deploying Applications by Specifying the Path.
8. Staging Mode Deploy
Exploded modules can only be deployed to MSes, which reside on the same machine as the Master Server. Since exploded modules are used mostly during the development stage, exploded modules can be deployed and run on a single machine without having to use multiple machines. During the testing stage, however, since you can construct a domain on multiple machines while maintaining application in the exploded module format, there is no need to deploy the exploded module to another machine.
If the -staging option is used to deploy an application, the exploded module can be compressed and sent to a MS on a different machine. The application, that is deployed using the -staging option, is regarded by the MS as an archive module. The MS decompresses the module and deploys it. When the MS is restarted, the application files are synchronized with those on the Master Server.
|
In staging deployment mode, files to synchronize between MS and the Master Server are not the files in the source application directory but the compressed file that the Master Server generates by compressing the directory. Therefore, modifications in files in the directory are not synchronized when MS restarts. |
If there are changes to an application, the updates can be applied to the files on the MS using the redeploy command. Like the existing method for deploying archive modules, the redeploy command can be used without the -staging option. You cannot use the -path option in this case. When MS receives the redeploy command, it synchronizes the application files, undeploys the existing application, and then deploys the new application.
For more information about deploying an application in Staging mode, see Staging Mode Deploy.
9. Application Undeployment
Undeploying applications by explicitly using a JEUS management tool is different from undeploying applications when the server shuts down.
The following shows their differences.
| Undeployment using a management tool command | Undeployment during server shut down | |
|---|---|---|
File Deletion |
The files created internally on the server will be deleted. For example, the results of JSP and EJB compilation, and the EJB 3.0 schedule information will be deleted from the database. |
The files created internally on the server will not be deleted. |
Timeout Mode |
Graceful Undeploy Timeout |
Graceful Shutdown Timeout (Undeploy Timeout is not applied.) |