Table of Contents
This chapter describes how to manage and deploy applications in a domain environment. It also explains how to deploy applications on a managed server (hereafter MS).
Domain Administration Server (hereafter DAS) is a server that manages domains. Because applications should be managed by a domain, DAS manages all applications in the domain.
All commands related to applications, such as commands to deploy and search for applications, can only be executed through DAS. When DAS starts, a service that manages applications starts. Through this service, an application can be deployed to a server or cluster. If an error occurs in DAS, and MS goes into the INDEPENDENT state, the deploy command is disabled. However, you can use the console tool (jeusadmin) command to connect to the MS and display the application information.
Caution
Displaying the application information by directly connecting to a MS is only possible when the MS is in the INDEPENDENT state. When the MS cannot access DAS, or DAS is not able to manage the MS, the MS goes into the INDEPENDENT state. In such a case, you should access the MS directly to check the application status.
To deploy an application, the application should be installed on a domain. Installing an application requires installing application files on DAS, and deploying an application makes the application available for use.
-
Application files are uploaded to DAS. Only applications, which are installed on DAS, can be deployed.
Installing an application on DAS results in the following:
-
Application files are placed in a storage, indicated by the domain's APPLICATION_INSTALL_HOME directory, using the WebAdmin or console tool (jeusadmin).
APPLICATION_INSTALL_HOME is the storage location for managing applications installed on a domain. This storage cannot be changed and should not be accessed manually. Deleting an installed application or manually adding a new application cannot be dynamically applied to this storage. The changes are applied when DAS restarts, but this is strongly not recommended.
-
An application is manually placed in a directory specified by a user.
A directory specified by a user is a directory where all applications reside. The user can add this directory to an application repository, and manually move application files to the repository. An application repository can be added or deleted using the commands add-application-repository and remove-application-repository through the WebAdmin or console tool (jeusadmin).
-
-
To start an application, the application must be distributed to the servers, and preparation tasks must be executed.
When a user sends the command to deploy an application to DAS using the WebAdmin or jeusadmin, DAS deploys the application to target servers or clusters using the two-phase deployment protocol. For details about two-phase deployment, see "1.1.1. Two-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.
The jobs are performed in two steps on DAS. All deployment-related commands are executed on DAS, and DAS sends the commands to each target server. When a user requests to deploy an application, the request is said to be successfully processed only when all servers, that received the request, can guarantee a successful deployment. The request is handled in two steps, the distribution step and the start step. If the distribution step fails, the deployment request will fail, and the application will be undeployed from all the servers.
-
If step 1 (distribution step) is successful, deployment is potentially successful, since the application is successfully distributed and verified. However, the application cannot be started yet.
-
If step 2 (start step) is successful, the application is ready to start. When there is a server that failed, this step is retried on that server to guarantee that the application can run on it.
These two steps can be executed using two commands, to distribute and to start an application, or using a single command, to deploy an application.
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.
[Example 1.1] A Client Exception for When an EJB Module in DISTRIBUTED State Receives a Request
[2012.05.07 15:28:35][1] [t-1] [JNDI.Context-0073] exception occurred during JNDI operation <<__Exception__>> javax.naming.NamingException: javax.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 on one or more target servers or clusters, the user's deployment request will fail. In such case, the undeployment 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 shut down 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 shut down 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, are started in this step, called the application start step in JEUS, and the application becomes available for service.
Different from the distribution step, when one or more servers of the target servers or clusters is successful in the start step, the step is marked as 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, this indicates that a server is in a failed state for the moment. After the server's status becomes normal, the start step has potential to succeed and become available for service. If a server fails during this step, DAS retries this step on the failed server 10 times, every 5 seconds, using different threads.
If all the tries 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.
In JEUS 7, an ID is assigned to each application to allow a domain to identify and manage the application. An application ID must be unique on a domain, because it is used to identify an application in a domain. It is recommended to use alphanumeric characters for the application IDs.
An application is assigned an ID when it is installed. If an ID is not assigned to an application during installation, an ID will be created using the name of the application file. For example, if examples.ear is not assigned an ID during installation, its ID will be examples_ear.
An application ID is used to issue control and search commands, such as deploy and undeploy. If an application file is located in a repository separate from a domain, its name is used as its ID.
When DAS receives an application file, it creates a directory in the application's INSTALL_HOME directory, which is in a domain directory with the application's ID. 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 Section 1.1.4, “Domain's INSTALL_HOME Directory”.
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.
Caution
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 "Java EE 6 Platform Specification".
Because a domain controls commands of 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
Status of applications in DAS is changed as follows:
INSTALLED → DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING
Descriptions for each statuses are as follows:
Note
Apart from these 3 statuses, an application can be in the DEPLOYED state on a domain.
If all the target deployment servers of an application are not in the RUNNING state, the status of the application is DEPLOYED. This means that the application is not running on any server.
Status of Applications in a Server
Status of applications on a server is changed as follows:
DISTRIBUTING → DISTRIBUTED → STARTING → RUNNING
Descriptions for each statuses are as follows:
| Status | Description |
|---|---|
| DISTRIBUTED | The distribute command from DAS has been successfully executed. The application is ready to run by using the start command. |
| RUNNING | An application is running on the corresponding server. |
The directory structure used to deploy an application is as follows:
Domain's INSTALL_HOME Directory
When an application is installed on a domain, it is placed in the APPLICATION_INSTALL_HOME directory.
- 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 DAS 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.
An Application Repository Managed by a Domain
The following shows an application repository that is added to a domain.
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 "1.5.1. Adding, Deleting, and Searching Application Repositories".
Image Directory of an Application Deployed on a Server
A server receives an application from DAS 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'.
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 is 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 that has information about the time when the applications are deployed. When a server is shut down and restarted, if the application has not been changed, for faster booting, this file prevents recreation of deployment image files and already generated files.
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
Because a server is the minimum unit which services 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 JEUS Server Guide. "3.1.1. Life Cycle of Managed Servers".
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, DAS 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.
Caution
If a user manually modifies a configuration file, the status of an application may not be maintained.
In JEUS 7, it is recommended to use the WebAdmin or console tool, and not to manually modify 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 server within the cluster. If an application fails to be distributed on even one of the servers 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.
Note
A cluster represents a single group that performs a service, not just a list of 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 should be deployed on the servers which are not alive, when the servers become live, restarted, restored, or dynamically added to the cluster. DAS guarantees that an application is successfully deployed on the members of a cluster which failed the boot-time deployment with retries.
If a server failed or is not in the RUNNING state during deployment, the applications on the server must be deployed after the server is failbacked or restarted. It is the role of DAS to guarantee successful deployment when a server boot-time deployment fails.
DAS, at most, guarantees that an application is successfully deployed on the members of a cluster which failed the boot-time deployment with retries. It retries up to five times, in five minutes intervals. If all the trials fail, DAS will notify that the deployment can no longer be guaranteed, since the failure cannot be recovered in JEUS. The user needs to find the reason and resolve the problem. This guarantee applies not only to servers that were not in the RUNNING state during the deploy process, but also to servers that were dynamically included to the cluster.
If all retries of DAS when deployment fails, the following message will be displayed:
[Example 1.2] A Log Message Displayed When All Retries for Deployment Fail
Deployment reattempts of the application[examples] failed 5 times. No more deployment attempts will be made. solve the problem for deploying application.
An application cannot be deployed on a 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:
[Example 1.3] A Log Message Displayed When a Target is a Server Included in a Cluster
WARNING: The server[server1] is part of the cluster[cluster1], so this application[exampes] can only be deployed to the cluster. Deploy again this application to the cluster target.
The previous problem occurs when a user manually modifies the domain.xml file, which is prohibited. JEUS does not provide support for resolving errors caused by this action.
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 detailed information about a virtual host, refer to JEUS Web Engine Guide. "Chapter 5. Virtual Hosts". For detailed information about the deploy command, see "4.3. Controlling and Monitoring Applications with WebAdmin" and "4.4. Controlling and Monitoring Applications Using the Console Tool".
This section describes how to deploy an application or a module on a managed server (MS).
Runtime deployment is deploying an application or a module on a running server. It can be executed by accessing DAS using the WebAdmin or console tool.
In JEUS 7, 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 DAS 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 DAS, only DAS can write information about the applications in domain.xml. MS receives application settings from DAS 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 "4.3. Controlling and Monitoring Applications with WebAdmin" and "4.4. Controlling and Monitoring Applications Using the Console Tool".
Boot-time deployment is deploying an application registered in domain.xml when MS boots. Because permanent deployment is the default setting for JEUS 7, 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 DAS. 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.
Note
If a server included in a cluster is a target of an application, boot-time deployment will not be executed for the application. An application can be deployed on a server included in a cluster only as a unit of the cluster. This is guaranteed when deployment is executed with a JEUS tool, but not for when the file, domain.xml, is manually modified.Therefore, you should avoid manually modifying this file.
The execution of the distribution step is similar for when a server boots or when a server is running. First, the server receives application files from DAS. If the application files already exist on the server, these files and the application files installed on DAS 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. At this time, the start-server command is executed, and the failed applications are retried to be distributed. If all applications are distributed, the start step can be executed. If one or more applications fail to be distributed again, the server will remain in the STANDBY state.
To force a server into the RUNNING state, even if one or more applications fail to be distributed to the server, run the following command:
[DAS]domain1.adminServer>start-server -force server1
If the previous start-server command is executed with the -force option, the status of the server becomes RUNNING, and only distributed applications are started in the server.
When the applications are successfully distributed during boot-time deployment, MS checks with DAS to see if the application can be started. If the applications are in the DEPLOYED or RUNNING states in DAS, 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 DAS, run the start-server command with the -force option to force the server into the RUNNING state.
Note
If an application is in the DISTRIBUTED state in DAS, only the distribution step for the application can be executed on the server. To maintain the status of the application when DAS restarts, DAS 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 DAS again. Even if the server is in the SUSPENDED state, the server can get the start and stop commands from DAS. The server remembers the commands and is able to maintain the application status when it resumes, even if the application cannot execute the commands.
Note
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. DAS 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 DAS. Because the server cannot access DAS, it cannot receive application files from DAS. 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 DAS, because the server and DAS 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 one of the three situations are not possible, an application cannot be deployed. At this time, a server goes into the STANDBY state and stops booting.
To force the server into the RUNNING state, connect to the server using the console tool and run the local-start-server command.
Note
Because deployment will probably fail, even if the local-start-server command is run, start the server with the -force option.
When a server boots in the INDENDENT state, it cannot retrieve a list of applications, which only needs to be distributed, from DAS. Therefore, the server starts all applications which have been successfully distributed.
If a server which boots in the INDEPENDENT state goes into the DEPENDENT state by being connected to DAS, 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 a list of applications, which need to be started from DAS, 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 DAS is restored, the server does not handle these tasks.
One of the major roles of DAS is synchronizing the application files. The application files in DAS and MS need to be synchronized when:
-
Runtime deployment is executed.
MS receives the application files, to be deployed, from DAS.
-
Boot-time deployment is executed.
If the application files to be deployed in MS are modified, MS will receive the application files from DAS.
-
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 DAS. 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 DAS that have been modified are also sent to the MS.
DAS 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 DAS, 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 DAS.
The statuses of all the applications in MS, that are 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 DAS.
If the status of an application is DISTRIBUTED in DAS, the application in MS will be stopped and changed to the DISTRIBUTED state. If MS has an application which is already undeployed in DAS, the application will also be undeployed in MS.
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 does not support automatic deployment. It only supports the redeployment function that redeploys by detecting changes in the applications within the domain.
Note
Because DAS manages applications in a domain environment starting with JEUS 7, the automatic deployment function is not supported. Since a domain cannot be seen as a target for applications, and an exploded module cannot be transferred to a separate machine, automatic deployment is not supported.
However, 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. This way, when changes occur, they can be detected.
Application files, for which automatic redeployment is configured, are checked, if they are changed, at every 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 file.
DAS 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, DAS 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.
An application should be compressed into a file of an appropriate type according to the Java EE specification. However, an application decompressed in a directory can be deployed for the convenience of development. 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 DAS or on a different machine that is in an accessible location like NAS (Network Attached Storage). A module on a different machine is not installed under the INSTALL_HOME directory in DAS through the install-application command. It must be deployed by specifying the parent directory of the application in the 'Application Repository' setting in WebAdmin, or by using the deploy command with the path option. When using the deploy command, the application ID can also be given as an option. Otherwise, the application file name becomes the application ID.
Because DAS manages all applications which are running on a domain, the application files need to be installed on DAS, before the applications are deployed. However, applications can be deployed, without installing the application files for the following situation:
The applications installed on DAS are gathered and managed in a directory. The applications cannot be manually located in this directory.
Multiple directories can be set as repositories. All set directories are regarded as application repositories. To add, delete, and search application repositories, use the WebAdmin or console tool.
Java EE applications, both archive modules and exploded modules, can be placed in a directory, that is configured as an application repository of 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 with 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, by automatically detecting changes in the files, the application can be automatically redeployed.
If a filename in an application repository, to be added, is the same as an application ID, that is already in use in the domain, the application cannot be recognized in the domain. In this case, the following log message will appear:
[2012.05.15 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 DAS 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 will appear:
[2012.05.15 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 will appear:
[2012.05.15 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.
Caution
JEUS cannot determine whether to delete the running applications from a domain when deleting an application repository. To delete a running application, undeploy it, and then delete the repository.
Using WebAdmin
The following is the process of adding an application repository using WebAdmin:
-
To view the Domain configuration screen, select [Domain] from the left menu in WebAdmin. Click the [Lock & Edit] button on the bottom left.
-
To add an application repository, enter a directory name in 'Application Repositories' on the Domain screen, and then click [OK]. The changes will be saved, and the result will be displayed on the top.
When you click [Input] next to 'Application Repositories', a navigation pop-up appears, where you can select the repository path.
-
To apply the newly added application repository to a domain, click the [Apply Changes] button on the bottom left.
In the Apply Changes pop-up page, you can enter the description for the configuration that you are trying to modify. Enter the description in 'Description' and click [OK].
-
If the newly added application repository is configured on a domain, the application repository will be added to the domain, and the result will appear on the top.
-
To view the Deployed Application screen, select [Applications] from the left menu in WebAdmin. This screen shows that the applications, in the newly added application repository, are registered with the domain and are in the INSTALLED state.
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 DAS 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 application repositories using the console tool:
[DAS]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" [DAS]domain1.adminServer>list-application-repositories Application Repositories ================================================================================ +------------------------------------------------------------------------------+ | Path to Application Repository | +------------------------------------------------------------------------------+ | /apps/test | +------------------------------------------------------------------------------+ ================================================================================ [DAS]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" [DAS]domain1.adminServer>list-application-repositories Application Repositories ================================================================================ +------------------------------------------------------------------------------+ | Path to Application Repository | +------------------------------------------------------------------------------+ (No data available) ================================================================================
Note
For more detailed information about how to add, delete, and search application repositories using the console tool, refer to JEUS Reference Book. "4.2.6.1. add-application-repository", JEUS Reference Book. "4.2.6.11. remove-application-repository", and JEUS Reference Book. "4.2.6.9. list-application-repositories".
After an application repository is added, the applications in the application repository can be deployed using the WebAdmin or console tool. For detailed information, see Section 4.4.2, “Deploying Applications which Exist in an Application Repository”.
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 DAS 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 about how to deploy applications using the -path option through the WebAdmin or console tool, refer to Section 4.4.2, “Deploying Application by Specifying the Path”.
Exploded modules can only be deployed to MSs, which reside on the same machine as DAS. 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 DAS.
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 deployment using the -staging option through the WebAdmin or console tool, refer to "4.5. Deploying In Staging Mode".
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 | |
|---|---|---|
| Criteria for File Deletion | The files that have been 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 that have been created internally on the server will not be deleted. |
| Applied Timeout | Graceful Undeploy Timeout | Graceful Shutdown Timeout (Undeploy Timeout is not applied.) |