logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seemantini Godbole <SEEMANTINI.GODB...@getthere.com>
Subject RE: Idea on how to make Log4J more expandable during runtime.
Date Mon, 06 Aug 2001 19:54:47 GMT
Tim,

As Ceki pointed out, I do %x{userid/request/site} etc to log info that is
thread specific.

For performance and Transaction I have extended PatterLayout and
PatternParser class. Now I have to do %P{starttime} %P{endtime} %P{duration}
to get timings on the component.
The only problem/additional work with this approach is that you have to
create a logging event which knows/takes in additional properties such as
duration. Then you have to write patternConvertor classes which know how to
extract this info from the logging event.

Thx,
Seemantini

-----Original Message-----
From: Ceki Gülcü [mailto:cgu@qos.ch]
Sent: Monday, August 06, 2001 2:55 PM
To: LOG4J Users Mailing List
Subject: Re: Idea on how to make Log4J more expandable during runtime.


Tim,

Have a look at the latest code. The PatternLayout now has a conversion
character called X.

You can now write 

{
 Layout layout = new PatternLayout("%p [%t] user=%X{user} i=%X{i}- %m%n");
 Appender appender = new ConsoleAppender(layout);
 root.addAppender(appender);

 MDC.put("i", new Integer(2));
 MDC.put("user", "joe");

 root.debug("hello");
}
 
This will output

DEBUG [main] user=joe i=2 - hello

See also http://jakarta.apache.org/log4j/docs/plan.html 

Hope this makes it clearer, Ceki

At 15:34 06.08.2001 -0400, tmulle@moneynet.com wrote:
>Everyone,
>
>I want to make a clarification on the Pattern format in my first email..
>
>After looking at the PatternParser class documentation, I think it would be
>possible to keep it almost exactly the same format just using words instead
>of chars.
>
>Example:
>
>// Set up the pattern to print the new fields and some of the default
>fields
>// This would print something like:  "11:00:00 - Thread 0 [DEBUG] - Logging
>user info..., UserName=Joe Password=password"
>
>String pattern = "%date{HH:mm:ss} - %thread [%priority] - %message,
>UserName=%UserName Password=%PassWord";
>
>Now, I realize this would mean changing the PatternLayout and PatternParser
>classes to deal with words instead of characters, and I know it would
>probably be a major undertaking, but it's one I think may Log4j be even
>more flexible than before because now you don't need to extend classes to
>create individual PatternParsers, etc. I think a generic parser class can
>be created since the only thing the parser is now doing is pulling the
>fields directly from the LoggingEvents map of field values by name.
>
>This would make Log4J more dynamic at runtime, because if I wanted to add a
>new field to be logged I could simply add it to the map, pass it into the
>log method (debug, info, etc) and change the layout pattern to include the
>new field. Now instead of creating new classes, I've simply added 1 line of
>code and 1 line of text.
>
>Previous Example:
>
>// Create the category instance
>Category cat = Category.getInstance("TimsCat");
>
>// Create the new fields we want to log
>Map extraFields = new HashMap();
>
>extraFields.put("UserName", "Joe");
>extraFields.put("PassWord", "password");
>
>// Log the message
>cat.debug("Logging user info..", extra);
>
>
>New Example:
>
>// Create the category instance
>Category cat = Category.getInstance("TimsCat");
>
>// Create the new fields we want to log
>Map extraFields = new HashMap();
>
>extraFields.put("UserName", "Joe");
>extraFields.put("PassWord", "password");
>
>// We added a new field on the code
>extraFields.put("Address", "123 AnyStreet");
>
>// Log the message
>cat.debug("Logging user info..", extra);
>
>
>// New Pattern - This could/should be in an XML or properties file
>String pattern = "%date{HH:mm:ss} - %thread [%priority] - %message,
>UserName=%UserName Password=%PassWord Address=%Address";
>
>
>
>Hopefully this makes sense and people find it an improvement over the
>current architecture of Log4J. I do realize this is basically changing the
>way the whole product works, but I think it is something that can be done
>and will provide a more dynamic, flexible, and exapandable product in
>future versions. Maybe even JDK1.4 will want to use it.
>
>Anyway, I'm interested in feedback on this approach..the good, the bad, the
>ugly, etc.
>
>Thanks again,
>  - Tim
>
>
>____________________________________________________
>Timothy G. Mullé
>Senior Software Architect
>Reuters Valley Forge Solutions Center
>1000 Madison Avenue
>Norristown, PA 19403-2432
>
>Phone: (610) 650-8600 x8340
>Fax:      (610) 650-8170
>----- Forwarded by Timothy Mulle/ROL/NOR/US/Reuters on 08/06/2001 03:34 PM
>-----
>

>                    Timothy Mulle

>                                         To:     "LOG4J Users Mailing List"
<log4j-user@jakarta.apache.org>                      
>                    08/06/2001           cc:

>                    02:42 PM             Subject:     Re: Idea on how to
make Log4J more expandable during runtime.(Document     
>                                         link: Timothy Mulle)

>

>
>
>
>I've looked at the MDC.java class in the CVS repository and I must admit
>I'm not sure how this would help me. How would one use this class? How
>would I log the individual fields in the appenders? How would I send these
>values to a remote log server to log into a database?
>The only example I found was MDCStressTest.java and that didn't help
>
>Admittedly, I'm still new to Log4J and don't know much about NDC or MDC,
>but I think my proposal may be of benefit to others. It is true that my way
>would be more work, but I believe it is something that could be worked in
>as part of the foundation of Log4J.
>
>Any thoughts on this? Any ideas?
>
>- Tim
>
>____________________________________________________
>Timothy G. Mullé
>Senior Software Architect
>Reuters Valley Forge Solutions Center
>1000 Madison Avenue
>Norristown, PA 19403-2432
>
>Phone: (610) 650-8600 x8340
>Fax:      (610) 650-8170
>
>
>

>                    Ceki Gülcü

>                    <cgu@qos.ch>         To:     "LOG4J Users Mailing List"
<log4j-user@jakarta.apache.org>                     
>                                         cc:

>                    08/06/2001           Subject:     Re: Idea on how to
make Log4J more expandable during runtime.             
>                    02:07 PM

>                    Please

>                    respond to

>                    "LOG4J Users

>                    Mailing List"

>

>

>
>
>
>
>
>Hello,
>
>This is similar to the recently added MDC (MappedDiagnosticContext) class.
>See our CVS repository for more details. Regards, Ceki
>
>At 13:44 06.08.2001 -0400, you wrote:
>>Hello,
>>
>>     I was thinking, I think I've found a way that we can make Log4J
>>expandable at runtime in terms of adding attributes to the Category/Event
>>instead of extending classes.
>>What if the category class provided an optional method like this:
>>"debug(Object message, Map extra)" that took a map of the fields you want
>>associated with the Category/Event class.
>>Then we'd need a new Layout class that worked just like the PatternLayout
>>class but instead of "chars" it used word replacement. There could still
>be
>>"default" fields like date/time, thread, etc. but also allow for new ones.
>>The fields the PatternLayout uses to find the values would be the same
>>names as the ones in the Map passed to it.
>>The category class would then build a generic LogEvent message and hold
>>onto the new values and pass them around to the appenders/layouts as
>>normal, as long as the new Layouts know how to deal with the new patterns
>>
>>Here's an example of what I'm thinking..
>>
>>// Create the category instance
>>Category cat = Category.getInstance("TimsCat");
>>
>>// Create the new fields we want to log
>>Map extraFields = new HashMap();
>>
>>extraFields.put("UserName", "Joe");
>>extraFields.put("PassWord", "password");
>>
>>// Log the message
>>cat.debug("Logging user info..", extra);
>>
>>
>>Then on the PatternLayout would be something like..
>>
>>// Set up the pattern to print the new fields and some of the default
>>fields
>>// This would print something like:  "11:00:00 - Thread 0 [DEBUG] -
>Logging
>>user info..., UserName=Joe Password=password"
>>String pattern = "{$date}{HH:mm:ss} - {$thread} [{$priority}] -
>{$message},
>>UserName={$UserName} Password={$PassWord}";
>>
>>
>>This way we no longer need to extend any classes to add new fields to the
>>category/event, at least that is what I'm hoping for
>>
>>
>>What do you think? Does this sound like a good idea? Is there anything
>that
>>prevents this that I've missed?
>>
>>Thanks,
>>  - Tim
>>____________________________________________________
>>Timothy G. Mullé
>>Senior Software Architect
>>Reuters Valley Forge Solutions Center
>>1000 Madison Avenue
>>Norristown, PA 19403-2432
>>
>>Phone: (610) 650-8600 x8340
>>Fax:      (610) 650-8170
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>
>
>
>r
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org

--
Ceki Gülcü - http://qos.ch


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

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


Mime
View raw message