Configuring Tomcat
The Tomcat configuration that comes with Geronimo is a generic arrangement. It is a typical development setup where the connectors listen on port 8080 for HTTP, 8443 for HTTPS utilized with a test Secure Sockets Layer (SSL) certificate, an AJP connector on port 8009, and a JAAS Security Realm that works with the default geronimo-properties-realm security service. This will fit the needs for a majority of developers but will likely need changing when you are ready to move to a production environment. When moving to production, you will likely need to change the security, change the ports that Tomcat will respond to, set up a valid SSL certificate, respond to certain addresses, or implement custom Valves to do specialized logging and other server-specific tasks. Therefore, the server configuration of Tomcat will need to be changed.
Before examining the intricacies of these configuration files, let’s take a look at the Tomcat architecture to help show how the components are put together, which will help define the configuration.
Tomcat Architecture Overview
No matter in which format Tomcat is configured (whether as a standalone server or as a part of Geronimo), its general architecture is the same. Although there are some slight differences between standalone Tomcat and its integration into Geronimo, conceptually they are identical. The main difference in the Tomcat standalone versus Geronimo integration is that some of the Tomcat objects are not needed since other Geronimo services fill the need (such as Naming or Reference declarations). But for the most part, the object hierarchy in both implementations is essentially the same. For the sake of simplicity, this section provides an overview of the portion of the Tomcat architecture that affects the Geronimo integration.
Tomcat components are very object-oriented in nature. Certain objects can contain other types of objects and have a particular hierarchy attached to them, as well as inheritance. For example, in Tomcat, the Server is the top-level object from which everything else becomes a child. In Geronimo, this Server is known as the Container or TomcatContainer. The Container may contain an Engine, and the Engine may have one or more Host objects. Each Host may have multiple Contexts (Web applications). The Container has listeners called Connector objects, which are used to process different kinds of requests. Each Connector can be configured to listen to a particular type of protocol or port (such as HTTP on port 8080, AJP on port 8009, or HTTPS on port 8443). This may seem complicated, but the relationships are clarified visually in Figure 11-2.
Figure 11-2: Tomcat/Geronimo object hierarchy
A more pragmatic way of looking at this is that the Engine object handles the entire server. The Engine can have multiple Hosts. A server would want to have multiple Host objects if it had to implement virtual hosts. For example, one Host object could handle requests to a particular address such as localhost, where another Host object would handle requests to www.wiley.com. This allows a single server to serve multiple Web applications for different Web addresses. To take this a step further, each Host should be able to have multiple Web applications and thus can have multiple Context objects.
The more interesting part of this architecture is the inheritance of the Realm and Valve objects. How the inheritance works for each of these objects is slightly different. The Realm objects are typically used for security and can be applied at the server level (Engine), the Host level, or the Web application (Context) level. If a Realm is not attached at a particular level, then it uses its parent. If the parent does not have one, then the grandparent’s version is used. This allows you to declare security at any level and have the children inherit and use that security. If you want to change it for a particular Host or Context, you can have that level set a Realm and it will be used instead.
The Valves are interceptor objects that allow you to work with the requests and responses before Tomcat (at the different levels) handles them. They are kind of like a deep filter. They are used for things such as specialized logging or click-through analysis, or single-sign-on (SSO). The Valves at the different levels, however, are not replacing parents, but instead are adding on to the parental Valves. Therefore, a company may wish to have all its applications log each request in detail, but a single application use SSO. In this scenario, a logging Valve would be applied at the Engine level, and the SSO Valve would be applied at the Context level. This application would then log its requests and implement SSO.
Having an understanding the Tomcat architecture will help with configuring the Web container, since the setup of the Geronimo configuration files mirror the architecture.
Geronimo Tomcat Configuration
Configuring Tomcat in Geronimo follows a similar paradigm as you would with just Tomcat alone, where you edit XML files to tell the Web container which objects and attributes to use and how to run the server. Tomcat, on its own, primarily uses two XML files for configuration: server.xml for server level and context.xml for Web application level configuration. However, in Geronimo, these files do not exist in the Tomcat format but instead exist in plan configuration XML files as GBeans.
Table 11-1 shows a comparison of Tomcat configuration files with Geronimo equivalents.
| Tomcat File | Geronimo File | Description |
|---|---|---|
| server.xml | Tomcat configuration plan.xml from the source code (or var/config/config.xml for overriding attributes of the preconfigured GBeans) | Provides for configuring the server, such as the Engine, Host, Connectors, Realms, and Valves. |
| context.xml | geronimo-web.xml | Allows configuration of Web-application-level attributes such as context roots, and Web-application-level Valves and Realms. |
Open table as spreadsheetFor those who are familiar with Tomcat’s configuration files, the server.xml file’s equivalent can be found in the source code $GERONIMO_SOURCE_HOME/configs/tomcat/src/plan/plan.xml file. Even without source code access, the configuration in plan.xml can be changed and altered with the GERONIMO_HOME/var/config/config.xml file by adding GBean configurations or overriding GBeans’ attributes. The context.xml file’s equivalent is the geronimo-web.xml file that was discussed in Chapter 10 and later in this chapter. The geronimo-web.xml is a Geronimo-specific deployment plan that is used when deploying your Web application.
If you are changing the server configuration from the Geronimo source code, you only need to edit the $GERONIMO_SOURCE_HOME/configs/tomcat/src/plan/plan.xml file and rebuild the configuration and j2ee-tomcat-server assembly (see Chapter 18 on the companion Web site). Or, if using the binary, you can alter the GERONIMO_HOME/var/config/config.xml and override or shut off GBeans.
Geronimo’s Tomcat plan.xml
In Tomcat’s standalone container, you would configure the server through the server.xml file. This file sets all the major aspects of the Tomcat server and how it runs. This file will allow you to declare your Engine, Connectors, Hosts, Realms, and Valves. It follows the Tomcat architecture exactly as described earlier in this chapter. Listing 11-1 shows a skeleton server.xml file for standalone Tomcat. This file listing is not complete and has most attributes removed to emphasize the structure. Notice how the XML organization mirrors the Tomcat architecture along with the parent/child relationships.
Listing 11-1: Tomcat’s server.xml Skeleton File Layout
 |
<Server> <Service name="Catalina"> <Connector/> <Connector/> <Engine name="Catalina"> <Realm/> <Valve/> <Valve/> <Host> <Realm/> <Valve/> <Valve/> </Host> <Host> </Engine> </Service> </Server> |
In Geronimo, the source code contains the plan.xml file that is the equivalent of the server.xml file. Although you will likely not be using the Geronimo source code, this file is explained here since it is what is ultimately used to create the Tomcat configuration archive (CAR), and it shows the GBeans that you would use to override in the config.xml. You will notice that Geronimo’s Tomcat configuration is based on GBeans and uses GBean wrapper objects in a similar relationship as in Listing 11-1, following the Tomcat architecture.
Although the XML layout is significantly different from the server.xml file, the architecture remains the same. In the plan.xml file, the GBeans use references to other GBeans to show relationships, instead of parent/child XML. They also have attributes to set object specific values. One of the most important attributes on the Tomcat GBeans is the initParams attribute. Since most of the Tomcat GBeans are just wrappers to the actual Tomcat objects, the initParams attribute allows you to set the actual name-value attributes that you would have set in Tomcat’s server.xml. To more clearly show how the initParams attribute works, let’s look at how the Tomcat Host object would be declared in a server.xml file and make note of the attributes (in bold):
<Host name="localhost" appBase="" workDir="work"/> Now, let’s juxtapose this with a Geronimo Host declaration, making note of the initParams attribute.
<gbean name="TomcatHost" > <attribute name="className">org.apache.catalina.core.StandardHost</attribute> <attribute name="initParams"> name=localhost appBase= workDir=work </attribute> </gbean> Notice the attributes of the Host in the server.xml now become name-value pairs in the initParams attribute in the plan.xml. So, it is simple to understand how the Tomcat objects are used with GBeans and configured the Geronimo plan file. Examining the plan.xml file will help you to better understand the relationships between the different Tomcat GBeans and their configurations.
Listing 11-2 shows the snippet from the Tomcat plan.xml as it is represented in the source and what constitutes the Tomcat CAR. Notice that the relationships between the GBeans are represented the same way they would be represented in server.xml.
Listing 11-2: Geronimo’s Tomcat Configuration plan.xml Snippet
|
... <!-- The following is the equivalent of the server.xml file, but done with GBeans --> <!-- The TomcatContainer/Service --> <gbean name="TomcatWebContainer" > <attribute name="catalinaHome">var/catalina</attribute> <reference name="EngineGBean"> <name>TomcatEngine</name> </reference> <reference name="ServerInfo"> <name>ServerInfo</name> </reference> <reference name="WebManager"> <name>TomcatWebManager</name> </reference> </gbean> <gbean name="TomcatWebConnector" > <attribute name="name">HTTP</attribute> <attribute name="host">localhost</attribute> <attribute name="port">8080</attribute> <attribute name="maxHttpHeaderSizeBytes">8192</attribute> <attribute name="maxThreads">150</attribute> <attribute name="minSpareThreads">25</attribute> <attribute name="maxSpareThreads">75</attribute> <attribute name="hostLookupEnabled">false</attribute> <attribute name="redirectPort">8453</attribute> <attribute name="acceptQueueSize">100</attribute> <attribute name="connectionTimeoutMillis">20000</attribute> <attribute name="uploadTimeoutEnabled">false</attribute> <reference name="TomcatContainer"> <name>TomcatWebContainer</name> </reference> </gbean> <gbean name="TomcatAJPConnector" > <attribute name="protocol">AJP</attribute> <attribute name="name">AJP</attribute> <attribute name="host">localhost</attribute> <attribute name="port">8019</attribute> <attribute name="hostLookupEnabled">false</attribute> <attribute name="redirectPort">8453</attribute> <reference name="TomcatContainer"> <name>TomcatWebContainer</name> </reference> </gbean> <!-- SSL support NOTE: If keystoreFile is a relative path, it is relative to GERONIMO_HOME --> <gbean name="TomcatWebSSLConnector" > <attribute name="name">HTTPS</attribute> <attribute name="host">localhost</attribute> <attribute name="port">8453</attribute> <attribute name="maxHttpHeaderSizeBytes">8192</attribute> <attribute name="maxThreads">150</attribute> <attribute name="minSpareThreads">25</attribute> <attribute name="maxSpareThreads">75</attribute> <attribute name="hostLookupEnabled">false</attribute> <attribute name="acceptQueueSize">100</attribute> <attribute name="uploadTimeoutEnabled">false</attribute> <attribute name="clientAuthRequired">false</attribute> <attribute name="algorithm">Default</attribute> <attribute name="secureProtocol">TLS</attribute> <attribute name="keystoreFileName">var/security/keystores/geronimo- default</attribute> <attribute name="keystorePassword">secret</attribute> <reference name="TomcatContainer"> <name>TomcatWebContainer</name> </reference> <reference name="ServerInfo"> <name>ServerInfo</name> </reference> </gbean> <!-- Engine --> <gbean name="TomcatEngine" > <attribute name="className">org.apache.geronimo.tomcat.TomcatEngine</attribute> <attribute name="initParams"> name=Geronimo </attribute> <reference name="DefaultHost"> <name>TomcatHost</name> </reference> <references name="Hosts"> <pattern> <type>Host</type> </pattern> </references> <reference name="RealmGBean"> <name>TomcatJAASRealm</name> </reference> <reference name="TomcatValveChain"> <name>FirstValve</name> </reference> <dependency> <name>TomcatResources</name> </dependency> </gbean> <gbean name="TomcatAccessLogManager" > <reference name="ServerInfo"> <name>ServerInfo</name> </reference> <references name="LogGBeans"> <pattern> <name>FirstValve</name> </pattern> </references> </gbean> <!-- Valve --> <gbean name="FirstValve" > <attribute name="className">org.apache.catalina.valves.AccessLogValve</attribute> <attribute name="initParams"> prefix=localhost_access_log. suffix=.txt pattern=common </attribute> </gbean> <!-- Realm --> <!-- This is an example TomcatJAASRealm --> <gbean name="TomcatJAASRealm" > <attribute name="className">org.apache.geronimo.tomcat.realm.TomcatJAASRealm</attribute> <attribute name="initParams"> userClassNames=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal roleClassNames=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal </attribute> </gbean> <!-- Host --> <gbean name="TomcatHost" > <attribute name="className">org.apache.catalina.core.StandardHost</attribute> <attribute name="initParams"> name=localhost appBase= workDir=work </attribute> </gbean> ... |
You just saw how the Geronimo Tomcat configuration plan.xml file is similar to a server.xml. But in standalone Tomcat, you would edit the server.xml file directly. Although you could edit the source plan file and rebuild the configuration and assembly, this is not necessary to change the Tomcat configuration. You can override the Tomcat configuration through the config.xml. By simply overriding the attributes and references of the GBeans as they are shown in plan.xml in Listing 11-2, you can alter the Tomcat configuration. For example, to add the jvmRoute parameter to the Tomcat Engine (used for clustering), you would add the following:
... <module name="geronimo/tomcat/1.1/car"> ... <gbean name="TomcatEngine"> <attribute name="initParams"> name=Geronimo jvmRoute=node1 </attribute> </gbean> ... </module> ... Here you are adding the jvmRoute to the initParams attribute on the TomcatEngine GBean. You will notice that the name=Geronimo was included here as well. It is important to note that when overriding the initParams attribute, you should declare all of the same items as in plan.xml for the GBean. This is because the initParams attribute is actually a single attribute, and you are adding the list of Tomcat-specific settings to this attribute. Thus, as you omit a setting, it will not be configured.
In another example, you may not want Geronimo to use the SSL connector for Tomcat. Setting the load="false" attribute for the TomcatWebSSLConnector will prevent it from attaching to the container and running.
... <module name="geronimo/tomcat/1.1/car"> ... <gbean name="TomcatWebSSLConnector" load="false"/> ... </module> ... Also, to add a new GBean, you would simply declare the GBean in the configuration. For example, to add a new connector named MyNewHTTPListener that will listen on port 9090, your config.xml would contain the following:
... <module name="geronimo/tomcat/1.1/car"> ... <gbean name="geronimo/tomcat/1.1/car?ServiceModule=geronimo/tomcat/1.1/car,j2eeType=GBean, name=TomcatWebConnector-HTTP-MyNewHTTPListener" gbeanInfo="org.apache.geronimo.tomcat.ConnectorGBean"> <attribute name="protocol">HTTP</attribute> <attribute name="host">0.0.0.0</attribute> <attribute name="port">9090</attribute> <attribute name="name">MyNewHTTPListener</attribute> <reference name="TomcatContainer"> <pattern> <groupId>geronimo</groupId> <artifactId>tomcat</artifactId> <version>1.1</version> <type>car</type> <name>TomcatWebContainer</name> </pattern> </reference> </gbean> ... </module> ... In this example, the required attributes for the GBean are declared with the necessary values. Notice that when declaring a new GBean, the name must be fully qualified for the naming conventions for a JSR-88 naming convention. This includes the domain name (usually geronimo.server), followed by a “:”, then the Application (null if not part of an application), Module (usually the tomcat CAR), J2EEServer (usually geronimo), j2eeType, and the unique name of the module. The gbeanInfo represents the Java object that is being used, and the attributes and references are those that are defined for the GBean Java object. In this example, it is using the ConnectorGBean.
Hence, you are able override, remove or add GBeans to alter your Tomcat configuration through the config.xml file. Table 11-2 shows a complete listing of each of the Tomcat GBean objects, along with their attributes and references.
| GBean Object/Description | Type | Name | Req | Description |
|---|---|---|---|---|
| TomcatContainer | ||||
| The Tomcat container that provides for the central integration of Tomcat into Geronimo. | ||||
| A | catalinaHome | No | Tells the Web container where it can find the configuration files. Defaults to $GERONIMO_HOME/var/catalina. Recommended that it not be changed. | |
| R | EngineGBean | Yes | Refers to the name of an EngineGBean. | |
| R | ServerInfo | Yes | Reference to a ServerInfo GBean. | |
| ConnectorGBean | ||||
| GBean that wraps the Tomcat Connector object. Allowed for HTTP and AJP type connectors. May declare multiple connectors per container. | ||||
| A | name | Yes | A unique name to identify this connector. | |
| A | protocol | No | The protocol of this connector. May be HTTP or AJP. Defaults to HTTP if not declared. | |
| A | host | No | Which IP address to listen on. If set to 0.0.0.0, then it will listen on all IP addresses. Defaults to 0.0.0.0. | |
| A | port | Yes | Declares which port to listen on. | |
| A | maxHttpHeader SizeBytes | No | The maximum size of an HTTP header request in bytes. Defaults to 4096. | |
| A | maxThreads | No | Maximum number of threads or concurrent requests. Defaults to 200. | |
| A | maxPostSize | No | Maximum size the connector will accept from a POST operation. Defaults to 2097152 (2MB). May be disabled if the value is less than or equal to 0. | |
| A | maxSavePostSize | No | Maximum size the connector will accept from a POST operation that will be buffered by form or client-certificate authentication. Defaults to 4096K. May be disabled with a −1 as the value. | |
| A | minSpareThreads | No | Number of thread created upon starting the connector. This value should be smaller then the maxThreads attribute. Defaults to 4. | |
| A | maxSpareThreads | No | Number of threads in the pool that are unused. Defaults to 50. | |
| A | hostLookup Enabled | No | Forces a DNS lookup when dealing with IP addresses internally. Defaults to False. | |
| A | redirectPort | No | Will redirect to the same URL but on the declared port to an SSL connector if the web.xml has a security constraint requiring SSL. Defaults to False. | |
| A | acceptQueueSize | No | Maximum size of queue to accept requests before refusing connections. Default is 10. | |
| A | connection TimeoutMillis | No | Amount of time in milliseconds to wait for the HTTP request to occur before timing out. Default is 60000. | |
| A | uploadTimeout Enabled | No | Allows a longer timeout for uploading data. Defaults to True. | |
| A | lingerMillis | No | Length of time in milliseconds the sockets will linger. Defaults to -1 (disabled). | |
| A | tcpNoDelay | No | Sets the TCP_NO_DELAY on the sockets. Defaults to True. | |
| A | bufferSizeBytes | No | The input stream buffer-size in bytes. Defaults to 2048. | |
| A | connectUrl | No | Read-only. Returns a string displaying the connector URL. | |
| R | TomcatContainer | Yes | Named reference to the TomcatContainer GBean. | |
| HttpsConnectorGBean | ||||
| GBean that wraps the Tomcat Connector object for HTTPS type connectors. Allowed for only HTTPS type connectors and is used primarily for SSL. May declare multiple connectors per container. | ||||
| A | name | Yes | A unique name to identify this connector. | |
| A | protocol | No | The protocol of this connector. May be HTTP or AJP. Defaults to HTTP if not declared. | |
| A | host | No | Which IP address to listen on. If set to 0.0.0.0, then it will listen on all IP addresses. Defaults to 0.0.0.0. | |
| A | port | Yes | Declares which port to listen on. | |
| A | keystoreFileName | No | The path and filename of the keystore file. Relative paths will be relative to $GERONIMO_HOME. Defaults to use the .keystore in the user who is running Geronimo’s home directory. | |
| A | keystorePassword | No | The password of the server certificate that is stored in the keystore file. Defaults to "changeit". | |
| A | keystoreType | No | The type of keystore file used. Defaults to JKS. | |
| A | truststore FileName | No | The path and filename of the truststore file. Relative paths will be relative to $GERONIMO_HOME. | |
| A | truststore Password | No | The password of the truststore file. | |
| A | truststoreType | No | The type of truststore file used. Defaults to JKS. | |
| A | algorithm | No | Encoding algorithm. Defaults to SunX509. | |
| A | secureProtocol | No | SSL Protocol used. Defaults to Transport Layer Security (TLS). | |
| A | clientAuth Required | No | Requires that all SSL connections contain a valid client-side certificate chain. Defaults to False. | |
| A | maxHttpHeader SizeBytes | No | The maximum size of an HTTP header request in bytes. Defaults to 4096. | |
| A | maxPostSize | No | Maximum size the connector will accept from a POST operation. Defaults to 2097152 (2MB). May be disabled if the value is less than or equal to 0. | |
| A | maxSavePostSize | No | Maximum size the connector will accept from a POST operation that will be buffered by form or client-certificate authentication. Defaults to 4096K. May be disabled with a −1 as the value. | |
| A | maxThreads | No | Maximum number of threads or concurrent requests. Defaults to 200. | |
| A | minSpareThreads | No | Number of threads created upon starting the connector. This value should be smaller then the maxThreads attribute. Defaults to 4. | |
| A | maxSpareThreads | No | Number of threads in the pool that are unused. Defaults to 50. | |
| A | hostLookupEnabled | No | Forces a DNS lookup when dealing with IP addresses internally. Defaults to False. | |
| A | redirectPort | No | Will redirect to the same URL, but on the declared port to an SSL connector if the web.xml has a security-constraint requiring SSL. Defaults to False. | |
| A | acceptQueueSize | No | Maximum size of queue to accept requests before refusing connections. Default is 10. | |
| A | connection TimeoutMillis | No | Amount of time in milliseconds to wait for the HTTP request to occur before timing out. Default is 60000. | |
| A | uploadTimeout Enabled | No | Allows a longer timeout for uploading data. Defaults to True. | |
| A | lingerMillis | No | Length of time in milliseconds the sockets will linger. Defaults to -1 (disabled). | |
| A | tcpNoDelay | No | Sets the TCP_NO_DELAY on the sockets. Defaults to True. | |
| A | bufferSizeBytes | No | The input stream buffer-size in bytes. Defaults to 2048. | |
| A | connectUrl | No | Read-only. Returns a string displaying the connector URL. | |
| R | TomcatContainer | Yes | Named reference to the TomcatContainer GBean. | |
| R | ServerInfo | Yes | Reference to a ServerInfo GBean. | |
| EngineGbean | ||||
| Wrapper for a Tomcat Engine object. It will typically wrap a TomcatEngine object, as declared by the className attribute, which is an extension of the Tomcat org.apache.catalina.core.StandardEngine. | ||||
| A | className | Yes | A string representation of the underlying Tomcat Engine object. It is highly recommended to only use the org.apache.geronimo.tomcat.Tomcat-Engine object since it supports several functions in Geronimo. | |
| A | initParams | Yes | Name-value pair list for attributes specific to the Engine object as described by the className. Each of the name-value parameters are separated by an ‘=’ sign. Should have the name and default Host name-values set. The name value should match a GeronimoSecurityRealm GBean’s realmName attribute to allow security at the Engine level. See the Jakarta Tomcat documentation for a list of specific parameters for the Engine object. | |
| R | DefaultHost | Yes | The name of the HostGBean that represents the default host of the container. | |
| R | Hosts | Yes | Tells the EngineGbean the naming convention of the HostGbeans. This parameter is set as geronimo.server:j2eeType=Host,* and typically should not be changed. Although this is not a required attribute, the EngineGBean will not find HostGBean objects without it, so it is highly recommended. | |
| R | RealmGBean | No | Reference to a RealmGbean that will be applied at the Engine level and normally will cover security for the entire Tomcat container. | |
| R | TomcatValveChain | No | Reference to the first Valve in a chain of 1 or more valves that will be applied at the Engine level. | |
| R | CatalinaCluster | No | Reference to a Catalina-ClusterGBean that will provide for clustering the TomcatContainer. Clustering GBeans are beyond the scope of this chapter. | |
| R | Manager | No | Reference to the name of a ManagerGBean or object extending the ManagerGBean. Used for swapping out the session manager for Tomcat. | |
| HostGBean | ||||
| Wrapper for a Tomcat Host object. It will typically wrap a org.apache.catalina.core.StandardHost object, as declared by the className attribute. Multiple HostGbean objects may be declared and each HostGBean will represent a virtual host as defined by the initParams attribute’s name value. | ||||
| A | className | Yes | A string representation of the underlying Tomcat Host object. It is highly recommended to only use the org.apache.catalina.core.StandardHost object or one that is derived from it. | |
| A | initParams | Yes | Name-value pair list for attributes specific to the object as described by the className. Each of the name-value parameters is separated by an ‘=’ sign. Should have the name value set. The name value is a valid network name such as localhost or www.example.com. Keep in mind that a GeronimoSecurityRealm GBean’s realmName attribute should match the name value to allow security at the Host level. See the Jakarta Tomcat documentation for a list of specific parameters for the Host object. | |
| A | aliases | No | Comma-delimited list of network aliases that this host will respond to. | |
| R | RealmGBean | No | Reference to a RealmGbean that will be applied at the Host level and normally will cover security for the contexts that are under the host. Leaving this blank will default the host to inherit the Engine’s security. | |
| R | TomcatValveChain | No | Reference to the first Valve in a chain of 1 or more valves that will be applied at the Host level. This will add on to the chain of any Valves that were declared at the Engine level. | |
| R | CatalinaCluster | No | Reference to a Catalina-ClusterGBean that will provide for clustering the TomcatContainer. Clustering GBeans are beyond the scope of this chapter. | |
| R | Manager | No | Reference to the name of a ManagerGBean or object extending the ManagerGBean. Used for swapping out the session manager for Tomcat. | |
| ManagerGBean | ||||
| GBean wrapper for Tomcat Manager objects. The manager objects allow for changing the session manager for the Tomcat container. | ||||
| A | className | Yes | A string representation of the underlying Tomcat Manager object. The class name should reference an object that implements the org.apache.catalina.Manager interface. | |
| A | initParams | No | Name-value-pair list for attributes specific to the object as described by the className. The name-value parameters are separated by an ‘=’ sign. | |
| RealmGBean | ||||
| GBean wrapper for Tomcat Realm objects. May only have one Realm at the Engine and Host levels (or Context within the geronimo-web.xml or equivalent plan file). | ||||
| A | className | Yes | A String representation of the underlying Tomcat Realm object. The class name should reference an object that implements the org.apache.catalina.Realm interface. | |
| A | initParams | No | Name-value-pair list for attributes specific to the object as described by the className. The name-value parameters are separated by an ‘=’ sign. | |
| ValveGBean | ||||
| GBean wrapper for Tomcat Valve objects. May have multiple Valve objects by chaining them together at the Engine and Host levels (or Context within the geronimo-web.xml or equivalent plan file). Chaining Valves will store and execute them in the order of the chain. | ||||
| A | className | Yes | A string representation of the underlying Tomcat Valve object. The class name should reference an object that implements the org.apache.catalina.Valve interface. | |
| A | initParams | No | Name-value-pair list for attributes specific to the object as described by the className. The name-value parameters are separated by an ‘=’ sign. | |
| R | NextValve | No | Reference to the next ValveGBean in the chain. If this reference attribute is not included, then this GBean is the final Valve in the chain. | |
| Legend Type: (A) – Attribute, (R) – Reference to GBean Req: (Yes) – parameter is required, (No) – not required | ||||
Adding and removing the GBeans, and changing references and attributes as listed in Table 11-2, you can change the configuration to do things such as add virtual hosts, set up a proper SSL certificate, and add Valves and Realms. The following sections examine some of the GBean configurations that are commonly altered when setting up Tomcat.
Connectors
The ConnectorGBean and HttpsConnectorGBean GBean objects are wrappers around the Tomcat Connector object that allow the Web container to provide and accept connections from clients. They have the first line of control in the communication protocol, and control which port and address to listen on, connection thread pool management, and many other capabilities. Geronimo comes with three connectors already preconfigured: HTTP, AJP, and HTTPS. The HTTP connector is for use with the HTTP protocol and listens on port 8080. The AJP connector is for using Geronimo with a Web server such as Microsoft IIS or the Apache HTTPS server and uses port 8090. The HTTPS connector is for SSL communications and uses port 8443. Listing 11-3 shows the three connectors as they might be declared in the config.xml file.
Listing 11-3: Example Connector Configurations
|
... <module name="geronimo/tomcat/1.1/car"> ... <!-- HTTP Connector --> <gbean name="TomcatWebConnector"> <attribute name="host">0.0.0.0</attribute> <attribute name="port">8080</attribute> </gbean> <!-- AJP Connector --> <gbean name="TomcatAJPConnector"> <attribute name="host">0.0.0.0</attribute> <attribute name="port">8009</attribute> </gbean> <!-- HTTPS Connector --> <gbean name="TomcatWebSSLConnector"> <attribute name="host">0.0.0.0</attribute> <attribute name="port">8443</attribute> <attribute name="keystoreFileName"> var/security/keystores/geronimo-default </attribute> <attribute name="keystorePassword">secret</attribute> </gbean> ... </module> ... |
This shows the override of the already configured Tomcat GBeans. You may also add connectors manually through the config.xml as shown earlier in this chapter. The simplest way to add a connector is through the Web console, as was shown in Chapter 10. There is no limit to the number of connectors you can add. The only limitation is ensuring that each of the connectors listens on a different host address and port combination and that they are named uniquely. The ConnectorGBean is used for any kind of protocol that is not secure, such as HTTP and AJP. The HttpsConnectorGBean is used only for the HTTPS protocol. Table 11-2 provides a complete listing of all the attributes and attributes for the connector GBeans.
Secure Socket Layer (SSL) Connector
Geronimo’s Tomcat container comes with a preconfigured HttpsConnectorGBean to use with the SSL protocol. This GBean uses a test certificate located at $GERONIMO_HOME/ var/security/keystores/ geronimo-default with the password “secret.” This should only be used for development and test only. If Geronimo is to be used in a production environment, this configuration should be changed. Altering this configuration is simple, because it only requires editing the keystoreFileName and keystorePassword attributes for the TomcatWebSSLConnector GBean, as shown earlier. The keystoreFileName attribute should point to the new keystore path and file. Using a relative path to the file will be relative to $GERONIMO_HOME, and using a full path for this attribute will allow you to place your keystore file in any location.
Virtual Hosts
Virtual hosts provide the capability to have a single server answer to different Web addresses, without having to give out a new IP address to each new host. Each host will examine the request and look at the address of the URL, to see if it needs to handle that request. For example, let’s assume a configuration where a single server will support two companies: www.example.com, and localhost (all others). We want a certain Web application to respond to URLs that contain www.example.com, www.example.net, www.example.org, and all others to go to the default localhost. localhost does not need alteration and is already configured properly in Geronimo’s Tomcat CAR plan.xml file. To enable a virtual host, the first thing that must be done is to verify that a DNS entry will resolve to the name and the IP address of your server. This chapter will not cover how to set up DNS, but the important thing to remember is that the DNS must resolve to the address. The second thing that must be done is to enable a virtual host is to add a HostGBean in the config.xml file, as shown in Listing 11-4.
Listing 11-4: Geronimo’s HostGBean Example Declaration
|
... <module name="geronimo/tomcat/1.1/car"> ... <gbean name="geronimo/tomcat/1.1/car?ServiceModule=geronimo/tomcat/1.1/car,j 2eeType=Host,name=TomcatSecondHost" gbeanInfo="org.apache.geronimo.tomcat.HostGBean"> <attribute name="className">org.apache.catalina.core.StandardHost</attribute> <attribute name="initParams"> name=www.example.com appBase= workDir=work</attribute> <attribute name="aliases">www.example.net,www.example.org</attribute> </gbean> ... </module> ... |
When adding a new HostGBean, the GBean’s name should be unique, as is the case with the example host’s GBean named TomcatSecondHost. The name value of the initParams attribute should contain one of the network names for this host to respond to. In this example, it is www.example.com. Since this host should also respond to www.example.net and www.example.org, these are added to the aliases attribute and should be comma-delimited.
This handles only the server side of the configuration of a virtual host. To deploy an application to a specific host, you must name the virtual host in the geronimo-web.xml deployment plan for that application, using a host element declaration. If this is not declared, then the Web application will be deployed to the default host. This will be covered later in this chapter.
Valves
Valves are what are known as deep Web filters that can cover an entire server, host, or individual application. Their value comes from having the ability to intercept the Web request and response before they get to the application, and/or process the request after the application’s servlets. They can provide click-through tracking, specialized logging, security functions, and much more. There are many uses for valves, and they can be applied at the Engine, Host, and Context (the Web application) levels. The valves are stackable, in that valves that are declared at the Engine level will run in addition to those declared at the Host and Context levels. Each valve declared at its level will run for any child level underneath the parent.
Geronimo configures Valves by declaring them in a valve GBean chain. The EngineGBean and HostGBeans have references called TomcatValveChain that will refer to the first Valve GBean that is part of a chain. If there is more than one Valve, the first Valve will contain a reference called NextValve that names the next Valve. This is where the chain concept comes from. You continue to add Valves on to the end of the chain. The last Valve will not have a NextValve declaration and thus is the end of the chain. Each of the Valves is added to the chain in the declaration order, so you can be sure that certain Valves can run before others.
Listing 11-5 shows an example where a HostGBean configures a Valve chain. It has its TomcatValveChain reference the FirstValve, then uses the NextValve reference to refer to the SecondValve. The SecondValve has no NextValve reference, so it is the last Valve in the chain. In this example, any Web applications that are a part of this host will run the AccessLogValve, then the SingleSignOn Valve before the requests or responses by those applications. Each of the ValveGBean objects may also use the initParams attribute to set any specific properties for the Valve declared in the className attribute.
Listing 11-5: Example Host and Valve Chain Declaration
|
... <module name="geronimo/tomcat/1.1/car"> ... <gbean name="TomcatHost"> <attribute name="className">org.apache.catalina.core.StandardHost</attribute> <reference name="TomcatValveChain"> <pattern> <groupId>geronimo</groupId> <artifactId>tomcat</artifactId> <version>1.1</version> <type>car</type> <name>FirstValve</name> </pattern> </reference> </gbean> <gbean name=" geronimo/tomcat/1.1/car?ServiceModule=geronimo/tomcat/1.1/car,j2eeType=Tomcat Valve,name=FirstValve" gbeanInfo="org.apache.geronimo.tomcat.ValveGBean"> <attribute name="className"> org.apache.catalina.valves.AccessLogValve </attribute> <attribute name="initParams"> prefix=localhost_access_log. suffix=.txt pattern=common </attribute> <reference name="NextValve"> <pattern> <groupId>geronimo</groupId> <artifactId>tomcat</artifactId> <version>1.1</version> <type>car</type> <name>SecondValve</name> </pattern> </reference> </gbean> <gbean name=" geronimo/tomcat/1.1/car?ServiceModule=geronimo/tomcat/1.1/car,j2eeType=Tomcat Valve,name=SecondValve" gbeanInfo="org.apache.geronimo.tomcat.ValveGBean"> <attribute name="className"> org.apache.catalina.authenticator.SingleSignOn </attribute> </gbean> ... </module> ... |
Tomcat Realms
Tomcat Realms are different from the security Realms as described in Chapter 15. Tomcat Realms connect the Tomcat Web container to outside security implementations. They offer the ability to apply security with respect to users and roles to your Web applications. Each of the Realm objects has some capability to use a database, memory store, or other type of ability to provide user/role authentication. Only one Realm may be declared at each of the levels and may be applied to an EngineGBean, HostGBean, or referenced in a geronimo-web.xml file for the context/Web application level. Realm declarations differ from the Valves in that child declarations override the parent’s declaration for that level. The Engine level declaration will cover security for the entire server. The Host-level declaration will cover security for all contexts/Web applications that fall under that host. Context-level declaration will only apply to that Web application. At any point in the hierarchy that new declaration occurs, that Realm will override and be the default security for all children beneath it.
Tomcat comes with a number of Realms (such as the JDBCRealm, DataSourceRealm, JNDIRealm, and MemoryRealm) that typically are used in a standalone Tomcat implementation. Although these Realms can be used in Geronimo, they are not as useful as leveraging the Geronimo container-managed security. Geronimo comes with two Realm objects that make use of container-managed security:
-
TomcatJAASRealm for Java Authentication and Authorization Service (JAAS)
-
TomcatGeronimoRealm for Java Authorization Contract for Containers (JACC).
The actual Geronimo security implementation will be discussed in detail in Chapter 15. One of the important characteristics when using either of these Geronimo Realms is how the tie between the Geronimo security service and the Realm occurs. The EngineGBean and HostGBean objects require that the initParams attribute contain a name value. This name should match the realmName attribute of a GenericSecurityRealm or the applicationConfigName attribute of the ServerConfigurationEntry (see Chapter 15 for Geronimo Realm discussion). This tie is how Tomcat’s Realms can resolve the Geronimo security Realm to attach to when attaching the security at the Engine and Host levels. This means that you should name your GenericSecurityRealm GBean’s realmName or Server ConfigurationEntry GBean’s applicationConfigName with the same name as your EngineGBean object’s logical name if you apply the Realm at the Engine level, or the network name of your HostGBean if you apply the Realm at the Host level.
Listing 11-6 shows an example RealmGBean configuring a TomcatJAASRealm that is attached to an EngineGBean. The relationships are shown in bold. Notice that the EngineGBean has a reference to the TomcatJAASRealm. But the EngineGBean also is named Geronimo in its initParams attribute’s name value. That value matches the ServerConfigurationEntry GBean’s applicationConfigName attribute. How the security works and its configuration will be covered in Chapter 15, but it is important to understand how the Tomcat Realms tie to the security depending on what level they are declared at.
Listing 11-6: Example JAAS Realm Configuration for an EngineGBean
|
... <module name="geronimo/tomcat/1.1/car"> ... <!-- JAAS Geronimo Login Configuration --> <gbean name="geronimo/tomcat/1.1/car?ServiceModule=geronimo/tomcat/1.1/car,j2eeType=Config urationEntry,name=tomcat-properties" gbeanInfo="org.apache.geronimo.security.jaas.ServerRealmConfigurationEntry"> <attribute name="applicationConfigName">Geronimo</attribute> <attribute name="realmName">geronimo-properties-realm</attribute> <reference name="LoginService"> <pattern> <groupId>geronimo</groupId> <artifactId>j2ee-security</artifactId> <version>1.1</version> <type>car</type> <name>JaasLoginService</name> </pattern> </reference> </gbean> <!-- Engine --> <gbean name="TomcatEngine"> <attribute name="initParams"> name=Geronimo </attribute> <reference name="RealmGBean"> <pattern> <groupId>geronimo</groupId> <artifactId>tomcat</artifactId> <version>1.1</version> <type>car</type> <name>TomcatJAASRealm</name> </pattern> </reference> </gbean> <!-- Tomcat Realm --> <gbean name="geronimo/tomcat/1.1/car?ServiceModule=geronimo/tomcat/1.1/car,j2eeType=GBean, name=TomcatJAASRealm" gbeanInfo="org.apache.geronimo.tomcat.RealmGBean"> <attribute name="className">org.apache.geronimo.tomcat.realm.TomcatJAASRealm </attribute> <attribute name="initParams"> userClassNames=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal roleClassNames=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal </attribute> </gbean> ... </module> |
The Context level declaration of Tomcat Realms is handled much differently, and it occurs in the geroimo-web.xml but does not tie with a name attribute. There is a decision tree the Tomcat container uses to attach a Tomcat Realm to the Web application because it looks at a number of factors for deciding which Tomcat Realm to attach to your Web application. The key components that help decide the correct Tomcat Realm to use are the <tomcat-realm> element, which is the name of a Tomcat Realm GBean, the <security-realm-name> element that contains the actual Geronimo configuration entry Realm name, and the security block elements. These elements will be covered in the next section, but for the purpose of understanding the decision mechanism, the following factors will decide the Tomcat Realm used:
-
If a <tomcat-realm> and <security-realm-name> elements are declared in the geronimo-web.xml plan file, it will set the Tomcat Realm to the value of the <tomcat-realm> element, and the Geronimo configuration entry Realm will be referenced by the <security-realm-name> element.
-
If a <tomcat-realm> is declared in the geronimo-web.xml plan file, but not a <security-realm-name> element, it will set the Tomcat Realm to the value of the <tomcat-realm> element, but will look for a Geronimo configuration entry Realm that is named with the context root of the application. Hence, if the application is referenced with the URL /foobar as its servlet context path, then foobar will be the link to the GenericSecurityRealm GBean’s realmName attribute or ServerConfigurationEntry GBean’s applicationConfigName attribute.
-
If a <security-realm-name> is declared in the geronimo-web.xml plan file along with a security block, but not a <tomcat-realm> element, a TomcatGeronimoRealm will be attached to the Web application using the <security-realm-name> element’s value to attach to a Geronimo configuration entry Realm. Since no Tomcat Realm is declared, along with the security block’s presence, Geronimo assumes that JACC will be used.
-
If a <security-realm-name> is declared in the geronimo-web.xml plan file, without a security block and <tomcat-realm> element, a TomcatJAASRealm will be attached to the Web application using the <security-realm-name> element’s value to attach to a Geronimo configuration entry Realm. Since no Tomcat Realm is declared, and there is no security block, Geronimo assumes basic JAAS will be used.
-
If neither a <security-realm-name> nor <tomcat-realm> elements are declared in the geronimo-web.xml plan file, it will use the Tomcat Realm that is configured for the Host or Engine. It will accept the Realm that it finds first, starting with the Host as the immediate parent. In a default Geronimo configuration, this usually means a TomcatJAASRealm will be attached to the context.
Keep in mind that the existence of a Tomcat Realm in a plan does not mean it will be used by your Web application, unless you instruct your Web application to use the Realm with the web.xml deployment descriptors. So, it is safe to say that nearly every one of your Web applications will have a Tomcat Realm attached to it in one form or another. This will be covered in more detail in Chapter 15.
Context Level Configuration - geronimo-web.xml
The Servlet 2.4 specification describes a generic configuration of a Web application that allows the Web application to be portable across containers through the use of the web.xml. This means a packaged WAR file would theoretically be able to be deployed on nearly any application server or Web container without any need to change the configuration or code. However, each application server typically has additional options that can enhance the power of the application through the use of a proprietary configuration file. In standalone Tomcat, proprietary configuration is found in the context.xml file. The context.xml is a container-specific descriptor that allows additional configuration for your Web application that is particular only to standalone Tomcat. The context.xml file allows configuration such as the context path, as well as the ability to configure Valves and Realms, and other objects at the context level. Geronimo does not use this file but instead has its own equivalent proprietary configuration file; the geronimo-web.xml file. This file was covered in detail in Chapter 10, but this section will concentrate on the areas that affect Tomcat.
Many of the settings found in a server.xml and context.xml file are not appropriate for use in an application server. Geronimo handles many issues (such as deployment, application locations) and many other aspects that are set outside of Tomcat. It is for this reason that you may find certain Tomcat attributes or settings nonexistent or ignored in the Geronimo configuration.
Web Deployment Descriptor Namespace Review
Chapter 10 covered the fact that Geronimo allows for three types of geronimo-web.xml files that are controlled by the namespace declaration in the top of the plan file; generic, Jetty, and Tomcat. To review, the generic namespace may contain container-specific elements with a <container-config> and a reference to a container-specific namespace, as shown by the following:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1" xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1" > <sys:environment> <sys:moduleId>wrox/exampleapp/1.0/car</sys:moduleId> <sys:dependencies> <sys:dependency> <sys:moduleId>geronimo/j2ee-server/1.1/car</sys:moduleId> </sys:dependency> </sys:dependencies> </sys:environment> ... <!-- Container specific configuration --> <container-config> <!-- Tomcat Specific Container Declarations --> <tomcat xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0/config"> <valve-chain>FirstValve</valve-chain> <host>www.example.com</host> <cross-context/> </tomcat> </container-config> ... </web-app> You will typically use the generic namespace when you want your Web applications to be deployable to both the Tomcat and Jetty containers. However, most users will likely use and support a single container. The Geronimo container-specific Web deployment descriptor should be used in these situations. The difference between the generic and container specific deployment descriptors is that there is no need for a <container-config> and a <tomcat>/<jetty> element, and the container-specific elements then become a first-class citizen element of the geronimo-web.xml plan. To use a Tomcat-specific Web deployment descriptor, you would declare the following namespace in the <web-app> element:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://Geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1" xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1" > <sys:environment> <sys:moduleId>wrox/exampleapp/1.0/car</sys:moduleId> <sys:dependencies> <sys:dependency> <sys:moduleId>geronimo/j2ee-server/1.1/car</sys:moduleId> </sys:dependency> </sys:dependencies> </sys:environment> ... <!-– Container specific tags are first class citizen tags here --> <valve-chain>FirstValve</valve-chain> <host>www.example.com</host> <cross-context/> ... </web-app>
Tomcat-Specific Web Descriptor Tags
The Tomcat standalone container’s context.xml file provides the ability to set configurations beyond the servlet specification, such as to set the context’s path, or the base URL of the application with the path attribute. It allows you to set Tomcat Realms, Valves, the Manager, clustering, and other options. To support the pluggability of these objects to your Web application, Geronimo has a set of Tomcat-only elements in the geronimo-web.xml Web descriptor plan.
Table 11-3 lists the Tomcat-specific elements that are available, as well as a description of their use.
| Tomcat-Specific Elements | Description |
|---|---|
| host | Which virtual host to apply to this context. This value must match one of the HostGBean object’s initParams attribute name value. |
| cross-context | If this element exists, it allows your Web application’s servlet context to be accessible by other Web applications. This is used heavily with portlet applications because of heavy interactions between portlets. |
| disable-cookies | If this element exists, it will disable cookies from being used for the Web application. |
| valve-chain | Reference to the first ValveGBean in a valve chain. Valves will be added to any other parent valves for this context only. |
| tomcat-realm | Reference to the name of a RealmGBean. Applies the Realm at this context only. Should only be used when using a custom Tomcat Realm, because Geronimo will choose the proper Realm to use based upon the configuration. |
| manager | Reference to the name of a ManagerGBean or GBean that extends the ManagerGBean object, Allows you to swap out the session manager for Tomcat. |
| cluster | Reference to the name of a CatalinaClusterGBean to enable clustering for Tomcat. Clustering GBeans are beyond the scope of this chapter. |
Table 11-3 lists the elements in the order that they should appear when used in your Geronimo Web descriptor plan file. For a Tomcat container Web descriptor, these elements will come after the Web descriptor’s <context-root> and before the naming element block. These are based on a sequence for the Web descriptors for Geronimo. The entire XSDs for the geronimo-tomcat-1.1.xsd (Tomcat) and geronimo-tomcat-config-1.0.xsd (for using Tomcat-specific elements in a generic Web descriptor) are found in the Geronimo /schema directory.
One area to make note of is the <valve-chain>, <tomcat-realm>, <manager>, and <cluster> elements. These elements refer to a GBean that you can declare in the Web descriptor. Therefore, you can declare GBeans that are used only at the Web context level, since the GBeans can be declared directly in the geronimo-web.xml file.
Listing 11-7 shows an example geronimo-web.xml file that contains settings for a Web application called foobar. The namespace uses the Tomcat version to tell the deployer it will be deploying a Web application that contains a Tomcat-specific configuration. The <context-root> specifies the /foobar URL that will become the context of this application.
Listing 11-7: Example geronimo-web.xml with Tomcat-Specific Attributes and GBeans
|
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1" xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1" > <sys:environment> <sys:moduleId>wrox/exampleapp/1.0/car</sys:moduleId> <sys:dependencies> <sys:dependency> <sys:moduleId>geronimo/j2ee-server/1.1/car</sys:moduleId> </sys:dependency> </sys:dependencies> </sys:environment> <!-- Web Parameters --> <context-root>/foobar</context-root> <security-realm-name>geronimo-properties-realm</security-realm-name> <!-- Container configuration --> <host>www.example.com</host> <valve-chain>ContextValve</valve-chain> <tomcat-realm>ContextJAASRealm</tomcat-realm> <!-- Additional GBean configuration --> <gbean name="ContextJAASRealm" > <attribute name="className">org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm </attribute> <attribute name="initParams"> userClassNames=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal roleClassNames=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal </attribute> </gbean> <gbean name="ContextValve" > <attribute name="className">org.apache.catalina.authenticator.SingleSignOn</attribute> </gbean> </web-app> |
The <tomcat-realm> references the ContextJAASRealm GBean and the <valve-chain> references the ContextValve as the Valve chain for this context. The <host> references www.example.com, which is the name of a parent HostGBean that would be declared in the config.xml file. So, just like standalone Tomcat’s context.xml, you can set Tomcat objects at the Web application or context level.
EAN: 2147483647
Pages: 148