In the root hippo-cms7-project/pom.xml property <log4j.version>1.2.17</log4j.version> will be replaced with <log4j2.version>2.8.2</log4j2.version>.
This triggers and requires a huge set of additional changes, affecting almost all our product projects, as well as our downstream Hippo implementation projects!
The details/impact of these changes will be described further below, most notably the changes (rewrite) needed for all log4j.xml configuration files, as well the sometimes needed changes in (end project) downstream pom.xml files.
While this upgrade from log4j1 to log4j2 definitely is required for our own product projects, it still will remain possible, at least for the next v12 release, for Hippo implementation projects to keep using log4j1 as their logging implementation. That will require some other changes which will be described in the online documentation.
is replaced with:
and along the way, the slf4j version also is bumped to the latest:
is replaced with:
And the slf4j binding for log4j12:
is replaced with the binding now provided directly by log4j2:
Furthermore, for supporting specific log4j1 backwards-compatible implementation code (compilation), or for 3rd party dependencies which directly/only use log4j1 as logger
the following dependency is also added (test scope only!) to the global dependency management:
Log4j2 at startup now looks for a file named log4j2.xml instead of log4j.xml
Therefore all log4j.xml files (and derivates, like log4j-dev.xml and log4j-prod.xml) in the source trees have been renamed accordingly to log4j2.xml (and likewise log4j2-dev.xml and log4j2-prod.xml).
Besides the needed rewrite of the log4j configuration itself, for which the online log4j2 migration manual should be consulted,
the default log4j2-dev.xml and log4j2-prod.xml files provided by the hippo project archetype (see also below) can be reviewed and compared against the earlier log4j-dev.xml and log4j-prod.xml as a guideline.
Most notable changes are the new log4j2 filters provided by Hippo itself:
- the LookupFilter for context based filtering replacing the MdcOrJndiPropertyFilter, see -
- the re-implemented StringMatchFilter used for unit tests, see -
The system parameter through which you can configure log4j2 to use a specific configuration file has also changed!
Instead of using:
you now need to use:
This is a required change for all deployed environments, for example in Tomcat setenv.sh.
Note: when using a file: reference to the configuration file, make sure to use the file:// prefix, not the shorter file: which did work with log4j1 but no longer works with log4j2 on Windows!
for more background. CMS-10711
In the cargo.run profile of the Hippo project archetype this results in the following change from the old log4j1 parameter configuration:
to the new log4j2 parameter configuration (note again the required file:// prefix):
More specific changes in the Hippo project archetype are described further below.
In addition, the way the log4j2 LogManager works in multi 'context' environments has changed (by default).
Effectively this means that by default separate logging contexts are maintained per web application when Hippo is deployed.
This also means that our standard LoggingServlet, through which you can dynamically change log level by default won't 'see' the aggregate of all existing log4j loggers.
To fix this, another new system parameter needs to be set to change the default log4j2 behavior:
See the log4j2 Logging Separation manual for additional background.
This parameter is already configured for all cargo-maven2-plugin usages in the root hippo-cms7-project pom.xml, so doesn't need additional configuration changes for running Hippo using cargo.
This is another required change (additional parameter to be set) for all deployed environments, again for example in Tomcat setenv.sh.
For existing Hippo projects based on the Hippo project archetype, the following upgrade changes are needed:
The archetype now provides and uses these log4j2 based configuration files instead of the old conf/log4j-dev.xml and conf/log4j-prod.xml files.
The now obsolete log4j1 log4j.dtd has been removed.
As already mentioned before, within the project root pom.xml cargo-run profile the log4j1 log4j.configuration system property needs to be changed, from:
In addition it is adviced to remove the rebel.log4j-plugin system property which no longer is functional (being log4j1 based).
Note: changing it to rebel.log4j2_plugin, which is supposed to work, doesn't seem to work anymore either.
A better and more generic solution is adding the attribute monitorInterval="5" to the log4j2 Configuration element in conf/log4j2-dev.xml, which is left to be decided by the project developers.
As the log4j2 dependencies are different, the configuration for building a distribution needs to be adjusted.
Within the project root pom.xml dist and (since v11) dist-with-content profiles, replace the log4j1 specific dependencies:
And for the maven assembly configuration two more changes are needed.
- in src/main/assembly/conf-component.xml replace:
- and in src/main/assembly/shared-lib-component.xml replace:
- The ExecuteOnLogLevel test utility has been dropped and replaced with Log4jInterceptor CMS-10708
- When using PowerMock, you need to use the @PowerMockIgnore("javax.management.")* annotation to prevent huge stacktrace dump reported from within log4j2!