Next reading on my list

A new mom sure needs good advice on weight control, and where else to get it from than from one of the software gurus - John Walker explains the Hacker's diet and I am reading through it to get back in shape and fit into my old jeans!

Who told me about it? Well, trust Big Brother! ;)

My favorite interview

I was reading through Reginald's interesting blog entry about interviews and I started trying to see if there is a pattern in the way I typically conduct an interview. The basic philosophy is to make a candidate comfortable and to try to select, rather than reject. I usually start with asking the candidate to be at ease and to tell me something about themselves. We discuss their professional lives, why they are looking for a change, how long they have been working in the current position and so on. Then I ask them what they are working on currently, and what is their role in the project. While they speak, I try to form my opinion on their enthusiasm towards wha they are doing and how they seem to be faring in their team. This is important, as without being kicked about what you are doing, it will be difficult to sustain minimum 8 hours a day, 5 days a week. Also, most software is written in groups of 3-4, and it is important that the incumbent does not rub team members the wrong way. We have enough problems to cater to and would like to avoid the ego hassles, thank you!

I request them to explain the project high level design, and the lower level details of the modules they are working on. The idea is to get them to talk about what they should probably be knowing real well. If they make it this far, they are worth a real try to be inducted, and the interview now focusses on how much more they know. Would they mind explaining a bit about the interfaces to their modules? Why are the interfaces designed the way they are? Why are particular tools being used, what are their advantages/disadvantages? Would they be knowing some alternatives to those tools - another database, another package etc? If a client has requested something, does the candidate understand the business drivers to it?

There are some strong no-nos. Candidates who are not willing to be hands on - who want to purely lead are refused, as I interview programmers and not managers. Candidates who seem to get irritated when prodded will again not do, as we want people who can sit and discuss pros and cons and successfully drive their point across, or accept a superior point of view. Overall, personal integrity is sought after, though very difficult to judge. If the candidate is able to accept a mistake, it speaks volumes about his/her character.

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