Why use the ServletContext object in a web-app containing servlets and "worker" threads in Java

Question

Hi, I currently have a web-app where I have Servlets reading and writing to the ServletContext attributes and I have "working" Threads (Daemon threads) which get initialized on startup and currently hold as a member the ServletContext object. For a couple of reasons I'm thinking of moving to "implement Runnable" instead and I'm kind of stuck with the fact that I need a common resource that servlets and non-servlets can use to talk with each other and I feel I'm a bit stuck in the whole ServletContext paradigm. I'd appreciate it if someone could provide points on why to use the ServletContext (my way or another way) and also I'm thinking to just use a singleton class which will be initialized on startup and will be thread safe and I'll just route all communication of the servlets and non-servlets through it. What do you think?

Thanks

Answer 1

Java Servlet container is effectively a lightly managed code container. Servlets are components with very well defined life-cycle, and, there is also a very well defined contract between the container and the components (which can also include filters).

As it is specified, a web-app is a passive-reactive system.

It is passive, in the sense that no user defined threads are (strictly) allowed. (Some containers may not enforce this restriction, but by spawning off your own threads, you are effectively off the reservation, and potentially unpredictable behaviors can occur.)

It is reactive, in the sense that activity on the server (in your code base) occurs in response to requests, and these are for the typical Servlet app HTTP requests.

The ServletContext is the shared context of all components of a given web-app in the container. This context is created when the web-app is activated, and destroyed when it is deactivated. You can use a ServletContextListener component to hook into this life-cycle and get notification call backs regarding life cycle events.

If you are willing to continue on the wild side and spawn off active elements in your web-app, then you may wish to consider the following:

1 - Create and register a ServletContextListner component to manage the active components. On web-app startup/activation you will get a callback from the container. Here you can start your threaded components. As this component will be passed a reference to the ServletContext, you can pass that reference to the threaded components.

2 - Your threaded component class (whether an extension of Thread or implementation of Runnable) needs to be manageable, in the sense that you need to provide the means to cleanly shutdown the thread when your ServletContextListener receives the context shutdown callback. If you are up to formalizing the runnable tasks, the ExecutorService provides the functionality you require so you don't have to reinvent the wheel.

That said, you may wish to review your requirements and thus your chosen design and web-container platform. It may be that you really require a more sophisticated back-end stack.