3

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

Alex Salauyou
  • 14,185
  • 5
  • 45
  • 67

4 Answers4

2

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.

Thomas Bitonti
  • 1,179
  • 7
  • 14
  • please note, this solution is depending to your admin configurations. And if they miss it you have a missbehaving application. In bigger enterprises with a highly distributed admin team, this maybe a issue. – cilap Jan 03 '19 at 23:13
0

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

wl.GIG
  • 306
  • 1
  • 2
  • 13
  • The question is related to cases where on-deployment initialization depends on external modules which we cannot access during testing phase. – Alex Salauyou Dec 29 '18 at 09:51
0

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

cilap
  • 2,215
  • 1
  • 25
  • 51
  • And how the app may be stopped if it is detected to be not properly initialized? Any working solutions for Websphere? – Alex Salauyou Jan 03 '19 at 20:06
  • @AlexSalauyou how did you package the application for websphere (EAR, WAR)? Need to check my exact solution, it is already some years ago. In the meanwhile I prefer to use open source containers like wildfly - if the client allows it of course. – cilap Jan 03 '19 at 23:10
  • xml-configured Spring apps packaged as war-s – Alex Salauyou Jan 03 '19 at 23:26
  • Sadly you cannot control from "inside" the application the undeploy of the application. Every container has a different way of handling the start/stop. Could you explain me why it is important to stop the application? Is it a web-application, or a web-service, or a backend for a desktop app? – cilap Jan 04 '19 at 13:17
-1

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.

John Fantastico
  • 332
  • 1
  • 7
  • 1
    This suggestion does not apply to spring applications. Spring has its own error handlers here and there, depending on what's throwing the exception. It doesn't all go to a top-level try/catch that is implemented by the application itself. – Marnee May 06 '22 at 21:31