加载saaj类库时出现问题

时间:2013-03-06 18:18:15

标签: java soap saaj

我完成了我的作业,但仍无法找到解决问题的方法。我通过NetBeans创建了一个WAR文件,它使用肥皂和附件 - saaj技术。按照建议,我在我的项目中包括:saaj-impl.jar,saaj-ri.jar,saaj-api.jar。但是,当我“热部署”或将我的WAR文件放入webapps目录时,我得到以下异常:

java.lang.NoClassDefFoundError: com/sun/xml/messaging/saaj/soap/MessageFactoryImpl
source.pkg.SoapClient.sendSoapMessage(SoapClient.java:120)
source.pkg.Air.<init>(Air.java:233)
source.flightops.AirController.<init>(AirController.java:15)
servlets.ResultsDisplay.processRequest(ResultsDisplay.java:40)
servlets.ResultsDisplay.doGet(ResultsDisplay.java:91)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
root cause

java.lang.ClassNotFoundException: com.sun.xml.messaging.saaj.soap.MessageFactoryImpl
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1711)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556)
source.pkg.SoapClient.sendSoapMessage(SoapClient.java:120)
source.pkg.Air.<init>(Air.java:233)
source.flightops.AirController.<init>(AirController.java:15)
servlets.ResultsDisplay.processRequest(ResultsDisplay.java:40)
servlets.ResultsDisplay.doGet(ResultsDisplay.java:91)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621

我试着明确指出类路径:

System.setProperty("java.class.path", wjp.getDataDir() + "/webapps/" + wjp.getAppContext() + "/WEB-INF/lib");

我做了更多研究,并试图调用类加载器:

try 
{          
Class.forName("com.sun.xml.messaging.saaj.soap.MessageFactoryImpl").getClassLoader();
} 
catch (ClassNotFoundException ex) 
{
        Logger.getLogger(AirDriver.class.getName()).log(Level.SEVERE, null, ex);
}

但仍然与上述相同。这很奇怪,因为当我重新启动服务器时,有时应用程序正常工作 - 收到SOAP响应并显示结果,但重启服务器后只显示 。这暗示了服务器重启时以某种方式找到saaj类的事实?但是,问题是它必须在我“热部署”或将更新的WAR放入webapps目录而不重新启动时才能工作。每次更新WAR时,我们都无法负担重启生产服务器的费用。

另一个奇怪的问题是,在我重新启动服务器之后,启动这个WAR应用程序它运行正常。但是,使用相同saaj类库的其他应用程序会抛出同样的异常!所以它要么使用这个WAR应用程序而其他人没有工作,要么使用其他应用程序,这个WAR应用程序抛出此异常。是否存在某种有限的saaj库共享?我以前从未见过这样的事情。

拜托,有人可以帮我解决这个非常奇怪(和讨厌)的问题吗?

谢谢你, 胜者。

1 个答案:

答案 0 :(得分:0)

通过在主Web容器中重新实现应用程序(即ROOT / WEB-INF)而不是单独的portlet解决了该问题。

相关问题