Shulou(Shulou.com)06/01 Report--

This article mainly shows you the "sample analysis of Tomcat configuration files", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and study the "sample analysis of Tomcat configuration files".

Tomcat users must know that it contains a configuration file called server.xml. After all, the application has been changed here or deployed in the form of a directory.

How does the configuration information in this configuration file correspond to specific objects in Tomcat? Dom4j, Jdom, JAXB and SAX... will immediately appear in the brain of the developer. A series of XML parsing tools.

However, instead of using the above mentioned guys, Tomcat uses the Apache community's own XML parsing tool, Digester.

In Digester's Wiki, introduce yourself like this:

Many projects read XML configuration files to provide initialization of various Java objects within the system. There are several ways of doing this, and the Digester component was designed to provide a common implementation that can be used in many different projects.

Let's take a look at how Tomcat uses Digester internally.

Within the Catalina class, we will find a lot of code like this:

Digester.addObjectCreate ("Server/Service"

"org.apache.catalina.core.StandardService"

"className")

Digester.addSetProperties ("Server/Service")

Digester.addSetNext ("Server/Service"

"addService"

"org.apache.catalina.Service")

Digester.addRuleSet (new NamingRuleSet ("Server/GlobalNamingResources/"))

Digester.addRuleSet (new EngineRuleSet ("Server/Service/"))

Digester.addRule ("Server/Service/Connector"

New ConnectorCreateRule ()

These are the configurations, and the final parsing is done through parse.

InputSource.setByteStream (inputStream)

Digester.push (this)

Digester.parse (inputSource)

Is it illegal for the whole parse to parse the configuration file? Of course Not.

Corresponding to the addObjectCreate and addSetProperties marked in red above, a series of Rule is actually added behind these operations.

This is an abstract class with different implementations for the different Rule added above.

Where the corresponding implementation of create is ObjectCreateRule

Public void addObjectCreate (String pattern, String className

String attributeName) {

AddRule (pattern

New ObjectCreateRule (className, attributeName))

}

SetProperties corresponds to SetPropertiesRule.

Public void addSetProperties (String pattern) {

AddRule (pattern

New SetPropertiesRule ()

}

The Rule corresponding to setNext is SetNextRule

In the process of parsing, SetNextRule essentially calls the corresponding method through reflection. The following figure shows the Rule of a setServer executing Catalina

Corresponding to the execution of setProperties, the value of the corresponding property is also set through reflection. For example, the following figure shows setting the value of the port property of Server.

At this point, you may ask, how do these objects relate to each other when setting properties, creating new objects, and so on?

Here, a stack structure is maintained within Digester, from bottom to top, higher and higher. As shown below, from Catalina, up to Server, and then to Service

When carrying out Set, it will be from top to bottom, two adjacent ones, that is, the father-son relationship, thus setting the child of parent.

Public void end (String namespace, String name) throws Exception {

/ / Identify the objects to be used

Object child = digester.peek (0)

Object parent = digester.peek (1)

/ / Call the specified method

IntrospectionUtils.callMethod1 (parent, methodName

Child, paramType, digester.getClassLoader ()

}

When the corresponding property is set, the top one is taken from the stack, and the reflection is used to set the property.

The bottom layer of the whole stack is Catalina, the push operation after getting the configuration file input stream.

Public void push (Object object) {

If (stack.size () = = 0) {

Root = object

}

Stack.push (object)

}

The overall design idea of Digester is to push the newly created object into stack when the rule execution of Object is created at the beginning of the XML element. The object remains in the stack until the end of the XML element appears.

The parsing process of Rule mainly involves several methods of the Rule class above

The begin element is executed at the beginning

Executes when body nested elements match

The end element ends execution

Called at the end of the entire parse of finish

After the end of the parse, the Java object corresponding to the entire xml content has been created successfully, let's go!

Within Tomcat, Digester is used to parse server.xml configuration files, MBean description files, TLD file validation, and so on.

The specific use is also relatively simple, new a Digester object, and then set a specific object Rule, similar to all kinds of match rules, and then parse.

For example, the following xml file

That's all the Digester code is parsing.

Digester digester = new Digester ()

Digester.setValidating (false)

Digester.addObjectCreate ("foo", "mypackage.Foo")

Digester.addSetProperties ("foo")

Digester.addObjectCreate ("foo/bar", "mypackage.Bar")

Digester.addSetProperties ("foo/bar")

Digester.addSetNext ("foo/bar", "addBar", "mypackage.Bar")

InputStream is = digester.getClass () .getClassLoader () .getResourceAsStream ("mytest.xml")

Foo foo = digester.parse (is)

Of course, the specific XML file needs the corresponding Java class is still required.

The above is all the content of the article "sample Analysis of Tomcat configuration File". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.