Bdtjtk

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

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.

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

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

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.