non riesco a caricare log4j2 mentre eseguo fatjar

Question

sto lavorando su un progetto in cui utilizzo log4j2 logging. durante lo sviluppo in intellij, tutto funziona correttamente e la registrazione viene eseguita come previsto. log4j2.xml è collegato tramite la proprietà java passata a jvm all'avvio tramite le impostazioni intellij. ma una volta che si tenta di eseguire un Gradle standalone incorporato grasso-jar, ho riscontrato i seguenti problemi:

java -Dlog4j.debug=true -Dlog4j.configurationFile=/home/aaa/log4j2.xml -jar /home/aaa/myjar-SNAPSHOT.jar 

eccezioni:

ERROR StatusLogger Unrecognized format specifier [d] 
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 16 in conversion pattern. 
ERROR StatusLogger Unrecognized format specifier [thread] 
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at position 25 in conversion pattern. 
... 
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. 

io non capisco nemmeno dove coloro [thread] s provenienza, dal momento che ottengo lo stesso errore anche mentre si utilizza un config più semplice di base nel mio log4j2:

<?xml version="1.0" encoding="UTF-8" ?><Configuration status="WARN" monitorInterval="86400"> 
<Appenders> 
    <Console name="console-log" target="SYSTEM_OUT"> 
     <PatternLayout 
       pattern="%-5p %d{yyyy-MM-dd HH:mm:ss.SSS} ${hostName} %c{1} %msg %throwable{7}%n"/> 
    </Console> 
</Appenders> 
<Loggers> 
    <Root level="info" additivity="false"> 
     <AppenderRef ref="console-log"/> 
    </Root> 
</Loggers> 

ogni pensiero è benvenuto. Grazie.

Answer 1

in fatJar, dipendenze possono fornire un log4j-provider.properties nel META-INF che causa questo problema,

rimuoverla nel compito Gradle:

task fatJar(type: Jar) { 
    manifest { 
     attributes 'Implementation-Title': 'project', 
     'Implementation-Version': project.version, 
     'Main-Class': 'com.sample.CLI' 
    } 
    baseName = project.name + '-all' 
    from { 
     configurations.compile.collect { 
      it.isDirectory() ? it : zipTree(it).matching { 
       exclude 'META-INF/**.RSA' 
       exclude 'META-INF/MANIFEST.MF' 
       exclude 'META-INF/log4j-provider.properties' 
      } } } 
    with jar 
} 

Answer 2

Il problema è descritto qui: https://issues.apache.org/jira/browse/LOG4J2-673

Purtroppo al momento non sembra essere solo una soluzione per il Maven-ombra-plugin: https://github.com/edwgiz/maven-shaded-log4j-transformer

<plugins> 
     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-shade-plugin</artifactId> 
      <version>2.4.3</version> 
      <executions> 
       <execution> 
        <phase>package</phase> 
        <goals> 
         <goal>shade</goal> 
        </goals> 
        <configuration> 
         <finalName>${project.artifactId}${appSuffix}</finalName> 
         <transformers> 
... 
          <transformer 
            implementation="com.github.edwgiz.mavenShadePlugin.log4j2CacheTransformer.PluginsCacheFileTransformer"> 
          </transformer> 
         </transformers> 
... 
        </configuration> 
       </execution> 
      </executions> 
      <dependencies> 
       <dependency> 
        <groupId>com.github.edwgiz</groupId> 
        <artifactId>maven-shade-plugin.log4j2-cachefile-transformer</artifactId> 
        <version>2.1</version> 
       </dependency> 
      </dependencies> 
     </plugin> 
</plugins> 

Answer 3

Il LoggerContextFactory associa l'API Log4j alla sua implementazione. Log4j LogManager individua una LoggerContextFactory individuando tutte le istanze di META-INF/log4j-provider.properties, un file standard java.util.Properties e quindi ispezionando ciascuna per verificare che specifichi un valore per la proprietà Log4jAPIVersion conforme alla versione richiesta da LogManager.

Incase del vaso grasso, è anche possibile specificare in modo esplicito log4j2 da utilizzare LoggerContextFactory nell'applicazione da:

System.setProperty("log4j2.loggerContextFactory", "org.apache.logging.log4j.core.impl.Log4jContextFactory") 

o come specificato nel file log4j-provider.properties incluso nel vostro log4j-core vaso.

Answer 4

Quando si esegue l'applicazione da un IDE, jar viene eseguito automaticamente senza incorporare le dipendenze e non si verificano conflitti di impostazioni del registro. Ma quando si converte l'applicazione in un contenitore di grassi, tutte le dipendenze verranno iniettate nel file jar del progetto e le impostazioni di log4j che provengono da file jar esterni (dipendenze) potrebbero essere in conflitto mentre il processo fatJar li unirà in un singolo artefatto.

In questo caso, penso che i file "Log4j2Plugins.dat" potrebbero essere in conflitto. Per sicurezza, puoi aprire il tuo file fatJar con un editor zip (es: 7Zip), navigare nel percorso in fatJar come sotto ed eliminare uno dei file in conflitto (puoi scegliere il più piccolo per dimensione) dal tuo fatJar. Eseguire il fatJar e verificare che la registrazione funzioni correttamente.

\ META-INF \ org \ apache \ logging \ log4j \ core \ config \ plugins \ Log4j2Plugins.dat

Ora possiamo controllare le dipendenze (artefatti) e trovare quali di essi contengono i file "Log4j2Plugins.dat". Quindi puoi escludere i moduli che hanno il file dal tuo strumento di compilazione e quindi il tuo processo di creazione di fatJar escluderà i file in conflitto e il tuo nuovo fatJar può avviare la registrazione come previsto.

Nel mio caso, il mio modulo fatJar importa alcuni altri moduli da Spring Boot e quando escludo le librerie di registro in conflitto, il mio fatJar inizia la registrazione senza errori.

configurations { all*.exclude module: 'spring-boot' all*.exclude module: 'spring-boot-starter-logging' all*.exclude module: 'logback-classic' all*.exclude module: 'commons-logging' }