在我们的项目中,我们有几个基于Spring的模块,这些模块作为Web应用程序部署在WAS上。我们需要跳过部署,或者如果模块的Spring上下文初始化失败(即ContextLoaderListener#contextInitialized
或DispatcherServlet#init
引发异常),则停止模块。现在,如果发生这种情况,应用程序将被部署并启动,但对于任何请求都将返回HTTP 500。
Websphere 8.5.5
答案 0 :(得分:2)
此APAR似乎相关:
https://www-01.ibm.com/support/docview.wss?uid=swg1PI58875
在APAR文本中:
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.
问题结论
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
有关其他信息,请参见APAR链接。
答案 1 :(得分:0)
您可以使用jenkins + maven。 添加您需要在测试下检查的零件,例如junit。 然后,如果此模块未通过测试,詹金斯将不会部署它。
但是我更喜欢在部署之前修正错误
答案 2 :(得分:0)
有一个非常相似的问题。 问题是-webfear-抱歉无法抗拒;-)在启动时未初始化所有内容。
为了触发受控请求,我在应用程序的启动中添加了ScheduledEJB。这个bean本身触发了对已定义URL的http请求,该URL本身触发了:
这本身确保了我的应用程序(EAR或WAR)在部署后得到了非常快速的测试。这对每分钟少量请求很有效
如果您处理高负载,则意味着每秒要处理大量请求,则需要选择其他方法。 在这种情况下,我在应用程序的@Startup中添加了一种轮询机制,该机制每秒或每250ms轮询一次(取决于应用程序的负载)。 对服务器的触发确保了我的@Startup bean是第一个触发应用程序中可能存在的init问题的人。如果发生这种情况,我会初始化一个过滤器,该过滤器始终向请求者报告500(或更合适的错误)。
当然,一旦获得500,就停止您的发射豆,否则您的管理员可能会杀死您。 (发生在我身上,因为我产生了很多吨或监测问题;-)) 当然,在常规操作上,在应用程序正确启动之后,您还应该禁用轮询
答案 3 :(得分:0)
在捕获Spring异常并允许应用程序继续运行的应用程序代码的顶级中寻找try-catch。
据我所知,如果允许引发的Spring异常传播到堆栈的顶部,则JVM将停止并且无法继续运行。