• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When should Servlet utility classes be Servlets and when ordinary Java classes?

 
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 Weaver
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I meant of course implement the interface.
 
Ranch Hand
Posts: 5399
1
Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Benjamin Weaver:
2. Utility classes, including servlets, are allowed to make calls outside the container, can they not? Say as a socket client?


Can you elaborate this ??
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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."
 
Benjamin Weaver
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Benjamin Weaver
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the info, Gary! I was writing a response to R K Singh when you sent in your reply.
 
reply
    Bookmark Topic Watch Topic
  • New Topic