Develop Reference

Configuring log4j under WebSphere Application Server

We have a bunch of applications being deployed on Webshere Application Server (WAS). Somewhere on the class path we have a very basic log4j.properties with that looks similar to below:
log4j.rootLogger=ERROR, FILE, CONSOLE
#
# CONSOLE appender is a ConsoleAppender
#
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%X{component} [%-5p] %c - %m%n
#
# FILE appender is a FileAppender
#
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=##%d{dd-MM-yyyy HH:mm:ss,SSS} %X{component} [%-5p] %c - %m%n
#
# MyApp Debug Levels.
#
log4j.logger.com.my.company.my.app=INFO
Note the missing log4j.appender.FILE.File File from our log4j.properties, This is configured art WAS level via Application Servers -> MyServer -> Logging and tracing -> JVM Logs with the file name set as below:
${SERVER_LOG_ROOT}/SystemOut.log
Changing the debug level works fine e.g. adding to the log4j.properties the following line will result in getting debug entries for MySpecialClass in the logs.
log4j.logger.com.my.company.my.app.MySpecialClass=DEBUG
That makes me conclude that my properties file is considered.
However we recently received a request that in addition to the normal log entries to output some special log entries (application error related logs) to a separate file. My initial thought was to add one more rolling file appender and leave that do the work. To my surprise it did not work, everything related to that appender was just ignored.
Then I thought this may be because the log file is configured in WAS and everything goes there regardless of what we put in the log4j.properties and I said it looks a bit odd to have multiple apps writing to the same log file. However I did not want to spend too much time on this and because the special log entries were the error ones I just said lets just use the existing WAS feature of having a separate file for System.Err logs: Application Servers -> MyServer -> Logging and tracing -> JVM Logs:
${SERVER_LOG_ROOT}/SystemErr.log
To achieve this I created my own com.my.company.my.app.CustomPatternLayout and implemented this very basic format method:
public String format(LoggingEvent event) {
String log = patternLayout.format(event);
Level logLevel = event.getLevel();
if (Level.ERROR.equals(logLevel) || Level.WARN.equals(logLevel)
|| log.contains("Exception") || log.contains("PEM_LOGGER_SEV3")) {
System.err.println(log);
}
return log;
}
I also replaced the file appender in log4j.properties to use my custom pattern layout
log4j.appender.FILE.layout.com.my.company.my.app.CustomPatternLayout
Again nothing happened in my logs and the expected log entries never got written to the SystemErr.log. More than this I set some debug breakpoints and my code never gets executed. However if I remove my custom class from the class path i got some ClassNotFoundException log4j entries in the SystemErr.out which is a sign my configuration is read.
With no many ideas left the last thing I tried was to create a file called org.apache.commons.logging.LogFactory and have its content like below:
org.apache.commons.logging.impl.Log4jFactoryImpl
Our applications are running with a parent first class loading policy and we cannot change this.
This last attempt did not work either. Now I am out of ideas and can only help someone may bring some light in what am I missing.
Thank you in advance for your inputs.
UPDATE:
Actually I was wrong. If log4j is used to produce log entries then the CustomPatternLayout is used. It was only when the log entry was written by WAS that I could not my custom pattern being used. I think this is because WAS will use JDK java.util.logging.Logger. So my question would change to:
Is there a relatively easy way of intercepting WAS calls to writing log entries and apply a logic similar to the one I put in my custom pattern.
Thanks again for your inputs.

Rollover the logfile everyday irrespective if any messages is getting logged or not

I have below configuration in my log4j.properties
log4j.rootLogger=ERROR,FA
log4j.appender.FA=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.FA.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.FA.RollingPolicy.FileNamePattern=.\\logs\\app.log-%d{dd-MM-yyyy}
log4j.appender.FA.File=.\\logs\\app.log
log4j.appender.FA.layout=org.apache.log4j.EnhancedPatternLayout
log4j.appender.FA.layout.ConversionPattern=%d %p %t %c: %m%n
log4j.appender.FA.Append=true
There are days when no error is reported and file is not getting rolled at the next consecutive days till next error is reported. As appender is set to ERROR level it will not roll log file till some error message is reported .
My question is Can we develop some mechanism so that the file will be rolled every midnight irrespective if appender have some error messages to be logged or not ?
I have a java application and we are using log4j api for logging so solution in Java or Log4j both would be appreciated .
thanks in advance
Note:- I cannot set the logger level to Info/Debug because of the size constraint

Using the new CronTriggeringPolicy in Log4j 2.5, I found a solution without dummy lines, which I posted here. Unfortunately, it still requires some custom plugin code because the behaviour of the DefaultRolloverStrategy is to simply delete empty files.

As it is a log4j behaviour not to rollover the empty file we have to use below approach
Have a written a thread and scheduled it for 12 hours which logs the dummy statement "This is a dummy message"
As the file is not empty now hence log4j takes care of rollover
and We send the log files every day we have decided to log a dummy statement after every 12 hours saying "This is a dummy message" , which has solved the problem of rollover.

Websphere with Logback logging to system out - formatting issue

I am using Logback in my application hosted on Websphere App Server. Logback is configured to log to System Out (and others are hesitant to change to a different file). The issue is that Websphere uses its own format for logging to System Out. Executing logger.debug("test") in my app yields:
[8/7/12 12:27:55:629 CDT] 0000003a SystemOut O DEBUG com.myapp... test
where everything up to the "O" is added by Websphere. The rest is from Logback
I have set up Logback to use the following pattern: %-5level %logger{36} - %msg%n so that I don't repeat timestamp and thread info which Websphere does on its own, but I am still annoyed that I can't fully customize the logging to System Out from within Logback.
I don't know a whole lot about logging best practices. Before, I have logged to separate files by web app, but for this project, I was told the System Out files are monitored by a third party and I should not change from using System Out. Is there any way to get around my issue given these requirements and tell Websphere not to mess with my System Out logging, or is the only solution to start logging to a different file? Thanks!

Your logback is configured to write messages to System.out. However, everything that is written to System.out is redirected by WebSphere and written to the SystemOut.log file with the same format as log messages produced by WebSphere, but with a severity indicator "O". It is not possible to change that.
Note that it is likely that the people who told you to use SystemOut.log actually meant that you should ensure that logging is done using WebSphere's log system so that messages are written with the correct category and severity and that log levels can be changed at runtime. Since WebSphere's log system is build on java.util.logging you should probably just replace logback by slf4j-jdk14 to satisfy their requirement.

I don't think you're going to be able to change the format. And if you could, it might break the current monitoring anyway.
I wonder if anyone would mind if you log to two loggers at the same time, SystemOut for the existing monitoring, and your own for a more readable format.

The problem is that Logback redirects the messages to console output instead of java.util.logging. Console output has no log levels and that's why WebSphere just writes "O".
We solved this by implementing a Logback appender that redirects logs to JUL (java.util.logging) instead. We convert Logback log levels to JUL levels (e.g. Logback "ERROR" is JUL "SEVERE").
We also wanted to use Websphere's trace options. If trace is enabled for a class/package pattern, you will see Logback DEBUG and TRACE messages in Websphere's trace.log. You can also check if the trace is enabled by calling Logback's isDebugEnabled() / isTraceEnabled().
See this answer with a full implementation:
https://stackoverflow.com/a/74386323/395879

Log4j daily rolling catalina.out without restarting Tomcat?

i am having trouble with configuring Log4j correctly. I was expecting Log4j to rotate my catalina.out file at midnight when configuring it like the following..
log4j.properties:
log4j.rootLogger=INFO, CATALINA
# Define all the appenders
log4j.appender.CATALINA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.CATALINA.File=/var/log/tomcat7/catalina.out
log4j.appender.CATALINA.Append=true
log4j.appender.CATALINA.Encoding=UTF-8
# Roll-over the log once per day
log4j.appender.CATALINA.DatePattern='.'yyyy-MM-dd-HH-mm'.log'
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern =%d{HH:mm:ss} %5p [%t] - %m%n
After configuring I restarted Tomcat and
everything is written to:
/var/log/tomcat7/catalina.out
To test my configuration i changed the current date time to like 23:59:59:
#ls -l /var/log/tomcat7/
-rw-r--r-- 1 tomcat7 tomcat7 5840 4. May 00:00 catalina.out
As you can see, it didnt rotate at midnight... (?)
When restarting Tomcat it works perfectly fine:
#ls -l /var/log/tomcat7/
-rw-r--r-- 1 tomcat7 tomcat7 5840 4. May 13:37 catalina.out
-rw-r--r-- 1 tomcat7 root 2395 4. May 00:00 catalina.out.*CURRENTDATE*.log
Is it even possible to rotate my logfiles without restarting Tomcat?
Thanks in advance,
Marley

There are three solutions for this problem:
change default tomcat logging façade that writes to catalina.out to for example: slf4j, with all the benefits that comes with using it and log4j.
configure system cron to run logrotate of tomcat log files
change default logging class from ConsoleAppender to FileAppender.
Benefits of solutions:
very flexible as the slf4j offers many options especially with log4j, that you use anyway.
simple and doesn't require touching tomcat configuration.
simple change of configuration that disables console output
Disadvantages:
require additional libraries, affects all applications that tomcat is hosting, requires replacing default configuration with log4j.
cron+logrotate works only in linux; it might be not as simple in windows with scheduler. Requires extra scripting in windows environment.
provides only simple backup with date. Date pattern cannot be set. Does not compress rotated files.
Solution for First issue, is described here
Solution for Second issue is described here
Solution for Third issue is described here
You can as well combine solutions. For example use crontab to gzip files that where created by changing catalina.out to other name.
I would also suggest to leave tomcat so it logs to catalina.out, and configure your application to different file with log4j. This way logs from tomcat that are not immaterial won't spam your logs.

Is it even possible to rotate my logfiles without restarting Tomcat?
Yes, if you're willing to work for it.
Your log4j configuration will only end up fighting with the standard shell redirection that bin/catalina.sh uses to redirect stdout to logs/catalina.out. You can't simply use log4j configuration to change how System.out behaves.
If you want to rotate conf/catalina.out you will have to take some alternative measures depending on how to launch Tomcat:
If you use jsvc to launch Tomcat and you are using commons-daemon 1.0.4 or later, then you can send SIGUSR1 to the jsvc process to re-open the log files. That will allow you to move the existing log file to another file (which just changes its name and continues to log to the new filename) and then do 'kill SIGUSR1': the original filename will then be re-opened and new logs messages will go to it.
If you use bin/catalina.sh to launch Tomcat, you can modify it so that it no longer does redirection and instead pipes output to a rolling-logger process like Apache httpd's rotatelogs or chronolog.

How to clear server.log in JBoss?

How do I clear JBoss' server.log file when JBoss is running? When I try to do
echo 1 > server.log
I get error msg that the file is being used by another program (JBoss). Is it possible to use a command-line tool (windows or linux(I do have CygWin)) or an application that I can write myself to clear that file?
P.S. I don't need that file to have 0kb, but I want it to have less than 100MB.

By default JBoss keeps the file locked, since it is writing log messages into it. It is locked as long as JBoss is running and I don't know of other way to release it than stopping JBoss itself.
To keep its size under control, you can modify your log configuration, which is by default in <server>/conf˛jboss-log4j.xml. You can specify the maximum size of a log file, and define what to do when that size is reached: roll over to a new file, truncate the existing one and start writing over it again, etc.
A basic example (not tested, so no guarantee that it works straight as it is):
<appender name="ROLL" class="org.apache.log4j.rolling.RollingFileAppender">
...
<param name="maxFileSize" value="100MB" />
...
</appender>
Moreover, with the maxBackupIndex parameter you may define the number of backup files (default is 1).

JBoss locks the file as long as the logging process is running.
If you enabled the JMX console you can stop the logging, delete / modify the log, and start the logging service again.
The url should look something like this (for log4j):
http://jboss.example.com:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Atype%3DLog4jService%2Cservice%3DLogging
I tested this with JBoss 5.
This solution should be scriptable as well.
Regarding your log file size problem: You should use a configuration approach instead of editing the log file manually.