Introduction

This chapter describes components and services of JEUS.

1. Components

JEUS servers can be centrally managed through the master server by grouping multiple servers in the same domain.

For more information on how to start the server and domains, see JEUS Domain Guide.

The following are featured JEUS components.

figure jeuscomponents
JEUS Components

  • Domain

    Domain is a group that manages servers and clusters. A domain consists of a master server (hereafter Master) and one or more managed servers (hereafter MS). For more information about domains, refer to JEUS Domain Guide.

  • Master Server(MASTER)

    Only one MASTER can exist in a domain. It manages applications and configurations of a domain. It also manages multiple managed servers (MSs) in the domain.

    The following are the main services of MASTER.

    • Dynamic configuration reloading service

    • Domain application management service

    • Domain data source management service

    • Cluster management service

  • Managed Server(MS)

    Multiple MSs can exist in a domain. An MS runs user-deployed applications, and provides services required by the applications.

    The following are the main services of MS.

    • EJB, WEB, and JMS engine service

    • JNDI service

    • Management service

    • Security service

    • HTTP session clustering service

    • Transaction service

    • Database (hereafter DB) or EIS (Enterprise Information System) connection service

    • Scheduler and other services

For more information on domain configuration, see Domain Configuration in JEUS Domain Guide.

1.1. Master Server(Master)

Master server (MASTER) is a server that manages a domain. Only one MASTER can exist in a domain. It manages domain configurations, and manages and controls applications running in the domain. It also manages MSs in the domain.

For a detailed explanation of the Master concept, see Master Server (MASTER) in JEUS Domain Guide.

The following services are the major services that can only be used in MASTER. These services can only be executed on MASTER because they have to be managed at the domain level. The following services can be used through the console tool (jeusadmin) by connecting to MASTER.

  • Dynamic configuration reloading service

    MASTER supports dynamic reloading of domain configurations on all servers in the domain. Domain configurations can only be changed by MASTER.

    The console tool (jeusadmin) can be used to execute dynamic configuration change commands. Some configuration changes can be applied dynamically, while others can only be applied after rebooting the server. This is the role of the dynamic configuration reloading service.

    For more information about the service that governs changes to settings in a domain, see Changing Domain Configuration in JEUS Domain Guide.

  • Domain application management service

    MASTER manages all applications running in a domain by using the domain application management service. To run applications on MSs, the applications must be registered in the domain. Then, in MASTER, execute the deploy command by specifying the targets to deploy. The domain application management service synchronizes the applications' states between MASTER and MSs. If an application file is changed on MASTER, the service allows MSs to retrieve the changed file to sync with MASTER.

    For more information on how to manage applications in a domain, see Managing Applications in the Domain Environment in JEUS Applications & Deployment Guide.

  • Domain data source management service

    In MASTER, the domain data source management service manages all data sources that are registered in a domain. MSs must use the data sources that are registered in the domain. For more information about how to register and manage data sources in the domain, refer to DB Connection Pool and JDBC.

  • Cluster management service

    In MASTER, the cluster management service manages clusters. A cluster is a collection of multiple servers running the same services, and it supports load balancing and failover. For more information about clusters, refer to JEUS Clustering in JEUS Domain Guide.

  • Managed Server (MS) service

    MASTER can provide all services that are provided by MSs. In an environment where only one server is running services like in a small-sized production environment or a development environment, MASTER can also be used to service applications like an MS. For more information about MS services, refer to Managed Server(MS).

    MASTER can be configured to run like an MS, but it is not recommended to do so. Except in an environment where only one server is required like in a small-sized production environment or a development environment, it is common to dedicate MASTER only for management and MSs for application services.

1.2. Managed Server(MS)

A Managed Server is a server instance that manages engines and services that are required to run the actual applications. Multiple MSs can be in a domain. MSs run user-deployed applications, and provide services and resources required by the applications.

The following are the key MS services.

  • Engine service

    MS provides servlet, EJB, and Jakarta™ Messaging (JMS) engines. For information about other engine services, refer to Engine Service.

  • JNDI service

    JNDI service provides the JNDI standard mechanism defined by Jakarta EE. It provides methods that find various objects registered in JEUS by name.

    JEUS server calls the object that provides such service as JNDI naming server. In a clustered environment, JNDI servers on each MS exchange information and work together like a single JNDI naming server. For more information about JNDI services, refer to JNDI Naming Server.

  • Management service

    Management service manages and monitors services, components, and applications by using Java Management Extensions (JMX).

    It configures the management objects of the JEUS Manager, such as JMX Remote API Connector (RMI Connector/JMXMP Connector), HTML adapter, and SNMP adapter that are defined in JMX. The management objects provide the methods for accessing JEUS management and monitoring information. For more information about management service configurations and management objects, refer to JEUS JMX Guide.

  • Security service

    Security service responds to and authenticates security requests from applications and internal components.

    For more information about security services, refer to JEUS Security Guide.

  • HTTP session clustering service

    HTTP session clustering service maintains HTTP sessions between servlet engines.

    JEUS supports distributed HTTP session clustering. The service maintains HTTP sessions even if an error occurs to a servlet engine. Distributed HTTP session clustering is a memory efficient distribution method for server operation. For more information about HTTP session clustering services, refer to Distributed Session Server in JEUS Session Guide.

    The previously described service is automatically provided in a cluster setup. For non-clustered servers, a limited service with certain constraints is provided that maintains sessions on all the servers in a domain. For more information, refer to Domain-Wide Session Cluster Mode in JEUS Session Guide.

  • Class FTP service

    In EJB 2.x, RMI stub classes are required to call an EJB from a remote client. But the required classes can be obtained through the FTP Class service without packaging the RMI stub classes on the remote client.

    If FTP Class service is not used, the RMI stub classes must be in the classpath of the remote client. For more examples, refer to EJB Client in JEUS EJB Guide.

    It is not FTP protocol but the HTTP protocol that actually sends the class files.

    EJB 3.x does not use this service because it uses dynamic proxy. EJB 2.x also uses dynamic proxy by default, but it can be configured to use the RMI stub method.

  • Scheduler service

    The Scheduler executes specific tasks at times pre-determined by the user. For more information about the Scheduler service, see JEUS Scheduler Guide.

  • Logging service

    Logging service records events and errors that occur on the servers to a file. The logger level or the handler that are supported by Java Logging Technology can be configured in JEUS. For more information about logging services, refer to Logging.

  • Database link service

    Servers provide support for applications to access databases using JDBC connection pools. For more information, refer to DB Connection Pool and JDBC.

  • Transaction service

    Servers provide support for applications to use transactions through a transaction manager. For more information about transaction managers, refer to Transaction Manager.

  • External Resources

    Server provides applications with connections to various types of external resources.

    External Resource Description

    Data Source

    Connects to a database. (Data source defined in JDBC standards)

    Mail Source

    Connects to a mail server.

    URL Source

    Connects to a URL source.

    Message Bridge

    Bridge between JMS destinations.

    Custom Resource

    Registers custom JavaBean resources to a JNDI storage.

    External Source

    Connects to an enterprise information system (EIS) such as TP Monitor(Tmax) and IBM MQ. (Separate from the method that deploys the JCA resource adapter.)

    JAXR Source

    XML registry source.

    Users can add the connection information for external resources. The information will be registered on a JNDI naming server and applications can use it for JNDI lookup operation. Although external resources are configured in the domain, this service is classified as a server service since it is used by all servers in the domain.

    In a cluster setup, all servers in a cluster share the same resources by using the JNDI naming server. For more information about resource configurations, refer to External Resources.

  • Enterprise Information System (EIS) connection service

    EIS can be accessed by using the registration information of the JCA resources or external resources where the application is deployed. For more information about the JCA resource adapter, refer to JEUS Jakarta Connectors Guide.

Engine Service

An engine corresponds to an EJB container or a web container that is defined in Jakarta EE, and it manages and runs user-deployed components. An engine is included as a service on the server and even without any configuration it automatically starts up using the default settings when the server starts up.

The engine configurations can be changed using the console tool while the server is running. Refer to the relevant documentation for information about the default and dynamic configurations of each engine.

The following are the three types of service engines provided by each server.

Engine Description

EJB Engine

Acts as an EJB container that manages and executes EJB components. For more information about this, see JEUS EJB Guide.

Web engine

(or servlet engine)

Acts as a web container that receives requests from web clients or web servers and creates dynamic web contents through user-deployed servlets (or JSP, JSF). For more information, refer to JEUS Web Engine Guide.

JMS Engine

Provides Jakarta Messaging (JMS). For more information, refer to JEUS MQ Guide.

Up to JEUS 6, engines could not run if the engine is not configured in the engine container, and this prevented applications from running services. If the web engine was not configured, the engine had to be added and JEUS had to be restarted to run web applications.

But starting from JEUS 7, the engines automatically starts up when MSs start up. This way, any type of applications can be deployed and serviced even if the user does not configure the engine.
INDEPENDENT Mode of Managed Server

In the INDEPENDENT mode, MSs boot up and operate without using MASTER. The INDEPENDENT mode is used when the URL information of MASTER doesn’t exist during startup or when MASTER is in a failed state.

The URL of MASTER must be provided as an option when starting an MS. The launcher uses this URL to access the configuration files on MASTER. If the URL information is omitted, the launcher cannot receive configuration files from MASTER.

If the MASTER URL is not provided and configuration files are cached on the server’s machine, the server will start in INDEPENDENT status using those configuration files. However, if no configuration files are available, the server cannot start.

Even if the configuration files exist on the server machine, the files may be outdated and out of sync with MASTER. Therefore, the MASTER URL should always be used to start a server.

There is only one case where the MASTER URL is not required: when MASTER and MS are on the same machine, so the domain configuration files do not need to be sent to the MS. If the MASTER URL is not provided even though it is not in a failed state, the server will run in the INDEPENDENT mode, but once the group management starts on the MS, it will communicate with MASTER and will be restored to the DEPENDENT mode.

The INDEPENDENT mode is triggered more often due to an error on MASTER rather than due to missing URL. When starting an MS, if an error occurs on MASTER, the launcher cannot receive the configuration files. After failback, the MSs that booted in the INDEPENDENT mode are switched back to the DEPENDENT mode. Their configuration files are synchronized with MASTER, and the applications that have failed to deploy are redeployed.

Even if MASTER is recovered and the configurations are synchronized, MS should be restarted if the non-dynamic configurations or running applications have been modified.

The following are the logs generated when MS starts in the INDEPENDENT mode.

JEUS_HOME/bin$ ./startManagedServer -domain jeus_domain -server server1 -u admin -p admin -masterurl localhost:9736
***************************************************************
- JEUS Home         : /home/jeus
- Java Vendor       : Sun
- Added Java Option :
***************************************************************
============== JEUS LICENSE INFORMATION ================
== VERSION : JEUS 9 (9.0.0.0-b15)
== EDITION: Enterprise (Trial License)
== NOTICE: This license restricts the number of allowed clients.
== Max. Number of Clients: 5
==========================================================
[2024.09.25 16:12:50][0] [launcher-1] [Launcher-0052] Receiving the configuration failed. Attempting to start as INDEPENDENT.
<<__Exception__>>
java.io.IOException: Connection failed. host:localhost, port:9736, virtual id:FileTransfer
 at jeus.net.SocketProxy.getConnection(SocketProxy.java:69)
 at jeus.net.SocketProxy.getConnection(SocketProxy.java:25)
 at jeus.server.filetransfer.ConfigurationSynchronizer.connect(ConfigurationSynchronizer.java:116)
 at jeus.server.filetransfer.ConfigurationSynchronizer.connect(ConfigurationSynchronizer.java:99)
 at jeus.server.filetransfer.ConfigurationSynchronizer.checkConnection(ConfigurationSynchronizer.java:141)
 at jeus.server.filetransfer.ConfigurationSynchronizer.downloadConfigFileFromMasterServer(ConfigurationSynchronizer.java:181)
 at jeus.launcher.ManagedServerLauncher.receiveConfigurationFromMasterServer(ManagedServerLauncher.java:245)
 at jeus.launcher.ManagedServerLauncher.updateXmls(ManagedServerLauncher.java:133)
 at jeus.launcher.ManagedServerLauncher.pullLatestDomainType(ManagedServerLauncher.java:67)
 at jeus.launcher.ManagedServerLauncher.initDescriptor(ManagedServerLauncher.java:53)
 at jeus.launcher.Launcher.start(Launcher.java:146)
 at jeus.launcher.ManagedServerLauncher.start(ManagedServerLauncher.java:73)
 at jeus.launcher.ManagedServerLauncher.main(ManagedServerLauncher.java:45)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at jeus.server.Bootstrapper.callMainMethod(Bootstrapper.java:576)
 at jeus.server.Bootstrapper.callMain(Bootstrapper.java:583)
 at jeus.server.Bootstrapper.main(Bootstrapper.java:151)
 at jeus.server.ManagedServerLauncherBootstrapper.main(ManagedServerLauncherBootstrapper.java:10)
<<__Exception__>>
[2024.09.25 16:12:50][1] [launcher-1] [Config-0157] SecurityDomainsConfigServiceProvider is jeus.service.descriptor.SecurityDomainsDescriptorFile.

...
[2024.09.25 16:12:53][0] [server1-1] [SERVER-0249] Successfully started the server INDEPENDENTLY
[2024.09.25 16:12:53][2] [server1-1] [SERVER-0248] The JEUS server is RUNNING.
[2024.09.25 16:12:53][2] [server1-1] [SERVER-0401] The elapsed time to start: 4079ms.
[2024.09.25 16:12:53][2] [launcher-21] [Launcher-0034] The server[server1] initialization completed successfully[pid : 15332].
[2024.09.25 16:12:53][0] [launcher-1] [Launcher-0040] Successfully started the server. The server state is now RUNNING.
JEUS_HOME/bin$

Once MASTER is restored, MS synchronizes the configurations with MASTER and redeploys any applications that have failed to deploy.

[2024.09.25 16:23:20][2] [server1-55] [Domain-0101] JEUS Master Server recovered. server1 is communicating with the JEUS Master server.
[2024.09.25 16:23:20][2] [server1-55] [SERVER-0201] Successfully connected to the JEUS Master Server(192.168.14.63:9736).
[2024.09.25 16:23:20][2] [server1-55] [SERVER-0308] Resynchronized the configuration with JEUS Master Server.

2. Class Loader Structure

This section describes the Isolated Class Loader supported in JEUS.

By default, the Shared Class Loader (hereafter Shared) is used in JEUS 5, and it is also supported in JEUS 7 for backward compatibility. However, it needs to be manually configured, otherwise the Isolated method is used by default. This guide does not cover shared class loader.

Applications use a separate class loader to prevent duplicate classes in JEUS. This is called Isolated Class Loader (hereafter Isolated). JEUS complies with the Jakarta EE standards that recommend to use the Isolated Class Loader.

The following is the Isolated Class Loader hierarchy.

figure jeusclassloaderhierachy
Isolated Class Loader Hierarchy

Each web module class loader of an application exists under an EJB class loader of the application. A class loader of an application does not request a class from a class loader of another application. When an application needs to use the interfaces of another application, it cannot reference the class loader of the application because Jakarta EE standards require that the interfaces be packaged together.

Since the classes are not shared, when deploying an application other applications do not need to be redeployed. The proper use of this class loader requires the binding of related applications into an EAR file to create a single application.

3. Server Directory Structure

Each server has its own directory under the DOMAIN_HOME folder. They exist in the servers directory under DOMAIN_HOME. Each server has a directory with its server name and stores information that is required to start and operate the server. This directory is called SERVER_HOME.

The following is the directory structure of SERVER_HOME.

{DOMAIN_HOME}
    |--servers
         |--server1
              |--.workspace
              |      |--deployed
              |      |--ejbtimerdb
              |      |--session
              |      |--tmlog
              |      |--tmp
              |--bin
              |--lib
              |   |--application
              |--logs
.workspace

Space used by each server in JEUS. Must not be modified by the user.

The following table describes each sub-directories.

Directory Description

deployed

Contains the unzipped image files of the applications deployed on the server and the files that were created when the applications were deployed. In this directory, directories are created by using application IDs to store the application files received from MASTER. Archived applications will be unzipped by using the application ID (deploy image).

Under the deployed directory, a directory named "_generated_" is created to store the files created when the applications are deployed. In this directory, directories are created by using application IDs to store the files required for deployment.

ejbtimerdb

Directory that is used for Apache Derby (a file-based database that is embedded in JEUS) when the timer services of the EJB engine does not have database configuration. For more information about timer services, refer to EJB Timer Service in JEUS EJB Guide.

session

Path of the file DB used in distributed session server. Distributed session servers store passivated sessions and backup sessions received from the primary session to this file DB. For more information, refer to Distributed Session Servers in JEUS Session Guide.

tmlog

Directory that contains transaction logs required for transaction recovery.

A sub directory is created with the name "_serverName_LOCATION_type_port_ipaddress_virtualport name". The following values are set for the type and virtualhost of the created directory name.

  • type: 0 for IPv4 and 1 for IPv6

  • virtualport: hash value of the server name

For more information, refer to Recovery Log File.

tmp

Directory that is used when temporarily saving files during server operation. There is no particular reason for users to access this directory.
bin

Contains the scripts for starting and stopping the server. The scripts execute the same functions as the scripts in 'JEUS_HOME/bin', but they don’t require the configuration of the domain name and server name.

The 'startMasterServer/stopserver' script is used for MASTER, and 'startManagedServer/stopserver' script is used for MS.

lib/application

Contains application libraries that are applied to the server.

The files in this directory is used when a library conflicts with a domain_level library in the 'DOMAIN_HOME/lib/application' directory. A warning indicating that there is a library conflict is displayed and the domin_level library is ignored on the server. For more information about 'lib/application', refer to lib/application Directory in JEUS Applictions & Deployment Guide.

logs

Contains the launcher log, server log, and access log files. According to the rotation rule, each log file is created as "logname_date.log00000" where "00000" represents a number between 1 and 99999. For more information, refer to Logging.

4. Launcher

In JEUS, both MASTER and MS are started by a launcher. A launcher process is executed when starting a server by using a script or starting MS from MASTER. The Launcher is responsible for preparing the server for startup and for starting up the server.

The launcher performs the following tasks:

  • Receive domain configuration files from MASTER.

  • Start the server.

First, the launcher receives the domain configuration files from MASTER. The files are domain.xml and security configuration files. When the launcher receives the files, it uses them to start the server JVM. When starting up the server, it reads JVM options and classpaths from the files and uses the options to create the server JVM.

If the launcher process fails to receive the configuration files but there are domain configuration files that are cached on the machine, the launcher will use them to start the server JVM. If the launcher fails to receive the configuration files and there are no cached files, the server cannot be started.

Besides the 2 aforementioned tasks, the launcher process acts as a logger for the server boot logs.

The logs that are generated when the server starts up are logged in the launcher logs. The launcher process starts the server JVM and waits for the server to complete the boot process and records logs that have been generated when the server finishes starting up. If the server fails to boot before the server resets the logger, the launcher logs can be used to check for the cause of the failure.

Generally, the launcher process starts the server JVM and terminates when the server starts up successfully. Note that the server process started by the launcher operates as a background process. Since the server process is started as a child process of the launcher process, it does not have its own console screen.

Hence, to print the server logs on a console screen, the '-verbose' option should be used to start a server. If the '-verbose' option is used, the launcher process does not terminate and it outputs the logs on the screen until the server is terminated. For more information, refer to Launcher Logger.