Tomcat

Tomcat 各种连接器比较

 

Below is a small chart that shows how the connectors differentiate.

	Java Blocking Connector Java Nio Blocking Connector APR Connector Classname Http11Protocol Http11NioProtocol Http11AprProtocol Tomcat Version 3.x 4.x 5.x 6.x 6.x 5.5.x 6.x Support Polling NO YES YES Polling Size N/A Unlimited - Restricted by mem Unlimited - Configurable Read HTTP Request Blocking Non Blocking Blocking Read HTTP Body Blocking Sim Blocking Blocking Write HTTP Response Blocking Sim Blocking Blocking SSL Support Java SSL Java SSL OpenSSL SSL Handshake Blocking Non blocking Blocking Max Connections maxThreads See polling size See polling size

 

Context 的监听器

Lifecycle Listeners

If you have implemented a Java object that needs to know when this Context is started or stopped, you can declare it by nesting a Listener element inside this element. The class name you specify must implement the org.apache.catalina.LifecycleListener interface, and the class must be packaged in a jar and placed in the $CATALINA_HOME/lib directory. It will be notified about the occurrence of the corresponding lifecycle events. Configuration of such a listener looks like this: <Context path="/examples" ...> ... <Listener className="com.mycompany.mypackage.MyListener" ... > ... </Context> Note that a Listener can have any number of additional properties that may be configured from this element. Attribute names are matched to corresponding JavaBean property names using the standard property method naming patterns.

 

 

Request Filters

You can ask Catalina to check the IP address, or host name, on every incoming request directed to the surrounding Engine, Host, or Context element. The remote address or name will be checked against a configured list of "accept" and/or "deny" filters, which are defined using the Regular Expression syntax supported by the Jakarta Regexp regular expression library. Requests that come from locations that are not accepted will be rejected with an HTTP "Forbidden" error. Example filter declarations: <Context path="/examples" ...> ... <Valve className="org.apache.catalina.valves.RemoteHostValve" allow="*.mycompany.com,www.yourcompany.com"/> <Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.*"/> ... </Context> See Remote Address Filter and Remote Host Filter for more information about the configuration options that are supported.

 

Host Name Aliases

In many server environments, Network Administrators have configured more than one network name (in the Domain Name Service (DNS) server), that resolve to the IP address of the same server. Normally, each such network name would be configured as a separate Host element in conf/server.xml, each with its own set of web applications. However, in some circumstances, it is desireable that two or more network names should resolve to the same virtual host, running the same set of applications. A common use case for this scenario is a corporate web site, where it is desireable that users be able to utilize either www.mycompany.com or company.com to access exactly the same content and applications. This is accomplished by utilizing one or more Alias elements nested inside your Host element. For example: <Host name="www.mycompany.com" ...> ... <Alias>mycompany.com</Alias> ... </Host> In order for this strategy to be effective, all of the network names involved must be registered in your DNS server to resolve to the same computer that is running this instance of Catalina

 

 

Single Sign On

In many environments, but particularly in portal environments, it is desireable to have a user challenged to authenticate themselves only once over a set of web applications deployed on a particular virtual host. This can be accomplished by nesting an element like this inside the Host element for this virtual host: <Host name="localhost" ...> ... <Valve className="org.apache.catalina.authenticator.SingleSignOn" debug="0"/> ... </Host> The Single Sign On facility operates according to the following rules: All web applications configured for this virtual host must share the same Realm. In practice, that means you can nest the Realm element inside this Host element (or the surrounding Engine element), but not inside a Context element for one of the involved web applications. As long as the user accesses only unprotected resources in any of the web applications on this virtual host, they will not be challenged to authenticate themselves. As soon as the user accesses a protected resource in any web application associated with this virtual host, the user will be challenged to authenticate himself or herself, using the login method defined for the web application currently being accessed. Once authenticated, the roles associated with this user will be utilized for access control decisions across all of the associated web applications, without challenging the user to authenticate themselves to each application individually. As soon as the user logs out of one web application (for example, by invalidating the corresponding session if form based login is used), the user's sessions in all web applications will be invalidated. Any subsequent attempt to access a protected resource in any application will require the user to authenticate himself or herself again. The Single Sign On feature utilizes HTTP cookies to transmit a token that associates each request with the saved user identity, so it can only be utilized in client environments that support cookies