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]
