Log4j – My Shitty Code https://myshittycode.com Embracing the Messiness in Search of Epic Solutions Fri, 06 Jan 2023 17:23:22 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.1 https://myshittycode.com/wp-content/uploads/2022/04/cropped-icon-32x32.png Log4j – My Shitty Code https://myshittycode.com 32 32 205304208 IntelliJ: Overriding Log4J Configuration Globally for JUnit https://myshittycode.com/2014/09/05/intellij-overriding-log4j-configuration-globally-for-junit/ https://myshittycode.com/2014/09/05/intellij-overriding-log4j-configuration-globally-for-junit/#respond Sat, 06 Sep 2014 02:55:39 +0000 http://myshittycode.com/?p=579 PROBLEM Most of the time, we may have several Log4J configurations depending on the environments, for example:- Since log4j.xml and log4j2.xml are the default configuration files for Log4J and Log4J2, these configurations will always be used unless we override the configuration file path. In another word, if we don’t override the configuration file path and […]

The post IntelliJ: Overriding Log4J Configuration Globally for JUnit appeared first on My Shitty Code.

]]> PROBLEM

Most of the time, we may have several Log4J configurations depending on the environments, for example:-

  • log4j.xml (Log4J) or log4j2.xml (Log4J2) – Production configuration using socket appender.
  • log4j-dev.xml (Log4J) or log4j2-dev.xml (Log4J2) – Development configuration using console appender.

Since log4j.xml and log4j2.xml are the default configuration files for Log4J and Log4J2, these configurations will always be used unless we override the configuration file path.

In another word, if we don’t override the configuration file path and we run our JUnit test cases offline from IntelliJ, it may take a very long time to execute them due to the broken socket connection. Further, it is not a good idea to clutter our production log files with non-production logs.

SOLUTION

To fix this, we need to configure IntelliJ to always use our development Log4J configuration.

First, on the menu bar, select Run -> Edit Configurations…

Then, delete all the existing JUnit configuration files.

Finally, expand Defaults -> JUnit.

Under VM options, specify the following system property:-

  • For Log4J, specify -Dlog4j.configuration=log4j-dev.xml
  • For Log4J2, specify -Dlog4j.configurationFile=log4j2-dev.xml

Please note the slight change on the system property name depending on the Log4J version.

Now, when we run our JUnit test cases from IntelliJ, it will always pick up the correct custom Log4J configuration file.

The post IntelliJ: Overriding Log4J Configuration Globally for JUnit appeared first on My Shitty Code.

]]> https://myshittycode.com/2014/09/05/intellij-overriding-log4j-configuration-globally-for-junit/feed/ 0 579 Managing Log4j Configuration for Both Development and Production Environments https://myshittycode.com/2013/09/04/managing-log4j-configuration-for-both-development-and-production-environments/ https://myshittycode.com/2013/09/04/managing-log4j-configuration-for-both-development-and-production-environments/#comments Wed, 04 Sep 2013 13:25:19 +0000 http://myshittycode.com/?p=25 PROBLEM Most of the time, we set the Log4j’s log levels to something lower (debug or info) during our local development. Once it is ready for production, we normally set the Log4j’s log levels to something higher (warn or even error) to prevent meaningless information from flooding the server log. One way to do this […]

The post Managing Log4j Configuration for Both Development and Production Environments appeared first on My Shitty Code.

]]> PROBLEM

Most of the time, we set the Log4j’s log levels to something lower (debug or info) during our local development. Once it is ready for production, we normally set the Log4j’s log levels to something higher (warn or even error) to prevent meaningless information from flooding the server log.

One way to do this is to manually adjust the log level(s) in log4.xml during our local development, for example:-

<!--?xml version="1.0" encoding="UTF-8" ?-->

<log4j:configuration>
    <!-- This appender logs to the console -->
    <appender name="consoleAppender" class="org.apache.log4j.ConsoleAppender">
        <param name="Target" value="System.out">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="[%-5p] [%c{1}] [%M:%L] - %m%n">
        </layout>
    </appender>

	<!-- Set "debug" log level for project code  -->
    <logger name="com.choonchernlim.myproject">
        <level value="debug">
    </level></logger>

	<!-- Set "info" log level for Spring framework  -->
    <logger name="org.springframework">
        <level value="info">
    </level></logger>

	<!-- Set "debug" log level for Hibernate framework  -->
    <logger name="org.hibernate">
        <level value="debug">
    </level></logger>

    <root>
    	<!-- The default log level is "warn" -->
        <priority value="warn">
        <appender-ref ref="consoleAppender">
    </appender-ref></priority></root>
</log4j:configuration>

Once we are ready for production, we will manually change the package specific log levels back to warn or comment them out, for example:-

<!--?xml version="1.0" encoding="UTF-8" ?-->

<log4j:configuration>
    <!-- this appender logs to the console -->
    <appender name="consoleAppender" class="org.apache.log4j.ConsoleAppender">
        <param name="Target" value="System.out">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="[%-5p] [%c{1}] [%M:%L] - %m%n">
        </layout>
    </appender>

	<!-- Comment out package specific log levels
    <logger name="com.choonchernlim.myproject">
        <level value="debug"/>
    </logger>

    <logger name="org.springframework">
        <level value="info"/>
    </logger>

    <logger name="org.hibernate">
        <level value="debug"/>
    </logger>
	-->

    <root>
		<!-- The default log level is "warn" -->
        <priority value="warn">
        <appender-ref ref="consoleAppender">
    </appender-ref></priority></root>
</log4j:configuration>

The problem with this approach is I always forget to make necessary changes in log4j.xml when I’m ready to package my project to be deployed in production.

SOLUTION

The solution that I come up with is rather simple. We will have two Log4j XML files under src/main/resources:-

  • log4j.xml
  • log4j-dev.xml

By default, assuming there’s no further Log4j configuration, log4j.xml will always get picked up by Log4j due to the default filename and its location. log4j-dev.xml will always be ignored by Log4j.

To ensure our local development picks up the configuration from log4j-dev.xml, we will need to make a minor tweak to the Jetty configuration in pom.xml:-

<project ...="">
	...
    <build>
        <plugins>
            <plugin>
                <groupid>org.mortbay.jetty</groupid>
                <artifactid>jetty-maven-plugin</artifactid>
                <version>8.1.8.v20121106</version>
                <configuration>
                    <systemproperties>
                        <!--
                        When Jetty runs, "log4j-dev.xml" will be used instead of
						"log4j.xml" because the latter is reserved for production
						usage.
                        -->
                        <systemproperty>
                            <name>log4j.configuration</name>
                            <value>log4j-dev.xml</value>
                        </systemproperty>
                    </systemproperties>
					...
                </configuration>
                <dependencies>
					...
                </dependencies>
            </plugin>
        </plugins>
    </build>
</project>

This way, when we run our local development on Jetty, log4j-dev.xml will be used. When we deploy the project in production, log4j.xml will be used instead.

The post Managing Log4j Configuration for Both Development and Production Environments appeared first on My Shitty Code.

]]> https://myshittycode.com/2013/09/04/managing-log4j-configuration-for-both-development-and-production-environments/feed/ 3 25