How Tomcat works-VII, Tomcat release WebApp

Directory

• What do you call publishing
• WebApp Release method
• Reload
• Summarize

What do you call publishing

The release is to let Tomcat know where our program is and create a context based on our configuration to initialize and launch it as follows:

• Where the program is located
• Create context, add to host
• Initialize (create Digester to parse Webxml)
• Start (Initialize filter, listener, servlet)

WebApp Release method

The way you publish WebApp in Tomcat will cause the app to start in a different order (this is divided by the boot order or timing):

1. Configuration in XML, configured in Conf/server.xml (inside the host tag)
2. Place the WebApp folder, the war package directly under Tomcat under the "WebApps" directory, or create a new XML under WebApps (the root tag is context, indicating the location of the application in the attribute)

In fact, the two types of publishing are only slightly different in the boot sequence, the boot process is exactly the same, first to configure the description in the Server.xml

Configuring in Server.xml

This happens when we use tools such as Eclipse to launch the development, eclipse will help us add a context to the Server.xml's host tag, as follows:

<?xml version= "1.0" encoding= "UTF-8"?><!--Licensed to the Apache software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with ThisWork foradditional information regarding copyright ownership. The ASF licenses ThisFile to under the Apache License, Version 2.0( the"License"); If you don't use Thisfile except in compliance with the License. Obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0unless required by applicable law or agreed to writing, software distributed under the License are distributed on an"As is"BASIS, without warranties or CONDITIONS of any KIND, either express or implied. See the License forThe specific language governing permissions and limitations under the License.--><!--note:a "Server" is not itself A "Container"define subcomponents such as"Valves" at ThisLevel . Documentation at/docs/config/server.html--><server port= "8006" shutdown= "shutdown" > <listener classname= " Org.apache.catalina.startup.VersionLoggerListener "/> <!--Security Listener. Documentation at/docs/config/listeners.html<listener classname= "Org.apache.catalina.security.SecurityListener"/>-<!--APR Library loader. Documentation At/docs/apr.html--<listener sslengine= "on" classname= " Org.apache.catalina.core.AprLifecycleListener "/> <!--Initialize Jasper prior to WebApps is loaded. Documentation At/docs/jasper-howto.html--<listener classname= "Org.apache.catalina.core.JasperListener"/ > <!--Prevent memory leaks due to use of particular Java/javax apis--> <listener classname= "Org.apache.cata Lina.core.JreMemoryLeakPreventionListener "/> <listener classname=" Org.apache.catalina.mbeans.GlobalResourcesLifecycleListener "/> <listener classname=" Org.apache.catalina.core.ThreadLocalLeakPreventionListener "/> <!--Global JNDI Resources Documentation at/docs/jndi-resources-howto.html-<GlobalNamingResources> <!--Editable User database that can also is used by Userdatabaserealm to authenticate users--<resource auth= "Container" description= "User database that can be updated and saved" factory= "Org.apache.cata Lina.users.MemoryUserDatabaseFactory "Name=" Userdatabase "pathname=" Conf/tomcat-users.xml "type="  Org.apache.catalina.UserDatabase "/> </GlobalNamingResources> <!--a" Service "is a collection of one or more "Connectors"That share a single"Container" note:a "Service" is not itself A "Container"define subcomponents such as"Valves" at ThisLevel . Documentation at/docs/config/service.html--<service name= "Catalina" > <!--the connectors can use a GKFX executor, you can define one or more Nam Ed thread pools--> <!--<executor name= "Tomcatthreadpool" nameprefix= "catalina-exec-"MaxThreads= "Minsparethreads=" "4"/>-<!--A "Connector"Represents an endpoint by which requests is received and responses are returned . Documentation At:java HTTP Connector:/docs/config/http.html (Blocking & non-blocking) Java AJP Connector:/docs/config/ajp.html APR (HTTP/AJP) Connector:/docs/apr.html Define a non-ssl http/1.1 Connector on port 8080-to <connector connectiontimeout= "20000" port= "8888" protocol= "http/1.1" redirectport= "8445"/> <!--A "Connector" using the shared thread pool--> <!--<connector executor= "Tomcatthreadpool"Port= "8080" protocol= "http/1.1"ConnectionTimeout= "20000"Redirectport= "8443"/>-<!--Define a SSL http/1.1 Connector on port 8443This connector uses the BIO implementation that requires the JSSE style configuration. When using the APR/nativeimplementation, the OpenSSL style configuration is required as described in the APR/nativeDocumentation-<!--<connector port= "8443" protocol= "Org.apache.coyote.http11.Http11Protocol"MaxThreads= "Sslenabled=" "true" Scheme= "https" secure= "true"ClientAuth= "false" sslprotocol= "TLS"/>-<!--Define an AJP 1.3 Connector on port 8009-<connector por t= "8019" protocol= "ajp/1.3" redirectport= "8443"/> <!--An Engine represents, the entry point (within Catalina), that processes every request. The Engine implementation forTomcat stand alone analyzes the HTTP headers included with the request, and passes them the app         Ropriate host (virtual host). Documentation at/docs/config/engine.html-<!--you should set Jvmroute-to-support load-balancing via AJP ie:<engine name= "Catalina" defaulthost= "localhost" jvmroute= "jvm1" >-<engine defaulthost= "localhost" nam E= "Catalina" > <!--for clustering, take a look at documentation at:/docs/cluster-howto.html (Simple-to)/docs/config/cluster.html (reference documentation)-<!--<cluster Classname= "Org.apache.catalina.ha . TCP. Simpletcpcluster "/>-<!--Use the Lockoutrealm to prevent attempts to guess user passwords via a brute-force Attack-<realm classname= "Org.apache.catalina.realm.LockOutRealm" > <!--This Realm uses the userdatabase configured in the global JNDI resources under the key"Userdatabase". Any edits that is performed against ThisUserdatabase is immediately available forUse by the Realm. --<realm classname= "Org.apache.catalina.realm.UserDatabaseRealm" resourcename= "Userdatabase"/> < /realm> Singlesignon valve, share authentication between Web applications documentation at:/docs/config/valve.html-<!--<valve classname= "Org.apache.catalina.authenticator.SingleSignOn" />-<!--Access Log processes all example. Documentation at:/docs/config/valve.html note:the pattern used is equivalent to using pattern= "Common"-<valve classname= "Org.apache.catalina.valves.AccessLogValve" directory= "Logs" pattern= "%h% L%u%t &quot;%r&quot; %s%b "prefix=" Localhost_access_log. "suffix=". txt "/> <context docbase="/VAR/TOMCAT-TEST/WEBAPPS/TESTTOMC At "path="/testtomcat "reloadable=" true "source=" Org.eclipse.jst.jee.server:TestTomcat "/> </Host> </ Engine> </Service></Server>

View Code

When you create a new server, the Server.xml is parsed, and a new standardcontext is created based on the configuration above, and Standardcontext is used as a child of the host (which can be catalina.createstartdigeste R method to see how to parse Server.xml), the context is initiated by the parent container host during Tomcat startup

Well, see this picture to find déjà vu, the drop, is the context of the initialization, because in Tomcat a context instance represents a webapp, so in fact, the application WebApp release itself is the context of the initialization and start, And look at the context launch.

The above has fully demonstrated a WebApp release process, that is, in the Server.xml configuration of the WebApp release process, followed by a look at the WebApps directory of the publishing process.

Under the WebApps directory

The Containerbase.startinternal method of the parent class is called in the Startinternal method of Standardhost, and after Standardhost publishes the app configured in Server.xml, it calls the SetState to switch the state of itself, this time will trigger listener Hostconfig Lifecycleevent method

@Overrideprotected synchronized voidStartinternal ()throwslifecycleexception {//Start Our subordinate components, if any    if((Loader! =NULL) && (LoaderinstanceofLifecycle))    ((Lifecycle) loader). Start (); Logger=NULL;    GetLogger (); if(Manager! =NULL) && (ManagerinstanceofLifecycle))    ((Lifecycle) manager). Start (); if((Cluster! =NULL) && (clusterinstanceofLifecycle))    ((Lifecycle) cluster). Start (); Realm Realm=getrealminternal (); if(Realm! =NULL) && (RealminstanceofLifecycle))    ((Lifecycle) realm). Start (); if(Resources! =NULL) && (ResourcesinstanceofLifecycle))    ((Lifecycle) resources). Start (); //Start Our child containers, if any
Because in the parsing Server.xml has created the context, here can directly start Container children[] =Findchildren (); List<Future<Void>> results =NewArraylist<future<void>>();  for(inti = 0; i < children.length; i++) {Results.add (Startstopexecutor.submit (NewStartChild (Children[i])); }    BooleanFail =false;  for(future<void>result:results) {        Try{result.get (); } Catch(Exception e) {log.error (sm.getstring ("Containerbase.threadedstartfailed"), E); Fail=true; }    }    if(fail) {Throw Newlifecycleexception (sm.getstring ("Containerbase.threadedstartfailed")); }    //Start The valves in we pipeline (including the basic), if any    if(PipelineinstanceofLifecycle)　　 ((Lifecycle) pipeline). Start (); Call the Lifecycleevent method, trigger the start event of the Standardhost, trigger the Start method of the listener hostconfig, all the WebApps below are published in the Start Method SetState (    lifecyclestate.starting); //Start Our threadThreadStart ();}

The calling process is as follows:

(The main draw of the deploywars call process, the other two deploy methods are similar)

The main methods in the Hostconfig.deployapps are:

• Call Deploydescriptors: Publish all WebApp that use the XML configuration, because there may be more than one XML, so Deploydescriptor is called inside the method to publish each XML corresponding WebApp
• Call Deploywars: Publish all the war packages in the WebApps directory, or there may be multiple
• Call Deploydirectories: Publish all applications directly deployed in the WebApps directory

As I said earlier, the release WebApp is a new context object and initialized and started, the main functions of the above three methods are:

Class<?> clazz =    + ". War"); Host.addchild (context);

• Build a Standardcontext
• The context is added to host and is called in the Container.addchildinternal method Context.start

The next steps are consistent with the WebApp that is configured above in Server.xml.

Reload

When we use Tomcat to develop the web, we often use the "Hot Load" (hot Deployment) function, then what is the rationale? The WebApp release is described above because the reload feature is also starting from Hostconfig, so continue to introduce reload features

The above containerbase.startinternal is called by the Standardengine.startinternal method, and initiates a daemon thread to detect whether the WebApp has changed (if the file has been modified) and to restart Stan if modified Dardcontext.

Summarize

Like Tomcat deployment and release, we use every day, but do not know how the principle of how, after learning the tomcat source code, all this is more clear. Know it, know why.

How Tomcat works-VII, Tomcat release WebApp