Using a custom Servlet oriented framework, too many servlets, is this an issue

Question

In our application, we structure different web applications by Servlet. There are many, many Servlets and Filters in our applications.

We already use different frameworks but not for this particular legacy web application. One issue is that one application/servlet is completely separate from another.

If you were to redesign your application that used this legacy design, how would you fix the issue where you have your application broken by too many servlets.

I was considering some kind of "Servlet Manager" that would group a bunch of servlets and then invoke the proper servlet when appropriate.

Answer 1

Spring has the facility to delegate requests to existing legacy Servlets (using ServletWrappingController or ServletForwardingController), if that is what you so desire.

So you could have a Spring DispatcherServlet sitting at the front of your legacy servlets, making full use of Spring's request routing facilities. Spring could also give you the facility for more easily sharing stuff between the servlets, but putting shared components in the servlet context for you.

Answer 2

Lookup the page controller / front controller pattern. It boils down to having a single servlet which controls the requests. Inside the servlet you need to lookup the action (just a business/domain object) associated with the particular request and then execute it.

Basic pseudo-example:

protected void processRequest(request, response) {
    Action action = ActionFactory.getAction(request);
    action.execute(request, response);
}

You could use the original url-patterns to return the desired Action. The ActionFactory could hold a Map<String, Action> wherein the key is less or more the original url-pattern. You could use request.getPathInfo() to determine the url-pattern. You could maintain those url-Action pairs in an xml or properties file or just adhere special naming conventions for classes implementing Action. The Action implementations can then use the "original" servlet coding.

However, if you're open for using an existing framework, then I would recommend just adopting one.