The START process for JBoss application Server

This article takes the JBoss application Server 4.2.1 GA (hereinafter referred to as JBoss) as an example to introduce its startup process on the Windows platform. To facilitate narration, the following assumptions are made to the platform environment: the Java Runtime installation path is C:/java, and JBoss's installation path is C:/jboss.

Since JBoss, written in 100% Java, has cross-platform features, why emphasize the Windows platform? This is because JBoss startup starts with platform-dependent script files, and script files on different platforms are different. For example, the script file on the window platform is the script on the Run.bat,linux platform is run.sh. The content of two files is very different, the function may be similar, nothing more than configure the startup environment, but there are also possible platform-related factors. I only read the Run.bat, do not understand run.sh, for the sake of prudence, I only introduce run.bat, to run.sh not to elaborate.

Before I introduce the JBoss startup process, I'd like to introduce the structure characteristics of JBoss, which will help you understand the startup process. JBoss is based on the JMX framework, and its structure is a mbeansserver and some mbean that hangs on the mbeanserver. Mbean provides functionality, Mbeanserver is the communication bus between Mbean. The advantage of the JMX framework is that it provides a high degree of flexibility and configuration for JBoss. Configurable is also one of the core concepts of JBoss, and almost all of the JBoss components can be replaced. JBoss helps to achieve high levels of configuration by means of system properties, configuration files, and more. We can customize our JBoss version by setting the system properties, or by editing the configuration file. This kind of configuration is embodied in the various parts of JBoss, the starting process can only be seen, if you want to know did, you can study the JBoss EJB container and other components.

After introducing the structural features of JBoss, we begin to enter the JBoss startup process. The entire process can be divided into six phases, which are described in turn.

First, execute the startup script, configure the startup environment

The starting process for JBoss starts with the execution of Run.bat, and Run.bat's main job is to configure the startup environment.

JBoss's startup environment is actually some startup parameters, such as JBoss installation path, Java command parameters, JBoss Classpath, and so on. If an error occurs during the configuration process, the execution of the Run.bat will be interrupted.

Run.bat will configure the following startup parameters:

Jboss_home

The installation path for JBoss, whose value is C:/jboss

PATH

Adding c:/jboss/bin/native to the path, the files under native are platform-dependent and can optimize JBoss performance.

Java

The path to the Java.exe file, whose value is C:/java/bin/java

Java_optsb

The parameters of the Java command, whose value is-dprogram.name=run.bat–server-xms128m–xmx512m–dsun.rmi.dgc.client.gcinterval=3600000– dsun.rmi.dgc.server.gcinterval=3600000

Jboss_classpath

The starting class path of JBoss, whose value is C:/java/lib/tools.jar; C:/jboss/bin/run.jar. The class files required for JBoss's startup are in these two jars.

If the system environment variable java_home is not set, then the execution of Run.bat will be interrupted and the JBoss startup loss

Defeat. Therefore, after the installation of JBoss, be sure to set the Java_home system environment variables.

If the run.bat executes smoothly, the following command will be executed at the end:

C:/JAVA/BIN/JAVA-DPROGRAM.NAME=RUN.BAT–SERVER-XMS128M–XMX512M–DSUN.RMI.DGC.

client.gcinterval=3600000–dsun.rmi.dgc.client.gcinterval=3600000-djava.endorsed.dirs=

C:/jboss/lib/endorsed–classpath C:/java/lib/tools.jar; C:/jboss/bin/run.jar org.jboss.main/%*

%* represents the startup parameters after Run.bat.

Start with this command to actually run the JBoss code.

Second, the entrance of JBoss launch

JBoss's magic begins with the Main.main method. Main This class is located in Run.jar. The Main.main method creates a thread group named "JBoss" and then creates and runs the thread "main" for that thread group. When the "main" thread begins to run, the Main.main method finishes and the main thread ends. The main task of the "main" thread is to invoke the Main.boot method.

The main job of the Main.boot method is to process command-line arguments and then create and run a server instance. When the server instance starts running, the JBoss startup process ends successfully. The following stages are the process of executing the boot method.

Iii. Handling Command-Line arguments

The boot method calls the Main.processcommandline method to handle command-line arguments. The command line argument here is actually the args parameter of the main method, which is passed as an argument to the ProcessCommandLine method.

The ProcessCommandLine method uses the Gnu-getopt package to parse command-line arguments, and handles different command-line parameters in a different way, as follows:

After some of the parameters are simply processed, the program exits directly. These parameters include:

-h displays Help messages.

-V Displays version information. Version information is obtained from the MANIFEST.MF file in Run.jar.

Some of the parameters are saved in the server properties (Main.props), which include:

-P Patch directory.

-n URL that is started from the network.

-C Server Configuration name, three predefined, minimal, default, and all. Of course, it can be customized.

-B The address of all JBoss service bindings, which must be configured if you need to access the JBoss service from another machine.

Name of-G ha partition

-U UDP Multicast address

Some of the parameters are saved in the member variable in Main, which includes:

-d boot patch directory saved in URL Booturl

-B Additional libraries added to the boot classpath are saved in list bootlibraries

-L Additional libraries added to the class loading path are saved in list extralibraries

-C Additional URLs added to the class loading path are saved in list Extraclasspath

Some of the parameters are saved in the System properties, which include:

-D System Properties

-P loaded properties from a given URL

-L Specify Log plug-in class, currently has log4j and JDK two kinds.

When the ProcessCommandLine method completes, the boot method loads, creates, and runs a server instance.

Iv. loading and creating server instances

The server instance is a Run-time object that represents the running JBoss application server. When you start an JBoss application server, you have a server instance that corresponds to it. In JBoss, the implementation of the server instance can be configured, that is, the server class is not solidified, but can be replaced. This poses a problem: JBoss must search for and load the server class during startup.

The work of searching and loading the server instance class is done by a secondary class, and its fully qualified class name is Org.jboss.system.server.ServerLoader. This class creates a specific ClassLoader and uses the class loader to load the server class and then uses the reflection mechanism to create a server instance.

The boot method first creates a ServerLoader instance, which we call the loader, and then the boot method adds some URLs to the loader. We refer to these URLs as server search paths. Loader is searching for server classes in the server search path. The server search path includes:

Booturl is provided by the-D parameter. If Booturl is a file directory, the URL of the jar under it is also added.

The bootlibraries is provided by the-B parameter.

Endorsed jars all jar packages located under C:/jboss/lib/endorsed.

Jmxlibs C:/jboss/lib/jboss-jmx.jar.

Concurrentlib C:/jboss/lib/concurrent.jar.