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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
