I'm new to Servlets. 1. What motivations are there to make utility classes Servlets themselves? Life-cycle might be one, HttpServlet interface might be another. But, in the latter case, why not just inherit the interface? For example, forwarding a request. Why not instead just pass the HttpRequest object to the utility object and have that object return to the calling servlet? 2. Utility classes, including servlets, are allowed to make calls outside the container, can they not? Say as a socket client? Your perspectives are appreciated!
Benjamin, My take is that the number of servlets should be minimized for performance reasons and that code that may be reused should be in utility classes. Generally, servlets are good for servicing requests (usually HTTP) and for control logic related to a web application. If the function of some code is not one of the these two, then consider moving it out of the servlet. Examples are business logic and database access. Presentation should usually be in JSPs (for HTML) or could be in the servlet if JSPs are not used. This approach enables common logic to be independent of the request protocol (HTTP). e.g. business code in a utility class could be reused directly by a Java application or via RMI.
Note that this means HTTP concepts such as the request, session and response should not usually be passed to utility classes. The exception is when the utility class is really a helper class for the servlet (control, request parsing, HTML generation...). Your example of passing the HttpRequest to the utility object is widely used in frameworks such as Struts that employ a "Front Controller" servlet that handles all requests and routes them to various utility objects (Struts Actions). This means that only one instance of the servlet is required for the whole application and each request is handled by a lightweight thread - a very efficient approach.
GMann (SCJP, SCJD, SCWCD, SCBCD) "I'd rather have a bottle in front of me than a frontal lobotomy."
Joined: Apr 08, 2003
For example, you might want, in your business logic, to connect via socket to a remote server, retrieve from that server certain data, then post that information to the web. It would be natural to delegate that socket activity to one or more business-logic classes. One technique would be to subclass a Command object (let's assume we are not using Struts), let's call it MakeSocketConnectionToServerCommand. The Command superclass would import the java.servlets package and include at least one abstract method: execute(HttpRequest). But it would not need to be a servlet. (I'm thinking of an working example of this in our product line). Such a Command class hierarchy exemplifies the use of non-servlet classes to perform business functions. Another way to put the question is, why, if ever, would business logic utility classes be servlets? For that matter, why do we ever need more than 1 servlet per application?
Joined: Apr 08, 2003
Thanks for the info, Gary! I was writing a response to R K Singh when you sent in your reply.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: When should Servlet utility classes be Servlets and when ordinary Java classes?