Java EE项目迁移Maven时遇NoClassDefFoundError(ognl.OgnlRuntime)及调度错误

从你贴的日志片段来看，目前只看到Struts2开始解析struts-default.xml的INFO级启动日志，但还没看到引发调度错误的核心异常信息。结合Java EE转Maven的常见踩坑点，我整理了几个优先排查的方向：

• 先把Maven依赖的坑填上
  迁移到Maven后，最容易踩的就是依赖缺失或者版本冲突的坑：

  • 检查你的pom.xml，确保Struts2的核心依赖（比如struts-core、xwork-core，如果需要适配WebSphere还要加struts2-websphere-plugin）都正确声明，并且版本统一；
  • 对于WebSphere已经提供的API（比如Servlet、JSP相关的依赖），一定要加上<scope>provided</scope>，不然打包时把这些jar塞进war包，很容易和WebSphere自带的类库冲突，引发各种奇怪的类加载错误。

• 去日志里挖完整的错误细节
  你现在给的日志只是启动时的INFO信息，根本看不到调度错误的原因。赶紧去C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\My_SERVER目录下找：

  • 翻SystemOut.log和SystemErr.log，搜索ERROR、Exception、Failed这些关键词，找到和调度错误对应的完整异常堆栈；
  • 重点留意ClassNotFoundException（类找不到，大概率是依赖漏加了）、NoSuchMethodError（方法找不到，基本是依赖版本不兼容）、SAXParseException（配置文件语法错了）这几类异常，都是迁移场景下的高频问题。

• 调整WebSphere的类加载策略
  WebSphere的类加载机制和Tomcat不一样，很容易因为类加载顺序搞出问题：

  • 把你的应用类加载模式改成PARENT_LAST（让应用自己的jar包优先于WebSphere自带的类库加载），这一招能解决大部分依赖冲突导致的调度错误；
  • 打开你打包好的war包，检查WEB-INF/lib目录，看看有没有重复的jar（比如同时存在struts-core-2.3.x.jar和struts-core-2.5.x.jar），重复依赖也是常见的祸根。

• 确认Struts配置文件没问题
  虽然日志显示在解析struts-default.xml，但要确保你自己的struts.xml配置正确：

  • 配置文件要放在Maven项目的src/main/resources目录下，这样打包时才会被放到WEB-INF/classes里，Struts才能找到；
  • 检查struts.xml里的语法，有没有标签没闭合、命名空间写错、Action类路径配置错误这些低级问题。

如果能把完整的错误堆栈贴出来，就能更精准地定位问题啦！

内容的提问来源于stack exchange，提问作者Alma