Tweaking Tomcat
Problem
To gain control over Tomcat internal mechanism by doing the following:
- To run tomcat programmatically in the same JVM.
- To override default JSP invocation
- To override default servlet invocation
- To run the http connector and listen to http requests
- Intercept requests and furnish request information like headers, body, get and post data
- To access uploaded file information
About Tomcat
Tomcat is a servlet container implementing the Java Servlet 2.4 Specifications. It is also holds a JSP engine as per the JSP 1.2 Specifications.
The basic functionality of Tomcat can be summarized as:
- Creating a request object by parsing the http request headers, bodyand other information which can be passed on to the invoked servlet
- Creating a response object which can be passed back to the requesting client(typically a browser)
- Invoking the service method of the responsible servlet
To achieve the above, Tomcat consists of two main modules – Connector and the Container. The Connector’s main job is to construct a request and response object for each HTTP request it receives, and connect the request with the container. The container is the processor of the request, it receives the Request and Response objects from the Connector and invokes the service method of the Container.
The various types of containers in Tomcat are:
1. A Server element represents the entire Catalina servlet container
2. A Service element represents the combination of one or more Connector components that share a single Engine component for processing incoming requests. One or more Service elements may be nested inside a Server element.
3. The Engine element represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for ultimate transmission back to the client. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with this Service.
4. Host: This allows multiple servers to be configured on the same physical machine and be identified by separate IP addresses.
5. Context: This represents a single web application
Solution Approach
As we are concerned with request interception before it reaches the servlet layer, we need to create a custom container and attach the HTTP connector to it. Requests from the connector can then be pointed to the custom container instead of the default servlet container. As we are dealing at the entire request processing level, a custom Engine object(SimpleContainer) is created.
The basic concept of Tomcat request processing is pipelining. A pipeline contains tasks that the container will invoke. A valve represents each task. There is one basic valve in the container’s pipeline, but we can add as many valves as we want. The pipeline invokes the first valve and this valve invokes the next and then the invoked valve invokes the next and so on till all the valves are invoked. So, our custom container needs a custom valve as its first valve, so as to consume the request and do the necessary processing
To gain control over Tomcat internal mechanism by doing the following:
- To run tomcat programmatically in the same JVM.
- To override default JSP invocation
- To override default servlet invocation
- To run the http connector and listen to http requests
- Intercept requests and furnish request information like headers, body, get and post data
- To access uploaded file information
About Tomcat
Tomcat is a servlet container implementing the Java Servlet 2.4 Specifications. It is also holds a JSP engine as per the JSP 1.2 Specifications.
The basic functionality of Tomcat can be summarized as:
- Creating a request object by parsing the http request headers, bodyand other information which can be passed on to the invoked servlet
- Creating a response object which can be passed back to the requesting client(typically a browser)
- Invoking the service method of the responsible servlet
To achieve the above, Tomcat consists of two main modules – Connector and the Container. The Connector’s main job is to construct a request and response object for each HTTP request it receives, and connect the request with the container. The container is the processor of the request, it receives the Request and Response objects from the Connector and invokes the service method of the Container.
The various types of containers in Tomcat are:
1. A Server element represents the entire Catalina servlet container
2. A Service element represents the combination of one or more Connector components that share a single Engine component for processing incoming requests. One or more Service elements may be nested inside a Server element.
3. The Engine element represents the entire request processing machinery associated with a particular Catalina Service. It receives and processes all requests from one or more Connectors, and returns the completed response to the Connector for ultimate transmission back to the client. Exactly one Engine element MUST be nested inside a Service element, following all of the corresponding Connector elements associated with this Service.
4. Host: This allows multiple servers to be configured on the same physical machine and be identified by separate IP addresses.
5. Context: This represents a single web application
Solution Approach
As we are concerned with request interception before it reaches the servlet layer, we need to create a custom container and attach the HTTP connector to it. Requests from the connector can then be pointed to the custom container instead of the default servlet container. As we are dealing at the entire request processing level, a custom Engine object(SimpleContainer) is created.
The basic concept of Tomcat request processing is pipelining. A pipeline contains tasks that the container will invoke. A valve represents each task. There is one basic valve in the container’s pipeline, but we can add as many valves as we want. The pipeline invokes the first valve and this valve invokes the next and then the invoked valve invokes the next and so on till all the valves are invoked. So, our custom container needs a custom valve as its first valve, so as to consume the request and do the necessary processing
posted by Sonal at 9:21 PM
0 Comments:
Post a Comment
<< Home