Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 5: Basic Tomcat Confi guration org.apache.catalina.servlets.DefaultServlet
debug 0
listings true 1 Default Directory Listings and Other Customizations You can disable directory listings by setting the listingsparameter to false. You can further customize the behavior of the default servlet by using the parameters shown in the following table. Only the frequently changed parameters are shown. Parameter Description listings readonly input Output globalXsltFilelocalXsltFile sendfileSize Determines if directory listings should be shown when a URL reaches the root of a directory. This is implemented to provide compatible behavior with most Web servers. Set this to false if you want to tighten security, or if some directories are very large and take significant time to display. Controls if write HTTP methods such as PUTand POST are allowed. Default is true. You need to override this if you need to enable upload. The buffer size used when reading resources. By default it is set to 2048 or 2KB. The buffer size used when writing resources. By default it is set to 2048 or 2KB. Specifies an XSLT stylesheet to use when displaying directory listings. This can be used to customize the look of the directory listings. localXsltFilespecifies a file name in the directory that Tomcat looks for to format the listing. globalXsltFilespecifies a stylesheet that can be located in any directory, via an absolute path. If a localXsltFileis not specified, the global stylesheet is used. If there are no global or local XSLT stylesheets, then the listings will not be formatted. Tomcat 6 supports the platform-specific use of a system-level asynchronous sendfile() to optimize the serving of large static resources (such as images). This parameter sets the threshold of file size before a file is considered for sendfile()transmission. The size is specified in KB and the default is 48. The next section of the default web.xml configures the invokerservlet.

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 5: Basic Tomcat Confi guration This concludes the coverage of Context descriptor and the system default context.xmlfile in the $CATALINA_HOME/confdirectory. Authentication and the tomcat-users.xml File Another configuration file found in the $CATALINA_HOME/conf directory is tomcat-users.xml . The tomcat-users.xml file is used by Tomcat 6 to authenticate manager tool users. Tomcat 6 makes use of a UserDatabase Realm component to accomplish this. The UserDatabase Realm enables modification of the loaded data and can properly persist (write back to the XML file) any changes made to the data. Only users assigned to role manager will be able to access the managerapplication. The Default Deployment Descriptor web.xml According to the Servlet 2.5 specification, every Web application should include a deployment descriptor (web.xmlfile). This file must be placed in the WEB-INF/ directory of the Web application and so is specific to just that Web application. There is also a web.xmlfile under the $CATALINA_HOME/conf directory. This file is similar to a Web application s web.xml file. However, this particular web.xml file is used to specify the default properties for all Web applications that are running within this server instance. Be very careful when making modifications to this file (such as any additions or changes) because they affect all Web applications running on the same server instance. Note also that other application servers may or may not support a global default web.xml, as this is not a requirement for Servlet 2.5 standard compliance. It is time to see what default server-wide properties are configured in this web.xml file. First, there is the standard XML header and a reference to the Servlet 2.4 schema (Tomcat 6 is Servlet 2.5 compliant, but as of this writing, the global web.xmluses the Servlet 2.4 schema). Unlike server.xml, web.xml can be formally validated against a schema: The Servlet 2.4 schema provides a significantly more rigorous mechanism for document validation than the DTD used in earlier specifications. Chapter 7 provides a detailed discussion of the Servlet 2.4 and 2.5 schemas. Configuring the Default Servlet for Static Resources In the following definition, a default servlet is specified. This default servlet is used to serve any static resources (static HTML files, GIF files, and so on) within all Web applications, and also to serve directory listings (if it is enabled; see the following listing). In other words, this default servlet provides equivalent capability to a standard Web server. In fact, when using Tomcat in the standalone mode of operation, it is the default servlet that handles static resources. The following segment in the web.xml file configures this default servlet: default

For high quality java hosting services please check tomcat web hosting website.

Chapter 5: Basic Tomcat Confi guration Attribute Description Required? unpackWAR useNaming workdir wrapperClass Default is true. When set to true, Tomcat unarchives the WAR file into the docBase directory before running it. If this is set to false, Tomcat attempts to run the WAR file without first unarchiving it. Default is true. Creates and provides to applications a Java EE JNDI compatible InitialContext for resource lookup. This is required if a Web application uses database connections. See Chapter 13 for more information. Specifies a temporary working directory for servlets (and JSPs) that run within this host. These applications can get the temporary directory via a call to get the javax.servlet.context.tempdir property. If this is not specified, a directory under $CATALINA_HOME/work is used instead. Specifies a wrapper class that implements the org. apache.catalina.Wrapperinterface for wrapping servlets. The default implementation need not be changed in most cases, unless you are developing Tomcat server extensions. No No No No Depending on the application, you may not have to craft a custom to get it deployed. Many applications are designed to run without the need for a custom Context descriptor. The XML subelements that can be placed inside a element are described in the following table. Subelement Description How Many? Loader Manager Realm Resources WatchedResource Configures the class loader used to load classes for a Web application. See Chapter 9 for a thorough examination of class loaders used in Tomcat. Configures the session manager for the context. The session manager creates, manages, and persists server-side sessions. There is typically no need to replace the default implementation unless you are implementing persistent sessions, fail- over, and/or clustering. Chapters 6 and 17 have more information on clustering configurations. A Realm that can be accessed in the Web applications running within this Context. The resource manager used to obtain resources. The default parent container implementation of org.apache.naming .resources.FileDirContext is sufficient. Tells the autodeployer to redeploy the Web application if any of the specified resources have changed. 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1

For high quality java hosting services please check java web hosting website.

Chapter 5: Basic Tomcat Confi guration Attribute Description Required? crossContext docBase override path privileged processTlds reloadable swallowOutput tldNamespaceAware tldValidation unloadDelay Enables cross-Context access when ServletContext .getContext() is called by a Web application. Default is false. You may need to turn this on for suites of Web applications that share information within the same virtual host. The document base path of the Web application running in the Context. This is often called the Context root. If the application is deployed as a WAR file, the document base is, by default, set to webapps/. This path can be set relative to the appBase of the enclosing Host container, or specified as an absolute path. Default is false. This indicates if settings in the local context.xmlshould be allowed to override settings in the DefaultContextspecified with the master server.xml. Specifies the context path of the Web application. If you want the application to be the default application for the specified host, use a path of . In most cases, the default is sufficient. The default is to use the value specified in docBase, the WAR name, or the application Context file name. Default is false. Should be set to true only if you are configuring a system application, such as the manager application. Specifies that TLDs should be processed when the Context starts up. Default is true. Typically no need to change this value. Default is false. Determines if Tomcat should monitor for changes in /WEB-INF/classesand /WEBINF/ lib for every application and reload when the application completes. This is typically used by developers during debugging. Default is false. Determines if any output to System.outor System.err should be captured and displayed in Tomcat s logs. Determines if TLD processing and validation should be namespace-aware. Default is false. Turning this on helps in debugging TLDs, but adversely affects performance. Determines if TLD validation should be performed during processing. Default is false. Turning this on helps in debugging TLDs but adversely affects performance. The number of milliseconds that Tomcat waits for Web applications to unload. The default is 2000. No No No No No No No No No No No

For high quality java hosting services please check java web hosting website.

Chapter 5: Basic Tomcat Confi guration Attribute Description Required? className The Java class that is used to implement the per- application Context. The default is the Tomcatsupplied class org.apache.catalina.core. StandardContext, and does not need to be changed. No allowLinking On Linux and other operating systems that support symbolic links, this allows files to be linked to resources outside the Web application tree. The default value is false. On Windows systems, which do not support symbolic links, make sure this value is false. No antiJARLocking Uses specialized classloaders code to avoid locking up JAR files as much as possible while accessing class information inside the JAR file. Default is false. This No should be turned on only if you experience a JAR file locking problem, such as failure in autodeployment. antiResourceLocking Uses specialized code to avoid file locking as much as possible. Default is false. This option should be left to default unless you experience file locking problems (typically during uninstall or redeployment of application). No backgroundProcessDelay The delay in seconds before the background processing thread is enabled for this host and other nested components. Any nested component with its own backgroundProcessDelayset to a non-negative value will be ignored, indicating that it will manage its own background processing (if any). The default delay is -1, indicating that the parent s background processing thread should be used. No cacheMaxSize Sets the maximum size for the resource cache, in KB. The default is 10240. No cacheTTL Time between attempts to revalidate items in cache, specified in milliseconds. The default is 5000. No cachingAllowed Determines if static resource (config files, images, Web pages, and so on) cache should be turned on. The default is true. No caseSensitive Determines if case sensitivity checks should be performed. Default is true. Leave this on, especially on an operating system with case-insensitive file systems such as Windows. No cookies Uses cookies to track session information from client No access. Cookies are the most universally accepted means to perform session management. Default is true. If you turn this off, application-level URL rewriting is required to maintain session information. Table continued on following page

For high quality java hosting services please check tomcat web hosting website.

Chapter 5: Basic Tomcat Confi guration Subelement Description How Many? DefaultContext Realm The configures the set of property values for a Web application that is deployed within this host but that does not have its own specified. Typically, this is used by Web applications that are automatically deployed. A Realm that can be accessed across all the Web applications running within this host, unless a lower-level component specifies its own Realm. 0 or 1 0 or 1 Web Application Context Definitions In Tomcat 6, administrator-controlled application Context Descriptor XML files are placed in the $CATALINA_HOME/conf// directory. This is done to maximize the decoupling between server and application configuration, and to improve deployment security. Web application specific Context descriptors can be embedded in the WAR file, under META-INF/ context.xml, and included with the Web application being deployed. Administrators can, at their discretion, disable the parsing of these embedded context.xml files on a per-host basis via the deployXML attribute of the host, documented earlier. This concludes the examination of the default server.xml file. The remainder of the chapter examines the other configuration files found in the $CATALINA_HOME/confdirectory. The Default context.xml File The context.xmlin the $CATALINA_HOME/conf directory is the default Context descriptor loaded with every single application running on the Tomcat instance. Because of the global nature of this default Context, it should contain only configuration entries that you need to apply across all Web applications and across all virtual hosts. (The nested component has the same effect, but across all Web applications in a single host.) This default context.xml contains only one line (all comments are removed in the following listing): WEB-INF/web.xml The web.xmlspecified in the nested component is watched by the Context s background processing for changes. Whenever this resource is changed, the application is redeployed by the Tomcat autodeployer (unless this feature is disabled explicitly). A element is a container. It can have any one of the attributes shown in the following table.

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.

Chapter 5: Basic Tomcat Confi guration Attribute Description Required? errorReportValveClass unpackWARs workdir $CATALINA_HOME/conf/// .xml. The default value is true, allowing the processing of the META-INF/context.xmlwithin any web applications deployed on the host. Specifies the Java class that implements the error- reporting Valve used by this host. The default implementation is org.apache.catalina.valves .ErrorReportValve. Set this to false if you want Tomcat 6 to run Web applications without unarchiving the WAR files found at the directory specified by the appBaseattribute. The default is true and Tomcat 6 will unpack these applications. The tradeoff here is typically performance (lower performance when WAR files are not unarchived) versus storage (no need to write to the appBase directory). Specifies a temporary working directory for servlets (and JSPs) that run within this host. These applications can get the temporary directory via a call to get the javax.servlet.context.tempdir property. If this is not specified, a directory under $CATALINA_HOME/ workis used instead. No No Note that there must be at least one entry associated with the element. This makes sense because you must be able to reach the Engine by at least one virtual host name. This means the defaultHostattribute of the element must be assigned with one of the entries. The XML subelements that can be placed inside a element are described in the following table. Subelement Description How Many? Context A can configure a set of property values for a Web application deployed within this host. There can be as many elements as there are Web applications. The default server.xml included with the Tomcat 6 distribution does not include any application Context. This enables a clean separation between server configuration and Web application configuration. Instead, all Web application Contexts can be maintained under the $CATALINA_HOME/conf// directory. In addition, an application can configure its own Context by including a context.xmlfile in the METAINF directory of the Web application WAR. 0 or more Table continued on following page

For high quality jboss hosting services please check jboss web hosting website.

Chapter 5: Basic Tomcat Confi guration In this figure, a single Engine supports three fictitious Web sites via virtual hosts. The first one is foodnuts.com, the second one is buycarsnow.com, and the third one is betterbookends.com . Each virtual host is running a completely different Web application. The Engine is responsible for forwarding any incoming requests to the corresponding host. If the system were to be configured as depicted in the figure, there would be three elements nested within the single definition. A element is a container. It can have any one of the attributes shown in the following table. Attribute Description Required? className appBase autoDeploy name backgroundProcessDelay deployOnStartup deployXML The Java class that is used to handle requests for the host. The default is the Tomcat-supplied class org. apache.catalina.core.StandardHost, and this almost never needs to be changed. Used to set the default application-deployment source directory. Tomcat 6 will look in this directory for applications to be deployed. The path should be specified relative to the installation or per-instance base directory for the Tomcat 6 server. Setting this attribute to true means that Web applications will be automatically deployed or redeployed while Tomcat 6 is running. This includes any new applications placed into the directory specified by appBase (in WAR form or unarchived), any application whose web.xmldeployment descriptor has been modified, and any application whose Context descriptor has been modified. The default value is true. Background processing must be enabled for this to work properly. See deployOnStartupfor auto application deployment during Tomcat startup. The resolvable name of this virtual host. The delay in seconds before the background processing thread is enabled for this host and other nested components. Any nested component with its own backgroundProcessDelayset to a non-negative value will be ignored, indicating that it will manage its own background processing (if any). The default delay is -1, indicating that the parent s background processing thread should be used. When set to true, automatically deploys Web applications from this host during component startup. The default is true. Used primarily in security sensitive installations to restrict the processing of context.xmlembedded within a Web application (usually found in META-INF/ context.xml of the WAR file). If this is set to false, the context configuration needs to be placed under No Yes No Yes No No No

For high quality java hosting services please check tomcat web hosting website.

Chapter 5: Basic Tomcat Confi guration The Host Component After the global UserDatabase Realm component configuration, the next configured component is a Host component. A Host component is a container; it can contain other nested components. The Host component represents a virtual host handled by a Tomcat 6 server instance. A single Tomcat 6 server can contain many virtual hosts. Each virtual host can be considered as a distinct request processing destination. A virtual host is configured as a element within the server.xmlfile. Each element defined within the enclosing element represents another virtual host that is handled by this Engine. In our case, the Host definition is as follows: This defines a virtual host named localhostmatching the defaultHostspecified in the outer container. The applications to be deployed for this virtual host are located under the $CATALINA_ HOME/webapps directory (all the examples from the Tomcat 6 distribution are installed there). In addition, the unpackWARs attribute specifies that if Tomcat 6 finds any WAR files in the appBasedirectory, they will be expanded before the Web application is executed. If you set unpackWARsto false , Tomcat executes the Web applications in place, without unarchiving them saving space but sacrificing performance. The autoDeployattribute is set to true, meaning that Tomcat actively scans for the addition of new Web applications or changes in existing ones, and then automatically deploys, or redeploys, them. See the description of the autoDeploy attribute in the next section for more details. Chapter 15 discusses the techniques used to support virtual hosting. For now, however, Figure 5-2 illustrates the basic concept of virtual hosting. Server Service Engine WebApp1 Restaurant Operations WebApp2 Supply Ordering WebApp1 Car Showroom WebApp2 Leasing WebApp1 Author BBS WebApp2 Book Store Virtual Host 3 (betterbookends.com) Virtual Host 2 (buycarsnow.com) Virtual Host 1 (foodnuts.com) Figure 5-2: Virtual hosting in Tomcat 6

If you looking for unlimited one inclusive web hosting plan please check cheap web hosting website.

Chapter 5: Basic Tomcat Confi guration The Realm Component In the default server.xml file, after the configuration of the Engine component, the next configured nested component inside the Engine is a Realm component: This configures a UserDatabaseRealm to load the tomcat-users.xmlfile into memory for use in authentication by default applications such as the managerapplication. Chapter 14 covers the attributes for the element, including how to specify your own XML file or data source for user authentication information. A Realm is a security mechanism used to perform authentication and implement container- managed security. Essentially, Realms are data sources that provide mappings between usernames and passwords (for authentication), and between usernames and roles that users assume (for container-managed security). For example, user johnf may have password xyzzy (authentication) and a role of supervisor. A Realm can access data sources external to Tomcat 6 where the user/password/role relationships are stored. There are many different implementations of Realms, differing only in the source from which they retrieve the information. Following are several types of Realms that are standard with Tomcat 6: . Memory: Uses a memory-based table that is populated with the user/password/role mappings. Typically, this is read into memory from an XML file during server startup and stays static throughout the lifetime of the server. For the default implementation that comes with Tomcat, the size of the mappings is seriously constrained by the memory available. This is typically used only in testing and development, and seldom in production. . UserDatabase: Implements a completely updateable and persistent memory Realm. It is backwardly compatible with the standard Memory Realm. Chapter 14 provides extensive coverage of UserDatabase. . JDBC: Uses a relational database source for obtaining authentication information. Any other data sources with a JDBC-compatible access interface may also be used (for example, ODBC- compliant sources via the JDBC-to-ODBC bridge). . DataSource: Similar to the JDBC realm, uses JDBC connections to obtain authentication information from a relational database source. However, it configures a lookup-based interface via JNDI when obtaining a JDBC data source for relational database access. This enables the pooling of multiple JDBC connections by the JNDI provider providing more efficient access to the relational database when a Web application performs many authentications at the same time. . JNDI: Uses Java Naming and Directory Interface (JNDI) to access the Realm data. This data is typically stored in an LDAP-based directory, although any authentication system compatible with the LDAP protocol can be used. (For instance, OpenLDAP, Microsoft, or Novell all have LDAP-compatible access drivers.) . JAAS: Works in conjunction with the Java Authentication and Authorization Service (JAAS) to obtaining the authentication and authorization information for the Realm. As mentioned earlier, Chapter 14 provides details about how to configure different Realms.

If you looking for unlimited one inclusive web hosting plan please check cheap web hosting website.