I just got the latest from CVS and it says it doesn't recognize the %X char
on the PatternLayout..
I've tried %x{username} and that doesn't do anything but print out
{username}
I've also tried %X{username} and that gives an error saying unexpected char
____________________________________________________
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
tmulle@moneyn
et.com To: "LOG4J Users Mailing List"
<[EMAIL PROTECTED]>
cc:
08/06/2001 Subject: RE: Idea on how to make Log4J
more expandable during runtime.
04:13 PM
Please
respond to
"LOG4J Users
Mailing List"
Semmantini,
That's exactly what've I've done already..I've extending Category and
added methods like debug(Object message, Map extra) and then build my
custom LogEvent
object with those fields. In my LogEvent extension I have methods like
getXXX() and setXXX() so I can easily set them without having a huge
constructor. I've also extended PatternParser and PatternLayout to read
these new fields.
I was merely pointing out that I thought all this customization was
unnecessary and suggested a new approach to the Log4J architecture to
possibly eliminate all of the overhead of creating classes when a new
field(s) added.
It would appear now with the MDC I may be able to do what I want after all.
Although, I think my approach may still yield a smaller, cleaner codebase
since there would be no need for each custom PatternParser instance for
each field, it may appear that mine is too invasive to this or next release
of Log4J.
- 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 04:04 PM
Please respond to
"LOG4J Users Mailing
List"
Just one more thing,
I had seen that the cat.debug, info etc... all functions take an Object and
not necessarily only a String. I took advantage of that.
I have a calss extended from Category...say MyCategory. It has methods such
as Performance, Transaction. You can pass your own objects to these
methods.
In my case there is object which has a message, starttime and endtime. Then
when you create a logging event you can supply a String message and any
other params such as starttime etc.
-----Original Message-----
From: Seemantini Godbole
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,
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]
---------------------------------------------------------------------
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]
