La ragione per i vostri problemi è che il file di configurazione logback non dovrebbe mai essere compilato. Viene letto in fase di runtime da LogBack tramite GroovyShell
o un meccanismo simile.
La soluzione dipende dalla configurazione del progetto. Di seguito troverete una soluzione per un progetto costruito con Gradle seguendo il Maven Standard Directory Layout:
primo file è src/main/groovy/Test.groovy
:
import org.slf4j.Logger
import org.slf4j.LoggerFactory
class Test {
static Logger LOG = LoggerFactory.getLogger(Test.class)
static void main(String[] args) {
LOG.debug("Test")
}
}
secondo file è src/main/resources/logback.groovy
:
import static ch.qos.logback.classic.Level.INFO
import static ch.qos.logback.classic.Level.DEBUG
import ch.qos.logback.classic.encoder.PatternLayoutEncoder
import ch.qos.logback.core.ConsoleAppender
appender("CONSOLE", ConsoleAppender) {
encoder(PatternLayoutEncoder) {
pattern = "%-4relative [%thread] - %msg%n"
}
}
root(DEBUG, ["CONSOLE"])
ho omesso il Gradle costruire file (build.gradle
).
Il layout di directory standard garantisce che ogni file in src/main/groovy
sia compilato, mentre tutto nel file classe src/main/resources
è incluso. Quindi LogBack è in grado di trovare quel file in fase di runtime.
Aggiornamento: Non ho letto il problema con sufficiente attenzione. Non sono riuscito a risolvere il problema quando entrambi i file si trovano nella stessa directory e lo avvio tramite groovy Test.groovy
. Penso che questo non sia possibile. Il comando groovy compila sempre tutti i file groovy nella directory corrente e nel classpath specificato.
Come potrebbe non funzionare lo script? Spiega la ragione. Penso che la soluzione giusta sarebbe quella di far funzionare lo script, non il fallback in .xml config. – Archer