Tomcat Virtual Directory Mapping

After you've installed TOMCAT, copy your Web project to%tomcat_home%webapps and it's OK. A better approach is to set up a virtual directory that maps the project's directory to Tomcat. This project does not need to be placed under Tomcat and is convenient for developers, as follows:
1. Find%tomcat_home%\conf\server.xml, (that is, TOMCAT's installation directory under the relevant file) to open this XML file, add the following code between
<context path= "" reloadable= "true" debug= "0" docbase= "E:\workspace\test\bin" workdir= "E:\workspace\test\work" Crosscontext= "true" >
</Context>

<context path= "/test" docbase= "E:\aaa" debug= "0" reloadable= "true"/>

Docbase is the actual path, here generally write an absolute disk path, of course, can also write relative path, relative path is relative to the Tomcat installation directory of the WebApps directory, usually set up the virtual directory is the purpose of the installation of Tomcat and the preservation of the project is separated, Therefore, it is recommended that you use the absolute path of the disk, and this disk path is occasionally in the Tomcat installation directory. Workdir is a tomcat run is a compiled file for JSP files, this file is best also separate.
Path is the virtual path, access time, note: Be sure to add "/". It is worth noting that path can be "/" then access to the "IP: Port" can access to the layout of the project, if it is "/test", then you have to access "IP: Port/test" To access, I recommend the first method. Otherwise access each project has to have a virtual path, look uncomfortable. Maybe you'll think about what to do if I have multiple projects. is not sure to take a few virtual paths, if you use an IP words that is certain. But if you set the machine to more than a few IP, then the line, each project occupies an IP, so that the hierarchy is clearer.
Debug recommended setting to 0,reloadable is set to true.

In fact, not so troublesome, as long as the <context path= "/ehop" docbase= "D:\Study\Myproject\workspace\EShop\WebRoot"/> Written in </Host> The line above is OK.


2, if there is a 404 error in the test, if the previous configuration is not wrong, it may be in the%tomcat_home%\conf\web.xml file to display the virtual path directory to prohibit, at this time can be found in the Web. xml file
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Change the value of listings to true, then restart Tomcat, and at the input URL, the test succeeds.


3, if the project development is completed, ready to deploy on the server, remember to the third step in the Web. xml file, the value of the parameter listings to false, so as to avoid the project deployment path to the consumer.
Specific as follows:
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>

</init-param>

--------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------

Context naming:

When Autodeploy or deployonstartup are used then there are a close relationship between Thecontext name, context Path, CO ntext version and the base file name used for the war and/or directory this contains the Web application when the war or D Irectory is located in the Host ' s appBase. When no version is specified, the rules are:contextname = ContextPath If The contextpath is a zero length string, the BAS E name is ROOT If The contextpath are not a zero length string and the base name is the ContextPath with the leading '/' Remov Ed and any remaining '/' characters in the path replaced with ' # '. When a-version is specified, # #version are added to the Contextname and base name. To help clarify these rules, some examples is given in the following table.

/foo/bar

context Path	Context Version	context Name	Base fil ename
/foo	None	/foo	foo
None	/foo/bar	foo#bar
Empty String	None	Empty String	ROOT
/foo	all	/foo# #42	foo# #42
/foo/bar	all	/foo/bar# #42	foo#bar# #42
Empty String	all	# #42	root# #42

The version component is treated as a String both for performance reasons and to allow flexibility in versioning schemes. String comparisons is used to determine version order. If version is not a specified, it is treated as the empty string. Therefore, Foo.war is treated as an earlier version than foo# #11. War and foo# #11. War would be treated as an earlier VE Rsion thanfoo# #2. War. If using a purely numerical versioning scheme it's recommended that zero padding are used so thatfoo# #002. War is treated a S an earlier version than foo# #011. War.

If you want to deploy a WAR file or a directory using a context path which is not related to the base file name then one of The following options must is used to prevent double-deployment:disable Autodeploy and Deployonstartup and define all contexts in Server.xml Locate the WAR and/or directory outside of the Host ' s appBase and use a context.xml file wit H a DocBase attribute to define it.

defining a Context:

It isn't recommended to place <Context> elements directly in the Server.xml file. This was because it makes modifying theContext configuration More invasive since the main conf/server.xml file can Not being reloaded without restarting Tomcat.

Individual Context elements May is explicitly defined:in an individual file At/meta-inf/context.xml Inside the application files. Optionally (based on the Host's Copyxml attribute) This could be copied to$catalina_base/conf/[enginename]/[hostname]/and R Enamed to application ' s base file name plus a ". xml" extension. In individual files (with a ". xml" extension) in the $CATALINA _base/conf/[enginename]/[hostname]/directory. The context path and version would be derived from the base name of the file (the file name less the. xml extension). This file would always take precedence over any context.xml file packaged in the Web application ' s Meta-inf directory. Inside a Host element in the Mainconf/server.xml.

Default Context elements may defined this apply to multiple Web applications. Configuration for a individual Web application would override anything configured in one of these defaults. Any nested elements, e.g. <Resource> elements, that is defined in a default Context would be created once F or each Context to which the default applies. They is not being shared betweenContext elements. In the $CATALINA _base/conf/context.xml file:the context element information would be a loaded by all WebApps. In the $CATALINA _base/conf/[enginename]/[hostname]/context.xml.default file:the context element information'll be Loaded by all webapps of that host.

With the exception of server.xml, files, define Context elements could only define a singleContext ele ment.

In addition to explicitly specified context elements, there is several techniques by which Context elements can be create D automatically for you. Seeautomatic application Deployment and User Web applications for more information.

To define multiple ContextS. Use a single WAR file or directory, use one of the options described above for C Reating Acontext that have a path that is not related to the base file name and create multipleContext de Finitions. For more infomation refer to:virtual Hosting and Tomcat

The Context Container