aspose file tools*
The moose likes Servlets and the fly likes static vars vs. servlet context Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "static vars vs. servlet context" Watch "static vars vs. servlet context" New topic
Author

static vars vs. servlet context

Gerry Giese
Ranch Hand

Joined: Aug 02, 2001
Posts: 247
Hi all.
I've been experimenting with learning how the 'static' keyword works. One thing I did was create a HttpServlet class that all my other servlets extend from so that it can do a bunch of pre-processing like setup database connections, handle forwarding, etc. It seems like if I just use static vars in this servlet to hold application settings it would be the same as if I had put the settings into the ServletContext, but easier to use. Is there any fault to my logic - are they equivalent? Any issues I should look out for? Is there a reason to use one over the other??
Thanks!


CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
Author of Posts in the Saloon
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12821
    
    5
ServletContext applies to everything in a "web application" so if all your servlets in this application use the same base, I think you end up with the same result.
Personally I would not do it that way because I am always fighting to keep the servlet class simple by farming out functions to helper classes. I say fighting because the servlet classes seem to get bigger anyway....
Bill

------------------
author of:
Gerry Giese
Ranch Hand

Joined: Aug 02, 2001
Posts: 247
Bill,
I guess I'm not sure how using static variables would make the base servlet (and it's children) any more complex.
I'm working on a framework where there are a number of utility and helper classes that perform various services such as logging, JDBC connections, security, and app configuration. What I'm doing is using a single servlet (I call it AppInitializer) that is the first in the load-on-startup order to instantiate these objects (many of them singletons, which I'm also learning about) and place them into the static variables in the base servlet (which never gets called, and in fact doesn't even have a doPost(), doGet(), or even service() in it). Then each servlet as it's loaded will access those services through the base servlet's variables (or accessors, depending). It's basicly like having additional built-in methods in the HttpServlet.
Maybe this background helps, maybe not. Maybe I don't understand the concept of 'helper' classes yet? Anyway, the only other way to make these basic services globally available, that I can see, is to instantiate them then stuff them into the ServletContext. But then each time a servlet needs a service it has to go unpack it from the ServletContext. Seems like it would be slower that way. I still have other helpers and business logic classes that get instantiated and destroyed like normal objects as needed.
My only issue right now is making the basic services thread-safe. The main one in need of this is my logging service, which logs to a file (one file per webapp). I'm just synchronizing the low-level write methods at this time. Since I'm using a singleton logger stored in the static variable, maybe I should just set up a fifo queue? Would that need to be synchronized, too? Thread-safety seems to me like the least-talked about and generally understood but one of the most important issues related to servlets/JSPs.
Thanks for the comments, Bill!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16228
    
  21

There's nothing inherently wrong with making a "reference" servlet with synchronized set/get methods, though I don't know that that's what I'd be doing there. For one thing, a Session EJB is very similar.
Before you try to synchronize everything under the sun (no pun intended), check the docs and make sure that Sun hasn't done it already, though. Some utility classes are already threadsafe and others mostly so (for example, if you format a thead-local StringBuffer and then write it in a method call).


Customer surveys are for companies who didn't pay proper attention to begin with.
Gerry Giese
Ranch Hand

Joined: Aug 02, 2001
Posts: 247
Tim,
EJBs are out of the picture right now. Our server (iPlanet) supports them, but we have only one machine and most of the developers are barely familiar with Java, much less J2EE. Using EJB at the moment would probably increase overhead and learning curve too much to be worthwhile at this time. As soon as we determine need for a second server or for something that fits perfectly with EJB capabilities, we'll jump in with two feet.
Right now, the only item I have synchronized is my logToFile(msg) method:

Would this be more efficient if I did a "synchronize( out )" inside the try block, and still be thread-safe? I have *got* to find more learning material related to thread-safety and servlets. Know of any?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: static vars vs. servlet context