14

Is there any method to prevent a Java EE application from starting if an exception occurs during application initialization? I'm basically looking for a way to cause the application to enter a "j2ee.state.failed" state (per JSR-77) following an unhandled exception thrown from a ServletContextListener or a Singleton Startup bean during application initialization.

The EJB specification seems to indicate that if an exception occurs during initialization of a Singleton bean, the application will continue to start and run without error; however, only the bean itself may be in a state where it cannot be invoked. Unfortunately, this is not the behavior that I'm looking for.

4.8.4 Singleton Error Handling

Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance. Possible initialization errors include injection failure, a system exception thrown from a PostConstruct method, or the failure of a PostConstruct method container-managed transaction to successfully commit. If a singleton fails to initialize, attempted invocations on the Singleton result in an exception as defined by Section 3.4.3 and Section 3.4.4.

The Servlet specification is a bit more ambiguous in its requirements, seemingly not requiring a container to behave in any particular way, but merely suggesting (through the use of the term "may") that the web module continue to start, but any requests should result in an internal server error. Again, this is unfortunately not the behavior I'm looking for. Why should the web application continue to start and appear to be running if it cannot handle any requests?

11.6 Listener Exceptions

The container may respond to all subsequent requests to the Web application with an HTTP status code 500 to indicate an application error.

In my experience, I've seen application servers handle this requirement differently. Some containers will in fact prevent the application from starting in these cases, whereas others will merely suppress the exception and respond to requests with 500 errors, as suggested in the specification.

Am I overlooking any part of the specification that would prevent an application from starting if an exception occurs during initialization?

shelley
  • 7,206
  • 4
  • 36
  • 63

3 Answers3

2

I think it depends on the application server you're using. It's up to him how to handle deployments with an invalid state, as you mentioned. The deployments aren't active when they fail so you've got to provide an service which looks for hints which your deployment should provide when started successfully. If not you can notify the administrators. But this is all serverspecific or needs an external tool.

In some projects we've used [nagios][1] and [rhq][2] for checking the deployments. For example nagios checks on JBossAS the jmx-console for the needed deployments. When the application which is deployed isn't shown within some seconds after deployment the it-staff is notified.

meme
  • 81
  • 2
  • 12
  • Tomcat 7.x will not start an application that throws an unchecked exception from a `ServletContextListener.contextInitialized()`, whereas WebLogic 12.1.3 will start the application. – javabrett May 26 '15 at 04:25
1

+1 to meme answer. And maybe it may help: in my expirience combination if bean with annotations @Startup and @Singleton throws exception in @PostConstruct method, it prevent whole application (ear) to start on JBoss AS 7.1.1

user1516873
  • 5,060
  • 2
  • 37
  • 56
0

in case of web apps - why not to create a servlet filter, which will check your own "failed" flag, and return 500 for any request, if this flag is raised? from container point of view, your app will be started of course.

aav
  • 2,514
  • 1
  • 19
  • 27
  • The goal is to prevent the application from starting in an invalid state. ServletContainerListeners and Singleton Startup beans are often used for performing initialization required for your application to function; if an error occurs during this initialization, the ideal state would be to fail-fast. This prevents users from being the ones to detect failures, bringing it to an admin's attention immediately. It would also allow application-agnostic deployment tools to universally detect application startup failures and behave accordingly; for example, by rolling back the application update. – shelley Sep 15 '11 at 18:37