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]
