What I think would be nice is if LoggingEvent stored a Map object that we
could then pass into it from the logging methods. I've asked about this
before and then Ceki told me about the MDC. I have seen the latest
LoggingEvent source and it does store MDC as a hashtable in the
LoggingEvent. But I don't think this will satisfy my requirements at this
time.
I need to support adding/removing fields to log as easily as possible.
Would it be of any benefit to other if we could do something like or am I
just wanting too much?
Category cat = Category.getInstance("logger");
Map fields = new HashMap();
fields.put("user", "joe");
fields.put("age", new Integer(26));
cat.debug("User info:", fields);
then on the server side I could do in my render or appenders:
Map fields = LoggingEvent.getDataMap();
// Format my fields..etc..
I think this would be very handy in the PatternParsers, etc...
____________________________________________________
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: Why isn't message
serializable in LoggingEvent?
08/08/2001 02:36 PM
Please respond to
"LOG4J Users Mailing
List"
Well, am I correct in understanding?....but I think renderer will take the
entire object and produce a string representation. Do other people have
needs such as producing a log with pattern..
%d %p %m{duration} %m{userid} %c %m%n.....where duration and userid are
set
in that message.
I also am a little bit confused as to how MDC could be used for this
purpose, I think it is close, but it is not excatly what I want. MDC
records
info per thread, which means it will have a userid for the life of the
thread unless you want to constantly keep track of clearing an earlier
value
and setting a new one.
Whereas setting name-value in the message gives you a very granular, use
and
throw kind of a control on per message on not on per thread basis.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 08, 2001 12:34 PM
To: LOG4J Users Mailing List
Subject: Re: Why isn't message serializable in LoggingEvent?
OK, here is what I've been tasked to come up with:
Client API
- Support a generic logging api on the client
- Logging must be able to be sent to a remote log server
- Logging must be able to be sent to additional targets (file, console,
etc)
- Support custom logging event types with various numbers of parameters
- Support dynamic configuration at runtime
Server API (Log Server)
- Will be used for general purpose logging (debug, info, error, etc) as
well as custom auditing, quote hit counting, page hit counting and others
- Listen on individual protocols for logging requests (JMS, TIBCO, etc)
- Define logging targets based on event ids. Where based on the event
type, the log data will be sent to either file, db, console, etc.
- Process both CUSTOM and generic logging events
- Must be able to be used from NON-JAVA api's (I know this limits out
Serialization)
- Must be multithreaded
I know Log4j has the ability to do all of this, in fact I have a basic
protoype working, I'm just trying to find out the best way to support
flexibility and maintance of adding new LoggingEvents without having to
extend a ton of classes. I don't want to just say that EVERY user of the
system has to use the CUSTOM logevent and category class if I can help it.
I'd like to somehow maintain the interface that Log4J already defines for
me.
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
Don Taylor
<donald_l_taylor_jr@ To: LOG4J Users Mailing
List <[EMAIL PROTECTED]>
yahoo.com> cc:
Subject: Re: Why isn't
message serializable in LoggingEvent?
08/08/2001 12:54 PM
Please respond to
"LOG4J Users Mailing
List"
Because message is an Object and not all Objects are serializable.
Hence, they serialize the rendered message instead. I know you don't
want to do it this way, but the solution is to place the renderers on
the client, not the server. Is there any reason why the renderer can't
be placed on the client? (Other than it's harder to manage and
control?)
-- Don
--- [EMAIL PROTECTED] wrote:
> Hi,
>
> Question, what was the rationale behind not serializing the
> "message"
> field in the LoggingEvent? This would have been helpful so that we
> could
> send the object remotely to a Log server and then use Renderers on
> the
> server to format the message.
>
>
> 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]
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
---------------------------------------------------------------------
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]
