运行带有通过logback.groovy文件定义的logback的项目时遇到问题。运行logback.xml配置时不会出现此类问题
以下是logback.xml配置的示例:
<configuration>
<appender name="testflow" class="ch.qos.logback.core.FileAppender" file="dbGripTest.log">
<encoder>
<pattern>%d{MMM d HH:mm:ss.SSS,UTC} %5p - %m [%ex] [%c{0}:%L] [%t]%n</pattern>
</encoder>
</appender>
<appender name="consoleMain" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{MMM d HH:mm:ss.SSS,UTC} %5p - %m [%ex] [%c{0}:%L] [%t]%n</pattern>
</encoder>
</appender>
<appender name="consoleSolace" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{MMM d HH:mm:ss.SSS,UTC} %5p - %m [%c{0}]%n</pattern>
</encoder>
</appender>
<root level="ERROR"/>
<logger name="com.db.testing" level="DEBUG">
<appender-ref ref="consoleMain" />
<appender-ref ref="testflow" />
</logger>
<logger name="com.db.taps" level="DEBUG">
<appender-ref ref="consoleSolace" />
<appender-ref ref="testflow" />
</logger>
</configuration>
以下是logback.groovy文件的内容:
import ch.qos.logback.classic.encoder.PatternLayoutEncoder
import ch.qos.logback.core.ConsoleAppender
import ch.qos.logback.core.FileAppender
import static ch.qos.logback.classic.Level.DEBUG
import static ch.qos.logback.classic.Level.INFO
import static ch.qos.logback.classic.Level.ERROR
appender("testflow", FileAppender) {
file = "dbGripTest.log"
append = false
encoder(PatternLayoutEncoder) {
pattern = "%d{MMM d HH:mm:ss.SSS,UTC} %5p - %m [%ex] [%c{0}:%L] [%t]%n"
}
}
appender("consoleMain", ConsoleAppender) {
encoder(PatternLayoutEncoder) {
pattern = "%d{MMM d HH:mm:ss.SSS,UTC} %5p - %m [%ex] [%c{0}:%L] [%t]%n"
}
}
appender("consoleSolace", ConsoleAppender) {
encoder(PatternLayoutEncoder) {
pattern = "%d{MMM d HH:mm:ss.SSS,UTC} %5p - %m [%c{0}]%n"
}
}
root(ERROR)
logger("com.db.testing", DEBUG, ["testflow","consoleMain"])
logger("com.db.taps",DEBUG, ["testflow","consoleSolace"])
这就是我使用groovy config运行应用程序时得到的结果:
Jun 10 07:37:33.312 INFO - Transport Receiver is listening on: [, idgrip/ccr/ext/abfx/request/uk] [SolaceTransport]
Jun 10 07:37:33.948 DEBUG - SNAP objects have been created [] [SNAPAdapter:-1] [main]
Exception in thread "main" groovy.lang.MissingMethodException: No signature of method: logback.appender() is applicable for argument types: (java.lang.String, java.lang.Class, logback$_run_closure1) values: [testflow, class ch.qos.logback.core.FileAppender, logback$_run_closure1@1a45193b]
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:56)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:78)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:179)
at logback.run(logback.groovy:9)
at cucumber.runtime.groovy.GroovyBackend.runIfScript(GroovyBackend.java:95)
at cucumber.runtime.groovy.GroovyBackend.loadGlue(GroovyBackend.java:77)
at cucumber.runtime.Runtime.<init>(Runtime.java:91)
at cucumber.runtime.Runtime.<init>(Runtime.java:69)
at cucumber.runtime.Runtime.<init>(Runtime.java:65)
at cucumber.api.cli.Main.run(Main.java:35)
at cucumber.api.cli.Main.main(Main.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
真正奇怪的是输出实际上是按配置文件中的说明格式化的 - 即第一个字符串使用“consoleSolace”模式,第二个字符串使用“consoleMain”模式,因此文件以某种方式被使用和解释。
使用的版本(来自依赖树插件):
[INFO] +- ch.qos.logback:logback-classic:jar:0.9.28.1:compile
[INFO] | \- ch.qos.logback:logback-core:jar:0.9.28.1:compile
[INFO] +- org.codehaus.groovy:groovy-all:jar:2.4.3:compile
任何想法导致这种行为的原因是什么?根据{{3}}
,这正是应该在logback.groovy中声明appender的方式。答案 0 :(得分:0)
当我正在解决由Cucumber引起的另一个问题时,我决定检查它是否有帮助。确实如此。
这是因为这个.groovy文件在Cucumber启动配置中被粘合,而Cucumber似乎试图执行遇到的所有.groovy文件。在我将启动器中的Glue更改为仅指向功能文件后,此错误消失了