Russell Bateman March 2022 last update:
If you're using something like Tomcat and you make changes to logging.properties, slf4j.properties, log4j.xml, logback.xml, etc., you'll find that they're not picked up. Not even always after you wait.
In my experience, for example, modifying the log level in logging configuration will never take hold and you must restart the consuming software, like Tomcat.
This happens during the build when JUnit tests are running. In your logback-test.xml, you have something like the following lines:
<configuration> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${catalina.base}/logs/catalina.out</file> <append>true</append> ...
Since ${catalina.base} isn't defined, it's a construct of the Tomcat distro filesystem, the result is that Logback creates this subdirectory so that it can fulfill its configuration requirement, i.e.: the creation of and writing to catalina.out in the "usual" place.
The solution is for logback-test.xml, your Logback configuration in the test scope, not for your production src/main/resources/logback.xml. Add the new macro below before the file appender that specifies catalina.out and change the macro in the appender as shown here:
<configuration> <property name="base.folder" value="${catalina.home:-./target}" /> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${base.folder}/logs/catalina.out</file> <append>true</append> ...
The result is that there will be a logs subdirectory created under your target (build) directory. This will be removed everytime you do
$ mvn clean ...
From log4j: abbreviate/shorten package names...
The logback pattern is: %logger{length}
The rightmost segment (classname on the path) (here, Bar) in a package name is never abbreviated even if its length is longer than the length option. Other segments of the package path may be shortened to at most a single character, but are never missing altogether.
