[logging] [PATCH] JDK 1.4 Logging

[Bob Herrmann]

On Tue, 2002-07-23 at 15:03, Bob Herrmann wrote:
> On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
> > 
> > I think there is a simpler solution for this class of problems, and 
> > that would also work with log4j and doesn't require _any_ API change.
> > ( only changes to the adapter implementations )
> > 
> > Any 'wrapper' will use:
> >   factory=LogFactory.getFactory();
> >
> >   factory.setAttribute( "commons-logging.wrapperClass", 
> > "[CLASSNAME-OF-WRAPPER]");
> >   factory.getLog(), etc.
> 

Hi.  This patch to commons logging allow you to specify which methods
in the call stack are uninteresting when using the JDK1.4 Logger. In
Tomcat this seems to be all methods named "log" and "internalLog."  This
is based on Costin's idea of uninteresting classes, but seems to work
better for method names (in Tomcat anyway.)

It is something of a back door.  It is primarily for projects that
are in the process of converting to using commons-logging.

Is this an acceptable change to commons-logging ?

Cheers,
-bob

P.S. this patch is updated from the one posted to tomcat-dev



Index: src/java/org/apache/commons/logging/impl/Jdk14Logger.java
===
RCS file: /home/cvspublic/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.4
diff -u -r1.4 Jdk14Logger.java
--- src/java/org/apache/commons/logging/impl/Jdk14Logger.java	17 Jul 2002 16:42:40 -	1.4
+++ src/java/org/apache/commons/logging/impl/Jdk14Logger.java	23 Jul 2002 20:49:11 -
@@ -65,8 +65,11 @@
 
 import java.util.logging.Level;
 import java.util.logging.Logger;
+import java.util.Hashtable;
+import java.util.StringTokenizer;
 
 import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
 
 
 /**
@@ -95,6 +98,14 @@
 
 logger = Logger.getLogger(name);
 
+String wrapperMethods = (String) LogFactory.getFactory().getAttribute("commons-logging.wrapperMethods");
+if ( wrapperMethods != null ){
+StringTokenizer st = new StringTokenizer(wrapperMethods,",");
+while (st.hasMoreTokens()) {
+wrapperMethodsHash.put( st.nextToken(), "F" );
+}
+}
+
 }
 
 
@@ -106,6 +117,11 @@
  */
 protected Logger logger = null;
 
+/**
+ * The methods that we ignore in the stack trace
+ */
+private Hashtable wrapperMethodsHash = new Hashtable();
+
 
 // - Public Methods
 
@@ -116,10 +132,17 @@
 // Caller will be the third element
 String cname="unknown";
 String method="unknown";
-if( locations!=null && locations.length >2 ) {
-StackTraceElement caller=locations[2];
-cname=caller.getClassName();
-method=caller.getMethodName();
+if( locations!=null && locations.length>2 ) {
+StackTraceElement caller=null;
+for (int stackLevel=2;stackLevel

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
> 
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.

Ok, I experimented some with this.  I found that the "wrapperMethod"
(namely looking for method names "log()" and "internalLog()") are more
effective than a classname for identifying "uninteresting" stack frames.

Seems Tomcat has 71 classes with a method named "log()" and often
logs messages from within the class itself.

The attached "patch.txt is the Change to commons.

The CommonsLogger.java is a new tomcat logger that sends output
to the commons-logger.

Does this look good?

Cheers,
-bob



> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.
> 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



/*
 * $Header: $
 * $Revision: $
 * $Date: $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */


package org.apache.catalina.logger;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * Implementation of Logger that appends log messages to the
 * Commons logger 
 *
 * @version $Revision: $ $Date: $
 */

public class CommonsLogger
extends LoggerBase
implements Lifecycle {


// - Instance Variables


/**
 * The descriptive information abou

Re: JDK 1.4 Logging

[costinm]

On 22 Jul 2002, Bob Herrmann wrote:

> That is an interesting idea, although in my particular case, I walk
> the stack a variable amount. Namely if the stack has method "log()" or
> method "internalLog()" I keep unrolling the stack - this may not be
> a great idea - but it gives good stack traces without changing
> other parts of tomcat.

We'll walk a variable ammount as well - until the first class after 
wrapperClass ( i.e. we look for the caller of a method in wrapperClass ).

I don't think supporting wrappers which are wrapped by 
other wrappers is a goal :-)

Wrapping commons-logging ( which is a wrapper ) as a transition
mechanism should be enough.


> If a webapp wants to use its own logger wrapper, and the factory
> has a single attribute - would there be a conflict here?

That may be a problem. I'm not worried about webapps ( they 
shouldn't play with logger-wrapping :-), but about jasper
which may want to wrap as well.

There is a solution tough - add all the 'wrapperClass' 
passed to the factory to list, and check for any of them
when we un-wrap the stack. This will allow an unlimited number
of wrappers - as long as one wrapper doesn't call another wrapper
that wraps commons-logging, the wrapper. 

We should just use commons-logging - it is nice to have a 
smooth transition, but this should be just that, I don't 
think we should try to solve all the wrapping problems.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> On 22 Jul 2002, Bob Herrmann wrote:
> 
> 
>>This could be fixed by adding these methods to Log of commons-logger
>>
>> void trace(Object msg, Throwable thr, String className, String method);
>> void debug(Object msg, Throwable thr, String className, String method);
>> void info(Object msg, Throwable thr, String className, String method);
>> void warn(Object msg, Throwable thr, String className, String method);
>> void error(Object msg, Throwable thr, String className, String method);
>> void fatal(Object msg, Throwable thr, String className, String method);
> 
> 
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.
> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.

Looks good :) +1.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
>...
> I think there is a simpler solution for this class of problems, and 
> that would also work with log4j and doesn't require _any_ API change.
> ( only changes to the adapter implementations )
> 
> Any 'wrapper' will use:
>   factory=LogFactory.getFactory();
>
>   factory.setAttribute( "commons-logging.wrapperClass", 
> "[CLASSNAME-OF-WRAPPER]");
>   factory.getLog(), etc.
> 
> The classname of wrapper will be passed to the impl..
> 
>  - for log4j - this just gets passed further, since log4j already supports 
> this feature.
>  - for jdk1.4 or other loggers who don't support wrapping - there is 
> already code in Jdk14Logger that walks the stack trace. Curently it
> uses a hard-coded '2 levels up', but it can use the wrapperClass
>  and walk up to find it.

That is an interesting idea, although in my particular case, I walk
the stack a variable amount. Namely if the stack has method "log()" or
method "internalLog()" I keep unrolling the stack - this may not be
a great idea - but it gives good stack traces without changing
other parts of tomcat.

If a webapp wants to use its own logger wrapper, and the factory
has a single attribute - would there be a conflict here?

-bob





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[costinm]

On 22 Jul 2002, Bob Herrmann wrote:

> This could be fixed by adding these methods to Log of commons-logger
> 
>  void trace(Object msg, Throwable thr, String className, String method);
>  void debug(Object msg, Throwable thr, String className, String method);
>  void info(Object msg, Throwable thr, String className, String method);
>  void warn(Object msg, Throwable thr, String className, String method);
>  void error(Object msg, Throwable thr, String className, String method);
>  void fatal(Object msg, Throwable thr, String className, String method);

I think there is a simpler solution for this class of problems, and 
that would also work with log4j and doesn't require _any_ API change.
( only changes to the adapter implementations )

Any 'wrapper' will use:
  factory=LogFactory.getFactory();
   
  factory.setAttribute( "commons-logging.wrapperClass", 
"[CLASSNAME-OF-WRAPPER]");
  factory.getLog(), etc.

The classname of wrapper will be passed to the impl..

 - for log4j - this just gets passed further, since log4j already supports 
this feature.
 - for jdk1.4 or other loggers who don't support wrapping - there is 
already code in Jdk14Logger that walks the stack trace. Curently it
uses a hard-coded '2 levels up', but it can use the wrapperClass
 and walk up to find it.


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 13:00, [EMAIL PROTECTED] wrote:
> I'm close to -1 on this patch.
> 
> I think the right long-term solution is to use commons-logging in
> all tomcat and jasper, and stop defining our interfaces.
> 
> I am +1 on fixing commons-logger, this will probably be
> usefull for other packages that switch to commons-logger.

I agree.  I originally implemented a commons-logger logger, but
the result wasn't very satisfying.  Mostly when the commons-logger
uses JDK1.4 it always shows my logger's class and method name.

This could be fixed by adding these methods to Log of commons-logger

 void trace(Object msg, Throwable thr, String className, String method);
 void debug(Object msg, Throwable thr, String className, String method);
 void info(Object msg, Throwable thr, String className, String method);
 void warn(Object msg, Throwable thr, String className, String method);
 void error(Object msg, Throwable thr, String className, String method);
 void fatal(Object msg, Throwable thr, String className, String method);

Although, the bigger problem is all the Loggers have unique features
and trying to squeeze them through the commons-logger API is going to
result in impedance mismatch.  Not sure what to do about this.

I can take stab at this little change (although it means touching
just about every class in commons-logging.)  Is it worth it?  Votes?

Cheers,
-bob




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> I'm close to -1 on this patch.
> 
> I think the right long-term solution is to use commons-logging in
> all tomcat and jasper, and stop defining our interfaces.
> 
> I am +1 on fixing commons-logger, this will probably be
> usefull for other packages that switch to commons-logger.

I share Costin's opinion on the subject: Tomcat should switch (over 
time) to commons-logging, not the individual loggers which are supposed 
to be abstracted by commons-logging.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 12:37, Remy Maucherat wrote:
> 
> Assuming people actually like the JDK 1.4 logger and think it's useful, 
> I like that solution better (there are flags, use them).

The JDK Logger is pretty cool. Although the default output is pretty
plain. I use it with my own formatter. My formatter is tweaked for
Tomcat - so it condenses some information and colorizes some
information.

This is a sample of its output,

http://hue.jadn.com:81/~bob/xdmp.png

My formatter is attached. It assumes an Xterm window sized to 175 or so.

Cheers,
-bob





package com.jadn;

import java.util.logging.Formatter;
import java.util.logging.Level;
import java.util.logging.LogRecord;
import java.util.Date;
import java.sql.Timestamp;

/*

 designed for a XTERM window of withd 175 (or so)


 INSTALL
 compile it
 jar it (ie. jar cf jadn.jar com/jadn/XTermFormatter.class)
 install it (cp jadn.jar $JAVA_HOME/jre/lib/ext/jadn.jar

 edit $JAVA_HOME/jre/lib/logging.properties  and comment out the SimpleFormatter
and add this one in,

#java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.formatter = com.jadn.XTermFormatter

 enjoy
*/

public class XTermFormatter extends Formatter {
/*
	  0	Black
	  1	Red
	  2	Green
	  3	Yellow
	  4	Blue
	  5	Magenta
	  6	Cyan
	  7	White
*/

// colors foreground/background (for xterm)
private static final String RESET = "\033[0m"; 
private static final String BOLD  = "\033[1m";

private static final String BLACK_WHITE  = "\033[30;47m";
private static final String RED_WHITE= "\033[31;47m";
private static final String GREEN_WHITE  = "\033[32;47m";
private static final String YELLOW_WHITE = "\033[33;47m";
private static final String BLUE_WHITE   = "\033[34;47m";
private static final String PINK_WHITE   = "\033[35;47m";
private static final String LTGREEN_WHITE= "\033[36;47m";

public synchronized String format(LogRecord lr){
	StringBuffer sb = new StringBuffer();


	// --  LOG: LEVEL

	Level level = lr.getLevel();
	if ( level == level.SEVERE )
	sb.append( RED_WHITE );
	else if ( level == level.WARNING )
	sb.append( YELLOW_WHITE );
	else if ( level == level.INFO )
	sb.append( BOLD+GREEN_WHITE );
	else if ( level == level.CONFIG )
	sb.append( PINK_WHITE );
	else if ( level == level.FINE )
	sb.append( BLUE_WHITE );
	else 
	sb.append( BLACK_WHITE );

	fill( sb, level.toString(), 5 );
	sb.append( RESET );
	sb.append( " " );


	// --  LOG: TIME STAMP 

Timestamp ts = new Timestamp(lr.getMillis());
	// -mm-dd hh:mm:ss.f
	// 0123456789012345678
	//   1
sb.append( ts.toString().substring(11, 19) );



	// --  LOG: LOGGER DOMAIN (or name of logger)

	sb.append( " " );
	sb.append( PINK_WHITE );
	String lgName = lr.getLoggerName();
	if ( lgName.length()>15){
	sb.append( ">" );
	sb.append( lgName.substring(lgName.length()-14) );
	} else {
	fill(sb, lgName, 15);
	}
	sb.append( RESET );
	sb.append( " " );


	// --  LOG: SOURCE CLASS AND METHOD

	String cname = shorten(lr.getSourceClassName());

	int lastDot = cname.lastIndexOf('.');
	if ( lastDot == -1 ){
	cname=BLUE_WHITE+cname+RESET;
	} else {
	cname=cname.substring(0,lastDot)+BLUE_WHITE+cname.substring(lastDot)+RESET;
	}
	cname += "." + lr.getSourceMethodName();

	fill( sb, cname, 60 );
	sb.append( " " );



	// --  LOG: MESSAGE AND EXCEPTION

	sb.append( lr.getMessage() );
	if (lr.getThrown() != null ){
	sb.append( " " );
	sb.append( lr.getThrown() );
	}

sb.append("\n");
	return sb.toString();
}


// try and shorten known names
private String shorten(String cname){
	if ( cname.startsWith( "org.apache.catalina" ) )
	cname = "o.a.c"+cname.substring("org.apache.catalina".length());
	if ( cname.startsWith( "org.apache" ) )
	cname = "o.a"+cname.substring("org.apache".length());
	return cname;
}


// fill with spaces until supplied string reaches requested minLen 
// (longer strings are passed through without being chopped)
private void fill( StringBuffer sb, String toAdd, int minLen ){
	sb.append(toAdd);
	int fillTo = minLen - toAdd.length();
	while (fillTo-->0 )
	sb.append(" ");
}

}




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[costinm]

I'm close to -1 on this patch.

I think the right long-term solution is to use commons-logging in
all tomcat and jasper, and stop defining our interfaces.

I am +1 on fixing commons-logger, this will probably be
usefull for other packages that switch to commons-logger.


Costin


On 22 Jul 2002, Bob Herrmann wrote:

> 
> Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> 
> I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> calls to commons-logging Log.  This was unsatisfying because the
> commons-logger unrolls the stack and logs the "class.method" of my
> logger, not my logger's caller. 
> 
> I was tempted to change the commons-logger to allow for specifying
> a class and method on all its methods, but that would be a large
> change the commons-logger (involving changes and decisions about
> how this new information should be pushed down and handled with
> the other loggers it supports.)  There is also some issues mapping
> tomcat verbosity levels, to common-logger log levels and then to JDK
> Logger levels.
> 
> So I punted and implemented the code below.  It is a
> "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> It allowed me to unroll the stack in a way that fits well with
> tomcat (ignoring stack frames calling with method log() or method
> internalLog() which are uninteresting.)  And allowed me to map
> verbosity to JDK Levels.
> 
> Cheers,
> -bob
> 
> 
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: JDK 1.4 Logging

[Patrick Luby]

Bob,

That would work. I forgot that Remy now puts out a JDK 1.4 build of 
Tomcat and using the build flags would allow it to be picked up by users 
of the JDK 1.4 builds.

Patrick

Bob Herrmann wrote:
> Humm...  How about this instead (not that I am lazy)?
> 
> $ cvs diff -u catalina/build.xml
> Index: catalina/build.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
> retrieving revision 1.124
> diff -u -r1.124 build.xml
> --- catalina/build.xml29 Jun 2002 01:00:04 -  1.124
> +++ catalina/build.xml22 Jul 2002 16:31:07 -
> @@ -801,6 +801,8 @@
> unless="jdk.1.3.present"/>
> unless="jdk.1.3.present"/>
> +   +   unless="jdk.1.4.present"/>
> unless="compile.jmx"/>
> name="org/apache/naming/factory/DbcpDataSourceFactory.java" 
> 
> 
> On Mon, 2002-07-22 at 12:28, Patrick Luby wrote:
> 
>>Bob,
>>
>>This is a useful piece of code. However, your patch can't go into Tomcat 
>>as it will only compile with JDK 1.4. The standard builds of Tomcat that 
>>are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
>>should be run without crashing Tomcat on JDK 1.2.
>>
>>So, if you would like this in Tomcat (and I think it would be a nice 
>>optional logger implementation), I think that you need to do the following:
>>
>>1. Remove all of the following import statements and replace them with
>>reflection calls so that the JDK 1.3 compiler can compile this class:
>>
>>import java.util.logging.Logger;
>>import java.util.logging.Level;
>>import java.util.logging.Formatter;
>>import java.util.logging.Handler;
>>import java.util.logging.LogRecord;
>>
>>2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
>>when the code is run on JDK 1.2 or 1.3.
>>
>>Patrick
>>
>>
>>
>>
>>Bob Herrmann wrote:
>>
>>>Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
>>>
>>>I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
>>>calls to commons-logging Log.  This was unsatisfying because the
>>>commons-logger unrolls the stack and logs the "class.method" of my
>>>logger, not my logger's caller. 
>>>
>>>I was tempted to change the commons-logger to allow for specifying
>>>a class and method on all its methods, but that would be a large
>>>change the commons-logger (involving changes and decisions about
>>>how this new information should be pushed down and handled with
>>>the other loggers it supports.)  There is also some issues mapping
>>>tomcat verbosity levels, to common-logger log levels and then to JDK
>>>Logger levels.
>>>
>>>So I punted and implemented the code below.  It is a
>>>"o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
>>>It allowed me to unroll the stack in a way that fits well with
>>>tomcat (ignoring stack frames calling with method log() or method
>>>internalLog() which are uninteresting.)  And allowed me to map
>>>verbosity to JDK Levels.
>>>
>>>Cheers,
>>>-bob
>>>
>>>
>>>
>>>
>>>
>>>
>>>/*
>>> * $Header: $
>>> * $Revision: $
>>> * $Date: $
>>> *
>>> * 
>>> *
>>> * The Apache Software License, Version 1.1
>>> *
>>> * Copyright (c) 1999 The Apache Software Foundation.  All rights
>>> * reserved.
>>> *
>>> * Redistribution and use in source and binary forms, with or without
>>> * modification, are permitted provided that the following conditions
>>> * are met:
>>> *
>>> * 1. Redistributions of source code must retain the above copyright
>>> *notice, this list of conditions and the following disclaimer.
>>> *
>>> * 2. Redistributions in binary form must reproduce the above copyright
>>> *notice, this list of conditions and the following disclaimer in
>>> *the documentation and/or other materials provided with the
>>> *distribution.
>>> *
>>> * 3. The end-user documentation included with the redistribution, if
>>> *any, must include the following acknowlegement:
&

Re: JDK 1.4 Logging

[Remy Maucherat]

Bob Herrmann wrote:
> Humm...  How about this instead (not that I am lazy)?
> 
> $ cvs diff -u catalina/build.xml
> Index: catalina/build.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
> retrieving revision 1.124
> diff -u -r1.124 build.xml
> --- catalina/build.xml29 Jun 2002 01:00:04 -  1.124
> +++ catalina/build.xml22 Jul 2002 16:31:07 -
> @@ -801,6 +801,8 @@
> unless="jdk.1.3.present"/>
> unless="jdk.1.3.present"/>
> +   +   unless="jdk.1.4.present"/>
> unless="compile.jmx"/>
> name="org/apache/naming/factory/DbcpDataSourceFactory.java" 

Assuming people actually like the JDK 1.4 logger and think it's useful, 
I like that solution better (there are flags, use them).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: JDK 1.4 Logging

[Bob Herrmann]

Humm...  How about this instead (not that I am lazy)?

$ cvs diff -u catalina/build.xml
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -u -r1.124 build.xml
--- catalina/build.xml  29 Jun 2002 01:00:04 -  1.124
+++ catalina/build.xml  22 Jul 2002 16:31:07 -
@@ -801,6 +801,8 @@
unless="jdk.1.3.present"/>
   
+  
   
Bob,
> 
> This is a useful piece of code. However, your patch can't go into Tomcat 
> as it will only compile with JDK 1.4. The standard builds of Tomcat that 
> are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
> should be run without crashing Tomcat on JDK 1.2.
> 
> So, if you would like this in Tomcat (and I think it would be a nice 
> optional logger implementation), I think that you need to do the following:
> 
> 1. Remove all of the following import statements and replace them with
> reflection calls so that the JDK 1.3 compiler can compile this class:
> 
> import java.util.logging.Logger;
> import java.util.logging.Level;
> import java.util.logging.Formatter;
> import java.util.logging.Handler;
> import java.util.logging.LogRecord;
> 
> 2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
> when the code is run on JDK 1.2 or 1.3.
> 
> Patrick
> 
> 
> 
> 
> Bob Herrmann wrote:
> > Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> > 
> > I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> > calls to commons-logging Log.  This was unsatisfying because the
> > commons-logger unrolls the stack and logs the "class.method" of my
> > logger, not my logger's caller. 
> > 
> > I was tempted to change the commons-logger to allow for specifying
> > a class and method on all its methods, but that would be a large
> > change the commons-logger (involving changes and decisions about
> > how this new information should be pushed down and handled with
> > the other loggers it supports.)  There is also some issues mapping
> > tomcat verbosity levels, to common-logger log levels and then to JDK
> > Logger levels.
> > 
> > So I punted and implemented the code below.  It is a
> > "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> > It allowed me to unroll the stack in a way that fits well with
> > tomcat (ignoring stack frames calling with method log() or method
> > internalLog() which are uninteresting.)  And allowed me to map
> > verbosity to JDK Levels.
> > 
> > Cheers,
> > -bob
> > 
> > 
> > 
> > 
> > 
> > 
> > /*
> >  * $Header: $
> >  * $Revision: $
> >  * $Date: $
> >  *
> >  * 
> >  *
> >  * The Apache Software License, Version 1.1
> >  *
> >  * Copyright (c) 1999 The Apache Software Foundation.  All rights
> >  * reserved.
> >  *
> >  * Redistribution and use in source and binary forms, with or without
> >  * modification, are permitted provided that the following conditions
> >  * are met:
> >  *
> >  * 1. Redistributions of source code must retain the above copyright
> >  *notice, this list of conditions and the following disclaimer.
> >  *
> >  * 2. Redistributions in binary form must reproduce the above copyright
> >  *notice, this list of conditions and the following disclaimer in
> >  *the documentation and/or other materials provided with the
> >  *distribution.
> >  *
> >  * 3. The end-user documentation included with the redistribution, if
> >  *any, must include the following acknowlegement:
> >  *   "This product includes software developed by the
> >  *Apache Software Foundation (http://www.apache.org/)."
> >  *Alternately, this acknowlegement may appear in the software itself,
> >  *if and wherever such third-party acknowlegements normally appear.
> >  *
> >  * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
> >  *Foundation" must not be used to endorse or promote products derived
> >  *from this software without prior written permission. For written
> >  *permission, please contact [EMAIL PROTECTED]
> >  *
> >  * 5. Products derived from this software may not be called "Apache"
> >  *nor

Re: JDK 1.4 Logging

[Patrick Luby]

Bob,

This is a useful piece of code. However, your patch can't go into Tomcat 
as it will only compile with JDK 1.4. The standard builds of Tomcat that 
are downloadable from the jakarta.apache.org are built using JDK 1.3 and 
should be run without crashing Tomcat on JDK 1.2.

So, if you would like this in Tomcat (and I think it would be a nice 
optional logger implementation), I think that you need to do the following:

1. Remove all of the following import statements and replace them with
reflection calls so that the JDK 1.3 compiler can compile this class:

import java.util.logging.Logger;
import java.util.logging.Level;
import java.util.logging.Formatter;
import java.util.logging.Handler;
import java.util.logging.LogRecord;

2. Catch any ClassNotFound and MethodNotFound exceptions that will occur
when the code is run on JDK 1.2 or 1.3.

Patrick




Bob Herrmann wrote:
> Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> 
> I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> calls to commons-logging Log.  This was unsatisfying because the
> commons-logger unrolls the stack and logs the "class.method" of my
> logger, not my logger's caller. 
> 
> I was tempted to change the commons-logger to allow for specifying
> a class and method on all its methods, but that would be a large
> change the commons-logger (involving changes and decisions about
> how this new information should be pushed down and handled with
> the other loggers it supports.)  There is also some issues mapping
> tomcat verbosity levels, to common-logger log levels and then to JDK
> Logger levels.
> 
> So I punted and implemented the code below.  It is a
> "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> It allowed me to unroll the stack in a way that fits well with
> tomcat (ignoring stack frames calling with method log() or method
> internalLog() which are uninteresting.)  And allowed me to map
> verbosity to JDK Levels.
> 
> Cheers,
> -bob
> 
> 
> 
> 
> 
> 
> /*
>  * $Header: $
>  * $Revision: $
>  * $Date: $
>  *
>  * 
>  *
>  * The Apache Software License, Version 1.1
>  *
>  * Copyright (c) 1999 The Apache Software Foundation.  All rights
>  * reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  *
>  * 1. Redistributions of source code must retain the above copyright
>  *notice, this list of conditions and the following disclaimer.
>  *
>  * 2. Redistributions in binary form must reproduce the above copyright
>  *notice, this list of conditions and the following disclaimer in
>  *the documentation and/or other materials provided with the
>  *distribution.
>  *
>  * 3. The end-user documentation included with the redistribution, if
>  *any, must include the following acknowlegement:
>  *   "This product includes software developed by the
>  *Apache Software Foundation (http://www.apache.org/)."
>  *Alternately, this acknowlegement may appear in the software itself,
>  *if and wherever such third-party acknowlegements normally appear.
>  *
>  * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
>  *Foundation" must not be used to endorse or promote products derived
>  *from this software without prior written permission. For written
>  *permission, please contact [EMAIL PROTECTED]
>  *
>  * 5. Products derived from this software may not be called "Apache"
>  *nor may "Apache" appear in their names without prior written
>  *permission of the Apache Group.
>  *
>  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
>  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
>  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>  * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
>  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>  * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>  * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
>  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
>  * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>  * SUCH DAMAGE.
>  * 

RE: JDK 1.4 Logging

[Bob Herrmann]

On Mon, 2002-07-22 at 12:12, David Oxley wrote:
> Why does Tomcat not use Log4j for its logging?

Some parts of Tomcat do use Log4j, other parts do not.  I think
this is because different people have just chosen whatever
they felt was handy.   Tomcat doesn't yet have a unified logging
strategy.  I originally tried to use "commons-logging" as my
back-end and it can be configured to use Log4j, but as I described -
the result was unsatisfying.

Read this earlier thread on this topic,

 http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg28257.html


Cheers,
-bob

> 
> Dave.
> 
> > -Original Message-
> > From: Bob Herrmann [mailto:[EMAIL PROTECTED]]
> > Sent: 22 July 2002 15:51
> > To: Tomcat Developers List
> > Subject: JDK 1.4 Logging
> > 
> > 
> > Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> > 
> > I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> > calls to commons-logging Log.  This was unsatisfying because the
> > commons-logger unrolls the stack and logs the "class.method" of my
> > logger, not my logger's caller.
> > 
> > I was tempted to change the commons-logger to allow for specifying
> > a class and method on all its methods, but that would be a large
> > change the commons-logger (involving changes and decisions about
> > how this new information should be pushed down and handled with
> > the other loggers it supports.)  There is also some issues mapping
> > tomcat verbosity levels, to common-logger log levels and then to JDK
> > Logger levels.
> > 
> > So I punted and implemented the code below.  It is a
> > "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> > It allowed me to unroll the stack in a way that fits well with
> > tomcat (ignoring stack frames calling with method log() or method
> > internalLog() which are uninteresting.)  And allowed me to map
> > verbosity to JDK Levels.
> > 
> > Cheers,
> > -bob
> > 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: JDK 1.4 Logging

[David Oxley]

Why does Tomcat not use Log4j for its logging?

Dave.

> -Original Message-
> From: Bob Herrmann [mailto:[EMAIL PROTECTED]]
> Sent: 22 July 2002 15:51
> To: Tomcat Developers List
> Subject: JDK 1.4 Logging
> 
> 
> Hi.  I am trying to get Tomcat to log to JDK1.4's logging.
> 
> I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
> calls to commons-logging Log.  This was unsatisfying because the
> commons-logger unrolls the stack and logs the "class.method" of my
> logger, not my logger's caller.
> 
> I was tempted to change the commons-logger to allow for specifying
> a class and method on all its methods, but that would be a large
> change the commons-logger (involving changes and decisions about
> how this new information should be pushed down and handled with
> the other loggers it supports.)  There is also some issues mapping
> tomcat verbosity levels, to common-logger log levels and then to JDK
> Logger levels.
> 
> So I punted and implemented the code below.  It is a
> "o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
> It allowed me to unroll the stack in a way that fits well with
> tomcat (ignoring stack frames calling with method log() or method
> internalLog() which are uninteresting.)  And allowed me to map
> verbosity to JDK Levels.
> 
> Cheers,
> -bob
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

JDK 1.4 Logging

[Bob Herrmann]

Hi.  I am trying to get Tomcat to log to JDK1.4's logging.

I tried implementing a "o.a.c.logging.Logger" subclass that forwarded
calls to commons-logging Log.  This was unsatisfying because the
commons-logger unrolls the stack and logs the "class.method" of my
logger, not my logger's caller. 

I was tempted to change the commons-logger to allow for specifying
a class and method on all its methods, but that would be a large
change the commons-logger (involving changes and decisions about
how this new information should be pushed down and handled with
the other loggers it supports.)  There is also some issues mapping
tomcat verbosity levels, to common-logger log levels and then to JDK
Logger levels.

So I punted and implemented the code below.  It is a
"o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging.
It allowed me to unroll the stack in a way that fits well with
tomcat (ignoring stack frames calling with method log() or method
internalLog() which are uninteresting.)  And allowed me to map
verbosity to JDK Levels.

Cheers,
-bob




/*
 * $Header: $
 * $Revision: $
 * $Date: $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * <http://www.apache.org/>.
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */


package org.apache.catalina.logger;

import java.sql.Timestamp;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;

import java.util.logging.Logger;
import java.util.logging.Level;
import java.util.logging.Formatter;
import java.util.logging.Handler;
import java.util.logging.LogRecord;


/**
 * Implementation of Logger that sends log messages to the
 * Jdk logger 
 *
 * @version $Revision: $ $Date: $
 */

public class JdkLogger
extends LoggerBase
implements Lifecycle {


// - Instance Variables


/**
 * The descriptive information about this implementation.
 */
protected static final String info =
"org.apache.catalina.logger.JdkLogger/1.0";

/**
 * The lifecycle event support for this component.