CODEWITHSUNDEEP
javaservletsweb-applicationswebsphere
Alex Salauyou
Alex Salauyou

Reputation: 14348

Skip deploying or stop web application if servlet context initialization fails

In our project, we have several Spring-based modules which are deployed on WAS as web applications. We need to skip deployment, or stop a module if its Spring context initialization fails (i.e. ContextLoaderListener#contextInitialized or DispatcherServlet#init throws an exception). Now, if such happens, app is got deployed and starts, but returns HTTP 500 for any request.

Websphere 8.5.5

Related question: https://stackoverflow.com/a/272747/3459206

Upvotes: 3

Views: 569

Answers (4)

Thomas Bitonti
Thomas Bitonti

Reputation: 1234

This APAR seems to be relevant:

https://www-01.ibm.com/support/docview.wss?uid=swg1PI58875

From the APAR text:

Listener exceptions typically should not stop the application
from starting up for service. However, some applications depend
on their listeners to do the necessary setup before the
application is started for service. Such applications prefer to
stop the application from starting up when there is any
exception in their listeners.

Problem conclusion

The WebContainer Container code was modified to provide an
option to stop the application when there is any listener
exception during the application starting up process.

A new WebContainer custom property needs to be set to enable the
behavior provided by this APAR:

For Full Profiles

com.ibm.ws.webcontainer.stopappstartuponlistenerexception = true
(default is false)

For Liberty Profile

stopappstartuponlistenerexception=true

The fix for this APAR is currently targeted for inclusion in
WebSphere Application Server fix packs 8.5.5.11 and  9.0.0.2,
and Liberty 16.0.0.3

See the APAR link for additional information.

Upvotes: 2

John Fantastico
John Fantastico

Reputation: 316

Look for a try-catch in the top level of your application code that is catching the Spring exception and allowing the application to continue running.

If the Spring exceptions being thrown are permitted to propagate to the top of the stack, the JVM will stop and there's no way it can keep running, far as I know.

Upvotes: -1

cilap
cilap

Reputation: 2333

Had a very similar issue. The thing is - webfear - sorry could not resist ;-) does not initialize everything on startup.

To trigger a controlled request, I added a ScheduledEJB to the startup of the application. This bean itself triggered a http-request to a defined URL, which itself triggered:

  • any filters to get initialized in the chain
  • any contexts which are needed are initialized

And this itself ensured that my application (EAR or WAR) got very quickly tested after deployment. This works well with some small amout of requests per minute

If you work with high load, means tons of requests per second, you need to choose a different approach. In this case I added a polling mechanism into the @Startup of the application, which polled every second or 250ms (depends on the load of the application). This firing to the server ensured, that my @Startup bean was the very first which triggered the possible init issues in the application. If this happened I initialized a filter which always reported a 500 (or better fitting error) to the requestor.

Of course stop your firing bean, as soon as you get the 500, else your admins may like to kill you. (happend to me, since I produced tons or monitoring issues ;-) ) And of course on the regular operation, after your application started properly, you should also disable the polling

Upvotes: 0

wl.GIG
wl.GIG

Reputation: 326

You can use jenkins + maven. Add the part you need to check under your test like junit. Then if this module do not pass test, jenkins would not deploy it.

But I prefer fix bugs before deployment

Upvotes: 0

Related Questions