Change to log4j2 logging library implementation for logging messages (components choose log4j 1.2 api or log4j 2 api to generate messages)

[jodygarnett]

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:

• introduce log4j2-core
• bridge slf4j to log4j2-core
• bridge java util logging to log4j2-core
• bridge apache commons logging to log4j2-core (done by spring-framework)
• Update LoggingAPI to list log4j 1.2 and log4j2 configuration files for selection
• Update LogUitl to support log4j2 configuration files
• 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:

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

Reference:

• https://logging.apache.org/log4j/2.x/manual/migration.html

[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]

@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]

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);

2. 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>

3. 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

[josegar74]

I have done minimal testing (harvesters, metadata creation, thesaurus, searches, pdf export) including the changes from jodygarnett#2 also and looks no, no issues found.

The application starts up now properly in Tomcat.

[josegar74]

Small typo in LogConofig

[jodygarnett]

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