Grails 2.3.4 War 在 Tomcat 7.0.47 中无法正常工作答案

【问题标题】：Grails 2.3.4 War not correctly working in Tomcat 7.0.47Grails 2.3.4 War 在 Tomcat 7.0.47 中无法正常工作
【发布时间】：2013-12-27 12:50:42
【问题描述】：

使用grails run-app 运行应用程序可以正常工作，但在 Tomcat 7 中部署后出现以下错误。

groovy.lang.MissingMethodException: 
No signature of method: static com.digithurst.hdspro.web.Responder.respond() 
is applicable for argument types: (ResourceListCmd, QueryCmd, groovy.util.ConfigObject) 
values: [ResourceListCmd@5c380e, ...]
Possible solutions: respond(HttpResource, java.lang.Object, java.lang.String)

如前所述，这在 Tomcat 之外有效。调用方法的方式与实现方式完全相同。 ResourceListCmd 实现了接口HttpResource，这使它非常适合。如果第一个参数是null，也会出现这个错误。

groovy.lang.MissingMethodException: 
No signature of method: static com.digithurst.hdspro.web.Responder.respond() 
is applicable for argument types: (null, QueryCmd, groovy.util.ConfigObject)
values: [null, ...]
Possible solutions: respond(HttpResource, java.lang.Object, java.lang.String)

更多关于环境的信息：

Windows 7 64 位
Java 7 U45 x86
Grails 2.3.4
Tomcat 7.0.47

我已经清理了用户目录中的.grails和.m2文件夹，并在创建war文件之前执行了grails clean。

[H3rnst回答后编辑]

控制器：

def index() {

    try {
        ResourceListCmd configs = configService.search()
        respond Responder.respond(configs, new QueryCmd(level: 'list'),
                                  grailsApplication.config.grails.serverURL)
    }
    catch (Exception e) {
        render status: INTERNAL_SERVER_ERROR
    }
}

ResourceListCmd：

interface HttpResource {
    ...
}

abstract class AbstractHttpResource implements HttpResource {
    ...
}

class ResourceListCmd extends AbstractHttpResource {
    ...
}

响应者：

class Responder {
    static def respond(HttpResource resource, def query, String serverURL) {
        ...
    }
}

【问题讨论】：

是 run-war 还是 run-app 工作？
我没有尝试过run-war（不知道那个命令），但是，正如开篇所说，run-app 确实有效。
我遇到了类似的问题，run-app 运行良好，但 run-war 没有运行，你可以试试吗？
我当然可以，但这有什么帮助呢？不过，这必须等到星期一。

标签： grails tomcat7

【解决方案1】：

您的战争（或 tomcat 服务器类路径）包含重复或错误版本的 jar，其中包含 com.digithurst.hdspro.web.Responder 类。（您使用 run-app 开发启动的类的版本与运行您的战争的一个 tomcat 负载不同）

您可以尝试解压战争结束验证有问题的 jar 的版本和/或使用像 jarscan 这样的工具来扫描重复的类。

您甚至可以尝试使用命令dependecy-report 并搜索相同库的重复注入。可能您正在使用的两个不同插件正在合并到同一库的不同版本中，从而导致问题。

【讨论】：

该类是我编写的，因此不属于任何第 3 方库。不过，我会看看战争中的情况。
Jarscan 恰好显示了一次 Responder，这是我编写的一类。我还用Java Decompiler看了一下.class，果然不出所料。

【解决方案2】：

marko's 建议做run-war 实际上给出了解决这个问题的最终线索。这不是 Tomcat 的问题，而是应用程序运行的环境。run-app 和 run-war 默认情况下都使用“开发”环境，因此它可以工作。只有在“生产”中它没有，这是部署到 Tomcat 时使用的。

真正的罪魁祸首是配置的一部分，错误消息是正确的，尽管出乎意料。我用grailsApplication.config.grails.serverURL 调用Responder.respond() 方法。 serverURL 仅设置为“开发”模式，而不是“生产”模式。这就是 Groovy/Java 抱怨方法签名的原因：

(ResourceListCmd, QueryCmd, groovy.util.ConfigObject) vs (HttpResource, java.lang.Object, java.lang.String)

线索是最后一个参数，前两个是正确的。但是，我希望 null 作为值而不是完全不同的类型。

【讨论】：