core-geonetwork icon indicating copy to clipboard operation
core-geonetwork copied to clipboard

Change to log4j2 logging library

Open jodygarnett opened this issue 3 years ago • 3 comments

This has for the most part gone quite smoothly, the log4j 1.2 bridge is available to continue supporting the existing log4j 1.2 xml configurations which we have tested. Also tested the harvester logging continues to work as expected (where it programmatically adds an file appender).

Phase 1:

  • [x] introduce log4j2-core
  • [x] bridge slf4j to log4j2-core
  • [x] bridge java util logging to log4j2-core
  • [x] bridge apache commons logging to log4j2-core (done by spring-framework)
  • [x] Update LoggingAPI to list log4j 1.2 and log4j2 configuration files for selection
  • [x] Update LogUitl to support log4j2 configuration files
  • [x] double check status ability to view and download log file determined from file appender
  • [ ] double check harvester code that programatically adds an appender

Phase 2:

  • [x] Replace built-in log4j 1.2 configuration files (optional)
  • [ ] transition geonetwork codebase to log4j2-api (optioonal - a big search and replace)

jodygarnett avatar Jun 15 '22 13:06 jodygarnett

This work is going well, you can try running it right now using log4j-core backend.

One odd thing was core requiring use of bridge to slf4j 1.7 api for running apacheds; while the workers require a newer slf4j18 bridge to support slf4j1.8 api for camel.

jodygarnett avatar Jun 15 '22 13:06 jodygarnett

@juanluisrp what do you think about doing this work in several steps? The use of log4j-core as a back end is now complete for example. If we merge this you could sort out your camel dependencies.

jodygarnett avatar Jun 16 '22 07:06 jodygarnett

You are welcome to merge 6397 as is; the part that does not work is the harvesters.

Log4j does not want us to dynamically create appenders as programmers; instead it strictly wants everything defined by the configuration (so the sys admin as control).

So the approach to use is to:

  1. make a thread context map with the name of the harvester
ThreadContext.put("harvester", name);
  1. in the configuration generate the log file name dynamically using the name of the harvester from the thread locale
<appenders>
    <File name="harvester" fileName="$${ctx:harvester}">
        <PatternLayout pattern="%-4r %d{${datestamp}} [%t] %-5level %logger{36} - %msg%n"/>
    </File>
</appenders>
  1. If that does not work we should try routing (which has a more complete example):
<Routing name="Routing">
  <Routes pattern="$${ctx:harvester}">

    <Route key="$${ctx: harvester}">
      <File name="harvester-default" fileName="logs/harvester.log">
        <PatternLayout>
	  <pattern>%d{ISO8601} [%t] %p %c{3} - %m%n</pattern>
        </PatternLayout>
      </File>
    </Route>

    <!-- value dynamically determines the name of the log file. -->
    <Route>
      <File name="harvester-${ctx: harvester}" fileName="logs/harvester-${ctx:harvester}.log">
	<PatternLayout>
	  <pattern>%d{ISO8601} [%t] %p %c{3} - %m%n</pattern>
	</PatternLayout>
      </File>
    </Route>
  </Routes>
</Routing>

Reference:

  • https://logging.apache.org/log4j/2.x/faq.html#separate_log_files
  • https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
  • https://logging.apache.org/log4j/2.x/manual/thread-context.html

jodygarnett avatar Jul 25 '22 07:07 jodygarnett

@fxprunayre there is nothing to be done here, I will wait for it to be merged

jodygarnett avatar Aug 30 '22 20:08 jodygarnett