Hello again,
Hmmm, well it looks like Ceki and I were thinking of the same thing all
along :-)
It looks like this makes things much easier, although I can see a
limitation of using "chars" for the PatternLayouts instead of strings. But
it looks like it is possible to just use %X{var} to do all the work now.
Question, if I use MDC, do I have to reset it before each call to log?
Example:
public class SomeClass {
..// get the Category to log to
MDC.put("i", new Integer(2));
MDC.put("user", "joe");
root.debug("hello");
}
public class SomeClass2 {
..// get the Category to log to
MDC.put("i", new Integer(2));
MDC.put("user", "doe");
root.debug("hello");
}
Will these be separate MDC's? or will one overwrite the other?
Also, same question for multiple logging statements in a single class.
Do I have to do something like?
public class SomeClass {
..// get the Category to log to
MDC.put("i", new Integer(2));
MDC.put("user", "joe");
root.debug("hello");
MDC.clear()???
MDC.put("user", "SomeUser");
root.debug("Logging in");
MDC.clear()??
MDC.put("command", "stop");
root.info("Stopping Server");
}
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
Seemantini Godbole
<SEEMANTINI.GODBOLE@get To: "'LOG4J Users Mailing
List'" <[EMAIL PROTECTED]>
there.com> cc:
Subject: RE: Idea on how to
make Log4J more expandable during runtime.
08/06/2001 03:54 PM
Please respond to
"LOG4J Users Mailing
List"
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:[EMAIL PROTECTED]]
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, [EMAIL PROTECTED] 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"
<[EMAIL PROTECTED]>
> 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ü
> <[EMAIL PROTECTED]> To: "LOG4J Users Mailing
List"
<[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>r
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
