You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Scott Deboy <sd...@comotivsystems.com> on 2004/12/02 16:33:05 UTC

RE: Unable to populate 'Class', 'Method', 'Line' and 'File' fields within Chainsaw

SocketAppender doesn't use a layout - socketAppender sends serialized logging events over the wire.

Are you using a log4j1.2.8 jar on the source side?

If so, you can't get location info fields in Chainsaw V2 using a SocketAppender - the serialization of events changed between 1.2.8 and 1.3.

You can receive events from a 1.2.8 SocketAppender, but only if the events don't contain location info.

If you're using a 1.2.8 jar on the source side, you can still get location info in Chainsaw by following these steps:
1. On the source side, define a FileAppender using a conversion pattern that includes line/file/method etc patterns.
2. In Chainsaw, define a LogFilePatternReceiver, specifying the URL to your log file and the logFormat (pattern) in the file (see the JavaDoc - available from Chainsaw's help menu, for info no how to configure a LogFilePatternReceiver).  
3. Don't forget to set 'tailing' to true if you want to view the events in Chainsaw as they are written to the file.

If you're using a 1.3 jar on the source side, add a 'locationInfo' param (set to true) to the SocketAppender configuration and Chainsaw will display location info.

Hope that helps

Scott

-----Original Message-----
From:	Currimbhoy Shahyan [mailto:Shahyan.Currimbhoy@siemens.com]
Sent:	Thu 12/2/2004 6:55 AM
To:	'Log4J Users List'
Cc:	
Subject:	Unable to populate 'Class', 'Method', 'Line' and 'File' fields within Chainsaw

I am using Chainsaw to view logs generated via Log4j however I can't seem to
get anything inside the 'Class', 'Method', 'Line' and 'File' fields within
Chainsaw. I seem to get '?' inside all those fields.
I am trying to set the layout using Conversion Pattern however it doesn't
seem to recognize it. No matter what I put in the conversion pattern, it
only populates the standard fields (level, logger, time, thread, message).
When I tried setting the Conversion pattern for the Console Appender, I can
view the correct values in the Class, Method, Line and File fields.
Is there something additional I need to do in order to view these fields
inside Chainsaw. I am using a normal SocketAppender with the following
snipet from Log4j.xml:

<!-- Chainsaw Client -->
	<appender name= "CHAINSAW_CLIENT" class=
"org.apache.log4j.net.SocketAppender" >
    	<param name= "RemoteHost" value= "165.226.223.135"/>
    	<param name= "Port" value= "4445" />
    	<layout class="org.apache.log4j.PatternLayout">
		<!-- NO MATTER WHAT I PUT IN THE CONVERSION PATTERN, IT HAS
NO EFFECT ON THE LOGS WITHIN CHAINSAW-->
			<param name="ConversionPattern" value="%c{2} %L %F
%C %M %p %m %n" />
		</layout>
    </appender >




-----Original Message-----
From: Adriano Labate [mailto:adriano.labate@sportaccess.com]
Sent: Thursday, December 02, 2004 6:44 AM
To: Log4J Users List
Subject: RE: Multiple DailyRollingFileAppender on the same file :
renaming fails


Hi,

I tested a log4j configuration where I have 2 DailyRollingFileAppender
pointing to the same physical file and having a different PatternLayout. The
first one is used by the root logger and the second one by an explicit
logger.

In my previous post, I used this configuration on a Oracle JVM, now on a
standard Sun JVM.

In both cases, when it's time to rollover the file, the renaming fails.

The reason is that each appender maintains a handle on the file resulting in
two handles, that creates a lock and the renaming always fails and the
previous log content is lost.

-----------------------------------------------------
Handle v2.2
Copyright (C) 1997-2004 Mark Russinovich
Sysinternals - www.sysinternals.com

java.exe           pid: 1876   C:\transferService.log
java.exe           pid: 1876   C:\transferService.log
-----------------------------------------------------

I wonder whether it is the correct behavior ? It seems to me that log4j has
a full control on its configuration and could handle this situation. Maybe
this could be fixed in version 1.3 ?

Adriano Labate


-----Message d'origine-----
De : Adriano Labate [mailto:adriano.labate@sportaccess.com]

Envoyé : mercredi, 1 décembre 2004 17:06
À : log4j-user@logging.apache.org
Objet : Multiple DailyRollingFileAppender on the same file : renaming fails

Hi,

I just resolved a problem with the DailyRollingFileAppender and I just want
to share my experience with others. If it can help someone...

When it was time to rollover the file, I got the error:

"log4j:ERROR Failed to rename [c:/temp/mspak/monitoring/transferService.log]
to [c:/temp/mspak/monitoring/transferService.log.2004-11-25.log]."

I search on Google for this error and found around 200 results and realized
that it was a problem for a lot of people.

As I use log4j with the Oracle JVM I supposed that it was an Oracle issue
with I/O or permissions. After a lot of discussions with the Oracle support,
it was definitely not the case.

I noted that a lot of discussions talked about the possibility that the file
has a handle on it that prevents log4j to rename the file.

To be sure I installed and run 2 tools from www.sysinternals.com : Handle
and Process Explorer.

Running Handle I got :

--------------
C:\>handle -u transferservice.log
Handle v2.2
Copyright (C) 1997-2004 Mark Russinovich
Sysinternals - www.sysinternals.com

oracle.exe         pid: 984    AUTORITE NT\SYSTEM
C:\TEMP\MSPAK\monitoring\transferService.log
oracle.exe         pid: 984    AUTORITE NT\SYSTEM
C:\TEMP\MSPAK\monitoring\transferService.log
--------------

There was indeed two handles on my log file. I double checked with Process
Explorer (a GUI app) and confirmed that Oracle maintained two handles on my
log file. Now I was sure that it was a file handle problem.

Then I got a flash and realized that in my log4j.xml configuration file I
have two daily rolling file appenders that pointed on the same physical
file.

I tried to keep only one of them. Retried and YES, there was now only one
handle on the file!
Tested the rollover and it finally worked!


My configuration file was :

--------------
    <!-- Daily Rolling File Appender -->
    <appender name="DRFA" class="org.apache.log4j.DailyRollingFileAppender">
        <param name="Threshold" value="DEBUG"/>
        <param name="File"
value="c:/temp/mspak/monitoring/transferService.log"/>
        <param name="DatePattern" value="'.'yyyy-MM-dd'.log'"/>
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d{dd.MM HH:mm:ss:SSS}
%-5p [%c] %m%n"/>
        </layout>
    </appender>

    <!-- Daily Rolling File Appender   WARNING: disabled because file
renaming fails!!!
    <appender name="DRFA-blankpattern"
class="org.apache.log4j.DailyRollingFileAppender">
        <param name="File"
value="c:/temp/mspak/monitoring/transferService.log"/>
        <param name="DatePattern" value="'.'yyyy-MM-dd'.log'"/>
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%m%n"/>
        </layout>
    </appender>
    -->
--------------

I have now a question:


I didn't tried to use that configuration outside of Oracle, is it wrong to
use 2 appenders pointing on the same file (windows xp) ?

I searched on the Gülcü log4j manual but didn't found anything. Has anyone
tried to use this kind of configuration ?

I know that the Oracle JVM handles the threading differently than the Sun
JVM, so it can also explain the problem.

Adriano Labate




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions

USA, Inc. and are intended only for the addressee(s). 

The information contained herein may include trade secrets or privileged or

otherwise confidential information.  Unauthorized review, forwarding, printing,

copying, distributing, or using such information is strictly prohibited and may

be unlawful.  If you received this message in error, or have reason to believe

you are not authorized to receive it, please promptly delete this message and

notify the sender by e-mail with a copy to Central.SecurityOffice@shs.siemens.com


Thank you

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org