CODEWITHSUNDEEP
javaservletserror-handlingwar
Basil Musa
Basil Musa

Reputation: 8748

Right way for handling a java web application startup error

I'm currently writing a java web application that performs specific checks at startup. Example, checking that the configuration file exists and defines all the required setting variables.

I placed the checking code inside the a subclass of the ServletContextListener class and registered the ServletContextListener subclass inside web.xml using:

<listener>
    <listener-class>com.bloxware.lls3.MainContextListener</listener-class>
</listener>

In the overridden contextInitialized() method I wrote code that checks the configuration file is in place and contains valid values.

If an error takes place at startup, I want to log this error and inform the web user in a suitable manner.

I need help on how to move forward from here:

  1. Am I reading the configuration file parameters in the correct place (inside the ServletContextListener.contextInitialized(..) method )?

  2. How would I handle showing an error page to the user once this takes place (eg. shall I add code to each servlet and jsp page to check a global flag, or can I do that in a smarter way, possibly ServletRequestListener.requestInitialized(..))?

  3. I need a way that if the user fixes the configuration file, refreshing the page is sufficient and there is no need to restart the web application.

Upvotes: 3

Views: 1504

Answers (1)

rfeak
rfeak

Reputation: 8214

I can respect the goal of having a dynamic configuration that checks itself, but realistically I wouldn't suggest going that route.

For the most part (caveats later) when a web application starts up, it either is configured correctly or it isn't. If the application is mis-configured, it simply won't work. For example, when applications start, many will connect to a database. If they connection string is wrong, there is never going to be a good user experience. This should be handled at startup, and startup only. The web application should NOT start, if it knows that it cannot function. Spattering code through your entire application to deal with that isn't the way to go.

The idea of checking this on context initialization is fine. But, it should be perfectly willing to throw a detailed and logged exception on the spot so that an administrator (not a user!) can deal with the issue and restart the app.

As for dynamic configurations that update without a restart. This is fine for adjusting non-critical parameters, such as timeout lengths, logging levels, or pool settings. These should only be things that don't bring the app to an immediate halt if they are incorrect. The hostname of your DB connection (for example) isn't one of these things.

In my experience, none of these things is really worth the effort to deal with all the side issues induced by dynamic reloading of configurations. I'd go with just checking things at startup and halting immediately if there is a fatal issue.

EDIT: Side note - Checking that your configuration file is in place and contains all the necessary settings is something that should probably be done in testing, not at application startup time. You can do this as a simple unit test against the file itself.

Upvotes: 2

Related Questions