A more basic behavior can be had by simplifying the code above. You don't need a log4j.properties file.

package com.etretatlogiciels.samples.log4j;

import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;

public class Log4J
{
  private static Logger   logger = Logger.getLogger( Log4J.class.getName() );
  private SimpleLayout    myLayout;
  private Appender        myAppender;

  public Log4J()
  {
    logger.setLevel( Level.INFO );
    myLayout   = new SimpleLayout();
    myAppender = new ConsoleAppender( myLayout );
    logger.addAppender( myAppender );
  }

  public static void do_something( int a, float b )
  {
    double   X = b - a - 3.1415;

    logger.info ( "Parameters passed to method do_something are: " + a + ", " + b );
    logger.debug( "Operation performed successfully" );
    logger.error( "Value of X is " + X );
  }

  public static void main( String[] args )
  {
    BasicConfigurator.configure();
    do_something( 99, 542 );
  }
}

If you change the properties file above to use info in place of debug:

log4j.rootLogger=info, appender
log4j.appender.appender=org.apache.log4j.ConsoleAppender
log4j.appender.appender.layout=org.apache.log4j.DateLayout

...you get (in simple-layout mode):

INFO - Parameters passed to method do_something are: 99, 542.0
ERROR - Value of X is 439.8585

...and you're now missing the DEBUG log line because DEBUG is left off and ERROR is higher in value. (The appender puts out the level set to, plus all higher-valued levels). The levels in ascending order are:

1. DEBUG
2. INFO
3. WARN
4. ERROR
5. FATAL

To console, to file, to ?

We don't vary ConsoleAppender to FileAppender, JDBCAppender, SocketAppender, etc. in this sample because we want the output to go othe console for our demonstration. However, these are possibilities. What additional information must be supplied we don't yet know.

To change the "global" (whole application) logging level (from INFO to DEBUG, etc.), edit log4j.properties:

log4j.rootLogger=DEBUG, ...

It's important to understand levels and their effect on what's to be logged. If the event level is greater or equal to the logger's level, then that even is printed out (wherever and however its appender is supposed to put it out). Crudely put, if the even level is set to TRACE, then everything gets printed. Here's a table:

For example, if the event level is set to INFO, whose cell colors in the table above are highlighted green, the following logging statements would reach the log file:

• FATAL
• ERROR
• WARN
• INFO

...but, not DEBUG or TRACE.

In logback.xml or whatever configuration file you're using, INFO is set thus:

<logger name="com.etretatlogiciels" level="INFO" additivity="false">
  <appender-ref ref="CONSOLE"/>
</logger>

The properties file (or the .xml variant) can be used to set the logging level for classes individually.

log4j.logger.com.acme=DEBUG
log4j.logger.org.springframework=DEBUG
log4j.logger.javax.faces=TRACE
log4j.logger.org.apache.myfaces=TRACE
log4j.logger.com.sun.faces=INFO

log4j is particularly useful in web and distributed applications where using a debugger like the one in Eclipse is difficult or impossible. For Tomcat use, place log4j.properties where it will be copied down under the WEB-INF/classes subdirectory, for example, project-name/src.

Especially since I've switched to using IntelliJ IDEA, this raises its head again just a little bit.

For configuration, there's a pecking order. Apparently, log4j2-test.xml is sought in the classpath before log4j2.xml. Hmmm... I guess the way to ensure that the first one isn't found is to put it into src/test/ somewhere because those paths don't get included bu the build (ordinarily).

The configuration file may be added just about anywhere, but if not added to an existing path already in classpath, then its location must be configured into classpath of the IDE. This is really bad. The less configuration there is, the better, say I.

I see a statement to the effect that if my project uses Maven to build, then put log4j configuration on the path src/main/resources (and, likely, log4j2-test.xml on src/test/resources). However, this seems to be disputed. Others say to put it at the root of the src folder. The problem is that there are many, knee-jerk Eclipse heads and Eclipse used to ignore proper Java pathing (preferring src/... to src/main/java/...). So, I think "the root of src" for IntelliJ IDEA and properly sourced Maven paths would be src/main/java. This should be the root they're talking of. But, that's not where I'd like it. Here are some links to this confusing discussion:

• https://stackoverflow.com/questions/2772466/where-to-place-log4j-xml
• https://stackoverflow.com/questions/3765998/add-a-properties-file-to-intellijs-classpath
• https://stackoverflow.com/questions/5081316/where-is-the-correct-location-to-put-log4j-properties-in-an-eclipse-project
• https://stackoverflow.com/questions/23278607/using-simple-log4j-properties-in-my-java-code
• https://stackoverflow.com/questions/7390521/change-location-of-log4j-properties
• https://stackoverflow.com/questions/13372117/how-to-change-log4j-configuration-when-packaging

I put two files, log4j.xml and log4j-test.xml on src/main/resources and src/test/resources respectively. I find that the one for testing doesn't work. One answer said that I can only use a system property to differentiate, -Dlog4j.configuration=log4j[-test].xml.

Okay, I've sorted out all the nastiness of slf4j and log4j. It appears a) that slf4j doesn't play well with log4j2, so I stopped trying to use the newer version, b) I had to include the following dependencies in Maven. This consists of the latest slf4j and the latestf of log4j version 1 I can find without resorting to some alpha or beta stuff:

  <properties>
    <slf4j.version>1.7.7</slf4j.version>
    <log4j.version>1.2.17</log4j.version>
  </properties>
  .
  .
  .
  <dependencies>
    .
    .
    .
    <!-- log4j support for slf4j: -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>${slf4j.version}</version>
      <scope>test</scope>
    </dependency>
    <!-- slf4j proper: -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>${slf4j.version}</version>
    </dependency>
    <!-- log4j proper: -->
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>${log4j.version}</version>
    </dependency>
    .
    .
    .
  </dependencies>

...and here's what my log4j.xml file, which I'm placing on the path src/main/resources looks like. I've got more work to do on it because there's some brevity without sacrificing clarity I like to configure, but I haven't done that yet:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration debug="true">

  <appender name="console" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern"
             value="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n" />
    </layout>
  </appender>

  <appender name="file" class="org.apache.log4j.RollingFileAppender">
    <param name="append" value="false" />
    <param name="maxFileSize" value="10MB" />
    <param name="maxBackupIndex" value="10" />
    <param name="file" value="${catalina.home}/logs/mdht-restlet.log" />
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern"
             value="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n" />
    </layout>
  </appender>

  <root>
    <level value="TRACE" />
    <appender-ref ref="console" />
    <appender-ref ref="file" />
  </root>

</log4j:configuration>

I shamelessly ripped this off from the web for future use.

log4j.rootLogger=DEBUG,myAppender

log4j.appender.myAppender=org.apache.log4j.RollingFileAppender
log4j.appender.myAppender.file=/var/log/myapp.log
log4j.appender.myAppender.maxFileSize=10MB
log4j.appender.myAppender.maxBackupIndex=10
log4j.appender.myAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.myAppender.layout.ConversionPattern=%5p | %d | %F:%L | %m%n

log4j.logger.com.acme=DEBUG
log4j.logger.org.springframework=DEBUG
log4j.logger.javax.faces=DEBUG
log4j.logger.org.apache.myfaces=DEBUG
log4j.logger.com.sun.faces=DEBUG

It's possible, and simple, to change the logging level at runtime:

import org.apache.log4j.Level;
import org.apache.log4j.Logger;
...

{
  ...
  Logger root = Logger.getRootLogger();
  Level  level = Level.toLevel( "DEBUG" );

  root.setLevel( level );
  ...
}

I went over a complex logging scheme, such as the one illustrated above, and afterward noticed that all my JUnit tests were prefixed with the following.

log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /logs/catalina.out (No such file or directory)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.(FileOutputStream.java:212)
	at java.io.FileOutputStream.(FileOutputStream.java:136)
	at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
	at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
	at org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:223)
.
.
.

This turned out to be quite simple. When I was running my JUnit tests, the very explicit treatment of Tomcat and other logging I put into log4j.properties was asking Log4j to open files that didn't exist in the environment.

The solution was simply to put a separate copy of log4j.properties under the test subdirectory of my project (parallel to the origin one under the src subdirectory). The final result was something like:

log4j.rootLogger=TRACE,console
log4j.appender.console.Threshold=TRACE
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.layout=org.apache.log4j.SimpleLayout
log4j.appender.console.Target=System.out
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

This is different from how it was done in previous versions.

import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.config.Configuration;
import org.apache.logging.log4j.core.config.LoggerConfig;
.
.
.
  if( LOGGING )
  {
    // turn on logging to INFO level...
    LoggerContext ctx = ( LoggerContext ) LogManager.getContext( false );
    Configuration config = ctx.getConfiguration();
    LoggerConfig loggerConfig = config.getLoggerConfig( LogManager.ROOT_LOGGER_NAME );
    loggerConfig.setLevel( Level.INFO );
    ctx.updateLoggers();
 }
.
.
.

...doesn't recognize log4j.properties but XML, JSON and other formats. And the name is by default, log4j2. Here's a working sample:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration xmlns="http://logging.apache.org/log4j/2.0/config">
  <Properties>
    <Property name="LEVEL">trace</Property> <!-- Change to info in production -->
    <Property name="log-path">/var/log/search/</Property>
    <Property name="logfile-size">1 GB</Property>
    <Property name="cda-feeder">cda-feeder</Property>

    <!-- The console pattern gives calling method name and line numbers (%L). E.g.:
    TRACE | 2015-09-17 10:15:02 | [main] logging.Log4j2Example (Log4j2Example.java:38) - This will be printed on trace
      -->
    <Property name="console-pattern">%d{ABSOLUTE} %5p %c{1}:%L - %m%n</Property>

    <!-- The file pattern is shorter and more static; other differences are due simply to RollingFileAppender. E.g.:
    10:15:02,987 TRACE Log4j2Example: This will be printed on trace
      -->
    <Property name="file-pattern">   %d{ABSOLUTE} %5p %c{1}: %m%n    </Property>
  </Properties>

  <Appenders>
    <Console name="console" target="SYSTEM_OUT">
      <PatternLayout pattern="%-5p | %d{yyyy-MM-dd HH:mm:ss} | [%t] %C{2} (%F:%L) - %m%n" />
    </Console>

    <RollingFile name="rollingfile"
                 fileName="${log-path}/${cda-feeder}.log"
                 filePattern="${log-path}/${cda-feeder}-%d{yyyy-MM-dd}-%i.log"
                 append="true">
      <PatternLayout pattern="${file-pattern}" />
      <Policies>
        <SizeBasedTriggeringPolicy size="${logfile-size}" />
      </Policies>
      <DefaultRolloverStrategy max="4" />
    </RollingFile>
  </Appenders>

  <Loggers>
    <Logger name="root" level="${LEVEL}" additivity="false">
      <appender-ref ref="rollingfile" level="${LEVEL}" />
    </Logger>

    <Root level="${LEVEL}" additivity="false">
      <AppenderRef ref="console" />
      <AppenderRef ref="rollingfile" />
    </Root>
  </Loggers>

</Configuration>

A list of don'ts...

1. Don't log sensitive information.
2. Don't log too much (exhausting disk space).
3. Don't log cryptic messages (like, "Operation failed.").
4. Don't use a single log file.
5. Don't choose incorrect log levels.

FATAL for errors that cause the application to crash or fail to start.

ERROR for technical issues that need to be resolved for proper functioning of the system.

WARN for temporary problems or unexpected behavior that does not significantly hamper the functioning of the application.

INFO for messages that describe what is happening in the application.

DEBUG for messages that could be useful in debugging an issue.

TRACE, like DEBUG, but for more detailed events.

6. Don't crush performance with logging. Don't log during

   loops

   file I/O operations

   Bracket such code by a conditional like:

   if( logger.isTraceEnabled() )
     ...
   

7. Don't log to the console (except episodically, like early on, during test runs, etc.).

Here are some log4j layout ConversionPattern values and their effects (actual output forced by unit tests I've written for a product). The one marked below is my personal favorite, but it depends on what's being done, what's needed, etc.:

Note that removing the line number reduces in theory the amount of time logging takes since it obviates it from using reflection to determine it. According to Apache documentation, the following conversion specifiers will cause log4j to work harder (and run slower) in order to furnish the information requested:

While L is popular, since it's going to change a lot with bug fixes and refactoring, why put it out? It would really only be helpful in code that's too long and making lots of logging calls. Choosing wording carefully, and maybe adding an identifying code to logged statements would be even more useful than the line number if it came to that.

DEBUG [MessagingService-Outgoing-/10.10.10.134-Gossip] 2018-01-30 09:20:15,181 OutboundTcpConnection.java:545 -
Unable to connect to /10.10.10.134
java.net.ConnectException: Connection refused (Connection refused)
  at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_151]
  at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_151]
  at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[na:1.8.0_151]
  at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[na:1.8.0_151]
  at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0_151]
  at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_151]
  at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673) ~[na:1.8.0_151]
  at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:451) ~[na:1.8.0_151]
  at sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:137) ~[na:1.8.0_151]
  at org.apache.cassandra.security.SSLFactory.getSocket(SSLFactory.java:98) ~[cassandra-ss-index-plugin-3.11.0.13.jar:na]
  at org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:141) ~[cassandra-index-plugin-3.11.0.13.jar:na]
  at org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:132) ~[cassandra-index-plugin-3.11.0.13.jar:na]
  at org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:433) [cassandra-index-plugin-3.11.0.13.jar:na]
  at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:262) [cassandra-index-plugin-3.11.0.13.jar:na]

Before the JAR name in stack traces, there are tildes right before an opening square bracket. What does this mean?

At the end of each stack frame of the exception, a string consisting of the JAR file containing the relevant class followed by the "Implementation-Version" as found in that JAR's manifest will be added. If the information is uncertain, then the class packaging data will be preceded by a tilde, i.e. the '~' character.

logback and log4j go to great lengths to ensure that the class packaging information they display is correct. However, when they are unable to guarantee the absolute correctness of the information, then they will prefix the data with a tilde. Thus, it is theoretically possible for the printed class packaging information to differ from the real class packaging information.