A detailed description of the JBoss startup process

Today I looked at JBoss Boot.log and Server.log logs, combined with their own understanding and other information, and now the launch and loading process of JBoss to make the following summary;

Boot.xml is a log of the server's startup process and does not involve subsequent procedures

Server.xml is a log of the operation process and is more detailed, which contains the process of initiating

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 the narrative, the following assumptions are made to the platform environment: the installation path for the Java runtime is C:/java,jboss C:/jboss.

Since JBoss, written in 100% Java, has cross-platform features, why stress the Windows platform? This is because JBoss startup starts with a platform-dependent script file, and the 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 contents of the two files are very different, the function may be similar, nothing more than the configuration of the boot environment, but there may be platform-related factors. I only looked at the Run.bat, run.sh do not understand, for the sake of prudence, I only introduce run.bat, run.sh do not elaborate.

Before introducing the JBoss startup process, I would like to introduce the structural features 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. The Mbean provides functionality, and the mbeanserver is the communication bus between the Mbean. The advantage of the JMX framework is that it provides JBoss with a high degree of flexibility and configuration. The ability to configure is one of the core concepts of JBoss, and almost all jboss components can be replaced. JBoss helps to achieve a high degree of flexibility through a variety of methods, such as System properties, configuration files, and more. We can customize our version of JBoss by setting the system properties or by editing the configuration file. This configuration is reflected in all areas of JBoss, and the start-up process can only be seen, and if you want to know whole picture, consider other components such as JBoss EJB container.

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

First, execute the startup script, configure the startup environment

The start-up process for jboss begins with the execution of Run.bat, and Run.bat's primary task is to configure the boot environment.

JBoss startup environment is actually some startup parameters, such as the installation path of JBoss, 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

JBoss installation path with a value of C:/jboss

PATH

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

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 classpath for JBoss, with a value of C:/java/lib/tools.jar; C:/jboss/bin/run.jar. The class files required for JBoss start-up are in these two jars.

If the system environment variable java_home is not set, then the execution of the Run.bat will be interrupted and the JBoss boot fails. Therefore, after installing JBoss, be sure to set the

Java_home system Environment variables.

If Run.bat performs well, 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/%*

The%* represents the startup parameters behind the Run.bat.

Start with this command and actually run JBoss's code.

Ii. Access to JBoss startup

JBoss 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" of the thread group. After the "main" thread starts running, the Main.main method executes and the main thread ends. The main task of the "main" thread is to call the Main.boot method.

The main task 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 is completed successfully. The following phases are the process of the boot method execution.

Third, processing command line parameters

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 to the ProcessCommandLine method as an argument.

The ProcessCommandLine method uses the Gnu-getopt package to parse the command-line arguments, with different processing methods for different command-line arguments, briefly summarizing the following:

After some parameters are simply processed, the program exits directly.

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

Iv. loading and creating a server instance

A server instance is a run-time object that represents a running JBoss application server. Starting a JBoss application server, you will have a server instance with

The corresponding. in JBoss, the implementation of the server instance can be configured, that is, the server class is not cured, but can be replaced. This poses a problem:

JBoss must search for and load the server class during startup.

The task of searching for and loading a server instance class is done by an auxiliary class whose fully qualified class name is Org.jboss.system.server.ServerLoader. This class will create

A specific ClassLoader and uses the ClassLoader to load the server class, and then use the reflection mechanism to create a server instance.

The boot method first creates a ServerLoader instance, which we call loader, and then the boot method adds some URLs to the loader. We refer to these URLs as

The server search path. Loader is the search for server classes in the server search path.

Loader comes with URLs Log4j-boot.jar, Jboss-common.jar, Jboss-system.jar, Jboss-xml-binding.jar.

After adding the server search path, the boot method calls the loader load method. The Load method creates a class loader with the server search path as a parameter, and uses the

It searches for and loads server classes. If the load is successful, use the radiation mechanism to create a server instance that we call server.

The default server class is Org.jboss.system.server.ServerImpl, which is located in C:/jboss/lib/jboss-system.jar and not in the classpath of JBoss

the. Therefore, loader must create its own classloader and use the server search path as the class search path to find Serverimpl. By setting

Jboss.server.type System Properties, you can also use custom server classes. Of course, the premise is to ensure that the class file of the custom server class is searched on the server path

The path.

After the server instance has been created, it needs to be configured, which is the following initialization work.

V. Initializing the server instance

The primary task of initializing a server instance is to encapsulate the server configuration information in an object. This object is a class

examples of Org.jboss.system.server.ServerConfigImpl, such as Org.jboss.system.server.ServerConfigImpl@8b33e8. It includes basic configuration information for the server instance, such as the installation path for JBoss, the root of the server

directory, the server's log directory, the server's temp directory, the server's library path, and so on.

The boot method invokes the Init method of the server and begins the initialization work. The Init method delegates the initialization work to the server: Doinit method. The Doinit method creates and configures the Serverconfigimpl object, and finally prints out the server's configuration information in the console and in the log.

The Serverconfigimpl object is an Mbean, so users can use the JMX console to view configuration information for a server instance.

Once the initialization is complete, the server instance is started.

Vi. starting the server instance

Starting a server instance is a complex process in which a lot of work needs to be done. As mentioned earlier, JBoss is based on the JMX framework, and the main functions of JBoss are

In the form of an mbean as a service, the service communicates with the JMX bus. So far, we haven't seen JMX-related work. Therefore, in the service

The first step in the startup process of the instance is to build the JMX framework. After the JMX framework is built, JBoss needs to create several basic services that are

The form of an mbean, which hangs on the jmx frame. After that, JBoss begins the deployment process. JBoss preconfigured services, the user's deployment unit, are deployed and started at this stage.

The boot method invokes the Server.start method and begins the startup process. The Start method delegates the startup work to the Server.dostart method. The Dostart method is completed sequentially to

Work under:

1. Create and start a timer

This timer is used to calculate the time of JBoss startup, and the secret behind this is the time it takes for the console to output the startup process after the JBoss boot succeeds. (This

It doesn't matter, for completeness to introduce).

2. Create a Mbeanserver instance

Mbeanserver is the core of the JMX framework. JBoss needs to create a Mbeanserver instance. , the implementation of Mbeanserver can also be configured. can now

Using two kinds of mbeanserver, one is the JVM platform Mbeanserver, it is provided by the Java platform, and the other is provided by JBoss, the fully qualified class name is

Org.jboss.mx.server.MBeanServerImpl. By setting Javax.management.builder.initial System Properties, you can also use the custom

Mbeanserver. So what kind of implementation does JBoss use? If the Java version reaches or exceeds 5.0, and the Jboss.platform.mbeanserver system belongs to

True, use the JVM platform Mbeanserver, or use the Mbeanserverimpl provided by JBoss. (this point is inaccurate and involves

Lazymbeanserver, I'm not quite clear yet. As you can see, most of the cases are Mbeanserverimpl provided by JBoss.

3. Create and register a basic service

During the creation of the Mbeanserverimpl, the following 3 Mbean are created:

The first Mbean is Javax.management.MBeanServerDelegate, objectname=jmimplementation:type=mbeanserverdelegate

The second mbean is a dynamic mbean,org.jboss.mx.modelmbean.xmbean,objectname=jmimplementation:type=mbeanregistry

The third Mbean is a org.jboss.mx.loading.UnifiedLoaderRepository3,

Objectname=jmimplementation:service=loaderrepository, Name=default

The first Mbean was created before the call to Mbeanserverimpl, followed by the two Mbean that were created in the Mbeanserverimpl constructor. The second Mbean is the registry used to Mbeanserver, and all Mbean that hangs on Mbeanserver are registered in the registry. The third Mbean is related to the class-loading architecture of JBoss and is one of the basic services.

Server servers and Serverconfigimpl are also Mbean, and are also registered to Mbeanserver,objectname Jboss.system:type=server and jboss.system:type= respectively. Serverconfig.

The Dostart method then creates and registers the following 3 Mbean:

The first Mbean is a org.jboss.system.server.ServerInfo,

Objectname= Jboss.system:type=serverinfo

The second Mbean is a org.jboss.system.ServiceController,

Objectname= Jboss.system:service=servicecontroller

The third Mbean is a org.jboss.deployment.MainDeployer,

Objectname= Jboss.system:service=maindeployer

The first Mbean mainly encapsulates information about the hardware and software platforms that JBoss runs, including host addresses, J-OS versions, Java versions, and so on.

The second mbean is used to control the life cycle of the Mbean. The JMX specification does not provide

Quote from blog: http://www.2cto.com/os/201404/293620.html

A detailed description of the JBoss startup process