I just spent the better part of 3 hours trying to get my Rails application logging with Log4j. I've finally got it working, but I'm not sure if what I did is correct. I tried various methods to no avail until my very last attempt. So I'm really looking for some validation here, perhaps some pointers and tips as well -- anything would be appreciated to be honest. I've summarized all my feeble methods into three attempts below. I'm hoping for some enlightenment on where I went wrong with each attempt -- even if it means I get ripped up.
Thanks for the help in advance!
System Specs
Rails 3.0
Windows Server 2008
Log4j 1.2
Tomact 6.0.29
Java 6
Attempt 1 - Configured Tomcat to Use Log4J
I basically followed the guide on the Apache Tomcat website here. The steps are:
Create a log4j.properties file in $CATALINA_HOME/lib
Download and copy the log4j-x.y.z.jar into $CATALINA_HOME/lib
Replace $CATALINA_HOME/bin/tomcat-juli.jar with the tomcat-juli.jar from the Apache Tomcat Extras folder
Copy tomcat-juli-adapters.jar from the Apache Tomcat Extras folder into $CATALINA_HOME/lib
Delete $CATALINA_BASE/conf/logging.properties
Start Tomcat (as a service)
Expected Results According to the Guide
I should have seen a tomcat.log file in my $CATALINA_BASE/logs folder.
Actual Results
No tomcat.log
Saw three of the standard logs instead
jakarta_service_20101231.log
stderr_20101231.log
stdout_20101231.log
Question
Shouldn't I have at least seen a tomcat.log file?
Attempt 2 - Use default Tomcat logging (commons-logging)
Reverted all the changes from the previous setup
Modified $CATALINA_BASE/conf/logging.properties by doing the following:
Adding a setting for my application in the handlers line: 5rails3.org.apache.juli.FileHandler
Adding Handler specific properties
5rails3.org.apache.juli.FileHandler.level = FINE
5rails3.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5rails3.org.apache.juli.FileHandler.prefix = rails3.
Adding Facility specific properties
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rails3].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rails3].handlers = 4host-manager.org.apache.juli.FileHandler
Modified my web.xml by adding the following context parameter as per the Logging section of the jruby-rack README (I also modified my warbler.rb accordingly, but I opted to change the web.xml directly to test things faster).
<context-param>
<param-name>jruby.rack.logging</param-name>
<param-value>commons_logging</param-value>
</context-param>
Restarted Tomcat
Results
A log file was created (rails3.log), however there was no log information in the file.
Attempt 2A - Use Log4j with existing set up
I decided to give Log4j another whirl with this new web.xml setting.
Copied the log4j.jar into my WEB-INF/lib folder
Created a log4j.properties file and put it into WEB-INF/classes
log4j.rootLogger=INFO, R
log4j.logger.javax.servlet=DEBUG
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=${catalina.base}/logs/rails3.log
log4j.appender.R.MaxFileSize=5036KB
log4j.appender.R.MaxBackupIndex=4
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d{dd MMM yyyy HH:mm:ss} [%t] %-5p %c %x - %m%n
Restarted Tomcat
Results
Same as Attempt 2
NOTE: I used log4j.logger.javax.servlet=DEBUG because I read in the jruby-rack README that all logging output is automatically redirected to the javax.servlet.ServletContext#log method. So I thought this would capture it, but I was obviously wrong.
Question
Why didn't this work?
Isn't Log4J using the commons_logging API?
Attempt 3 - Tried out slf4j (WORKED)
A bit uncertain as to why Attempt 2A didn't work, I thought to myself, maybe I can't use commons_logging for the jruby.rack.logging parameter because it's probably not using commons_logging API... (but I was still not sure). I saw slf4j as an option. I have never heard of it and out of curiosity, I decided to look it up. After reading about it briefly, I thought it was as good of a shot as any and decided to try it out following the instructions here.
Continuing from the setup of Attempt 2A:
Copied slf4j-api-1.6.1.jar and slf4j-simple-1.6.1.jar into my WEB-INF/lib folder
I also copied slf4j-log4j12-1.6.1.jar into my WEB-INF/lib folder
Restarted Tomcat
And VIOLA! I now have logging information going into my rails3.log file.
So the big question is:
WTF?
Even though logging seems to be working now, I'm really not sure if what I did is right. So like I said earlier, I'm really looking for some validation more or less. I'd also appreciate any pointers/tips/advice if you have any. Thanks!
We also did various experiments and finally settled with slf4j option. Coming from Java background we knew slf4j, so we didn't go further.
<context-param>
<param-name>jruby.rack.logging</param-name>
<param-value>slf4j</param-value>
</context-param>
btw, there is no need to copy slf4j-simple-1.6.1.jar into tomcat/lib or WEB-INF/lib when using slf4j-log4jxxx.jar
It's possible that your early tests with commons-logging were showing zero bytes files because of bufferSize.
If your entries get flushed to the file when you stop Tomcat then this is indeed the case and you are falling foul of the default 8Kb buffer.
To disable, for immediate flushing try...
org.apache.juli.FileHandler.bufferSize = -1
on the specific handler...
So for localhost...
2localhost.org.apache.juli.FileHandler.bufferSize = -1
Related
My log config is as follows,but i can see only 1 backup file being created and all the other backup just goes off / deleted.
log4j.appender.application=org.apache.log4j.DailyRollingFileAppender
log4j.appender.application.File=${log.root.path}/test.log
log4j.appender.application.DatePattern='.'yyyy-MM-dd
log4j.appender.application.layout=org.apache.log4j.PatternLayout
log4j.appender.application.layout.ConversionPattern=%d{dd MMM
HH\:mm\:ss\:SSS} [%t] %-5p [%c\:%M\:%L] srcIp=%X{srcIp} -
remoteHost=%X{remoteHost} -port=%X{port} - activityType=%X{activitytype} -
activityStatus=%X{activitystatus} -applicationUser=%X{applicationUser} -
APITXNID=%X{apiTxnId} -CustomerRefNum=%X{CustomerRefNum} -%m%n%n
Your configuration looks fine, there are several thing you could try to do:
Try replace log4j.appender.application.DatePattern from '.'yyyy-MM-dd to '.'yyyy-MM-dd-HH-mm and see if files would be created every minute. If it works, chances are that some external cleanup script deletes old logs.
Add -Dlog4jdebug.true to VM options to verify what is effective log4j conf file is used.
Also consider using API Documentation warning
DailyRollingFileAppender has been observed to exhibit synchronization issues and data loss. The log4j extras companion includes alternatives which should be considered for new deployments and which are discussed in the documentation for org.apache.log4j.rolling.RollingFileAppender.
You can have the same effect as your config above, by replacing log4j dependency with apache-log4j-extras, which implements log4j 1.2.x, but has extra features, such as org.apache.log4j.rolling.RollingFileAppender with TimeBasedRollingPolicy
Then replace in your log4j.properties
log4j.appender.application=org.apache.log4j.DailyRollingFileAppender
log4j.appender.application.File=${log.root.path}/test.log
log4j.appender.application.DatePattern='.'yyyy-MM-dd
with
log4j.appender.application=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.application.rollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.application.rollingPolicy.FileNamePattern=${log.root.path}/test.log.%d{yyyy-MM-dd-HH-mm}
log4j.appender.application.File=${log.root.path}/test.log
How can I change the name of log4j.properties and the location of this as well?
You can change its location like so:
java -Dlog4j.configuration=file:/path_to_file_here/log4j.properties YourApplication
You should also read the manual.
Regarding changing the name, this is how you can achieve this:
First, you must add the following line to your java runtime command:
-Dlog4j.configuration=test.properties
For example lets assume you are using log4j in your web application deployed on Tomcat.
Add the above mentioned line in the java runtime command to start up Tomcat:
C:\Tools\java\j2sdk1.4.2_01\bin\java.exe -jar
-Duser.dir="C:\Tools\Tomcat 4.1"
-Dlog4j.configuration=test.properties
-Djava.endorsed.dirs="C:\Tools\Tomcat 4.1\common\endorsed"
"C:\Tools\Tomcat 4.1\bin\bootstrap.jar" start
You will also possibly want to read this.
I know this is a really old post, but the first thread when I searched for the question. And my found solution is:
System.setProperty("log4j.configurationFile", "theNameIWant.properties");
I have a problem with log4j loggin and I hope you can help me on this.
This is the scenario: I have 3 different applications (in other words 3 .jar) A, B and C. A is always running and from time to time calls B and C to execute them. Each of them have its own log4j.properties (with the path duly included in the MANIFEST) but Log4j only takes the properties of the main app A into consideration, ignoring the rest. I need to know if I can force Log4j to use for each app its own properties. I have seen something related using DOMConfigurator, but if I'm not wrong this only works with xml files and I'm using properties.
Thanks in advance
There are several Configurators, one of which is the PropertyConfigurator.
I need to know if I can force Log4j to use for each app its own properties.
Yes, you can. When you launch the applications B and C, define this system variable at their command line:
-Dlog4j.configuration=B.properties
where B.properties is the file name of log4j properties file in B's classpath. Likewise for application C.
Edit: found this: Change location of log4j.properties
I am trying to track down a problem with GWT. I get an error which I want to track down to the source but log4j truncates the stacktrace by indicating something like "... 26 more" hence I cannot determine the exact location for the problem. I tried finding out if there is anyway to prevent that truncation but have been unable to find any option that will accomplish that. Is this truncation a configurable feature?
I am running Tomcat 6.0.31, Spring 3.0 (for backend), GWT 2.1.0.
Thanks
It isn't log4j truncating the stack trace, it's standard Java. And it's actually only making the trace more readable because those lines that were omitted were already output by the 'enclosing' exception. See Throwable javadoc.
When I launch CruiseControl.NET with a particular configuration file I receive the following error:
ThoughtWorks.CruiseControl.Core.Config.ConfigurationException: Duplicate node detected
What does this mean, and what causes it?
I think you have 2 nodes in your config where it only expected one. Is there any chance you could post the config file it is throwing the exception on here as additional information? I'm using cruisecontrol (not the .net version) currently and find it can be very picky about it's XML files (rightly so) but not tell you anything about where in the file the exceptions were thrown from.
I found that I had an incorrectly structured config file. In particular, some blocks were outside of the configuration section. The error pointed to the second of these exec sections- apparently it didn't like that there was more than one of a given section inside the project.
Thus, the error occurred due a config file like this:
<project>
<tasks>
...
</tasks>
<exec>...</exec>
<exec>...</exec>
<project>
In my case I had something like:
<task>...</task>
<sourceControls>...</sourceControls>
<task>...</task>
<publishers>...</publishers>
It didn't like the two "<task>" nodes so I fixed it by removing the first "<task>" node. I was trying to do some stuff before getting the latest from svn, and then doing the build after that in the second "<task>" node. I'll need to revisit how to do that...any suggestions?