1

我们有 WAS 6.0（我知道）.2.43 ND 在多个地区运行。

我们的 Dev-B 区域运行良好，但是当我们进行 Web 调用时，Dev-C 会抛出 java 异常（至少这是开发人员告诉我的）......两个区域的代码相同，我检查了明显的嫌疑人（全球安全，SSL密码等），它们似乎都匹配。这是 SystemErr 的堆栈跟踪：

[8/1/12 4:02:31:758 EDT] 0000005c ServletWrappe E   SRVE0068E: Could not invoke the service() method on servlet action. Exception thrown : java.lang.NoClassDefFoundError
    at javax.crypto.Mac.getInstance(DashoA12275)
    at net.oauth.signature.HMAC_SHA1.computeSignature(HMAC_SHA1.java:73)
    at net.oauth.signature.HMAC_SHA1.getSignature(HMAC_SHA1.java:39)
    at net.oauth.signature.OAuthSignatureMethod.getSignature(OAuthSignatureMethod.java:83)
    at net.oauth.signature.OAuthSignatureMethod.sign(OAuthSignatureMethod.java:54)
    at com.harcourt.hsp.utils.LTIUtil.generateSignature(LTIUtil.java:62)
    at com.harcourt.hsp.web.struts.lti.action.BaseLTIAction.generateSignature(BaseLTIAction.java:238)
    at com.harcourt.hsp.web.struts.lti.action.BaseLTIAction.execute(BaseLTIAction.java:96)
    at org.springframework.web.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:106)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
    at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1796)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:887)
    at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
    at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1937)
    at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:130)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:434)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:373)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:253)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:207)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:109)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1498)

    at javax.crypto.Mac.getInstance(DashoA12275)
    at net.oauth.signature.HMAC_SHA1.computeSignature(HMAC_SHA1.java:73)
    at net.oauth.signature.HMAC_SHA1.getSignature(HMAC_SHA1.java:39)
    at net.oauth.signature.OAuthSignatureMethod.getSignature(OAuthSignatureMethod.java:83)
    at net.oauth.signature.OAuthSignatureMethod.sign(OAuthSignatureMethod.java:54)
    at com.harcourt.hsp.utils.LTIUtil.generateSignature(LTIUtil.java:62)
    at com.harcourt.hsp.web.struts.lti.action.BaseLTIAction.generateSignature(BaseLTIAction.java:238)
    at com.harcourt.hsp.web.struts.lti.action.BaseLTIAction.execute(BaseLTIAction.java:96)
    at org.springframework.web.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:106)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
    at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1796)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:887)
    at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
    at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1937)
    at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:130)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:434)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:373)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:253)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:207)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:109)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
    at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1498)

谢谢你的帮助。我确定这是我缺少的配置。

4

1 回答 1

0

由于某种原因，javax.crypto.Mac.getInstance无法解决。如果您想在全面排除故障之前尝试一些容易实现的目标：您是否缺少罐子？该类是否需要添加到您的类路径中？

归根结底，解决问题的最佳方法是逐步进行合乎逻辑的分析。这篇由3 部分组成的文章将引导您完成java.lang.NoClassDefFoundError. 这是一个相对较短的阅读，我怀疑它可能会回答你的问题。

为了完整起见，我已经包含了简短的版本（从上面提到的文章中提取）：

  1. 查看 java.lang.NoClassDefFoundError 错误并确定缺少的 Java 类。（在本例中为 javax.crypto.Mac.getInstance）

  2. 从您的编译/构建环境中验证并找到缺少的 Java 类

  3. 确定缺少的 Java 类是来自您的应用程序代码、第三方 API 还是 Java EE 容器本身。验证丢失的 JAR 文件在哪里/应该在哪里找到

  4. 找到后，验证您的运行时环境 Java 类路径是否存在任何拼写错误或缺失的 JAR 文件

  5. 如果问题是从 Java EE 应用程序触发的，请执行与上述相同的步骤，但要验证 EAR/WAR 文件的打包是否缺少 JAR 和其他库文件依赖项，例如 MANIFEST

  6. 执行受影响类的代码演练并确定它是否包含静态初始化程序代码（变量和静态块）

  7. 查看您的服务器和应用程序日志并确定是否有任何错误源自静态初始化程序代码

  8. 确认后，进一步分析代码并确定初始化程序代码失败的根本原因。您可能需要添加一些额外的日志记录以及适当的错误处理，以防止和更好地处理未来静态初始化代码的失败

于 2012-09-17T21:36:46.190 回答