----------------------------------------- (on vwall1)
email-body was scanned and no virus found
---------------------------------------------------------
Why not write a custom renderer for your class to render it in XML. Then
modify the server to handle the XML and do all of your logging from there.
Mark Russell
PNC
412-768-9603
tmulle@moneyn
et.com To: "LOG4J Users Mailing List"
<[EMAIL PROTECTED]>
cc:
08/08/2001 Subject: Re: Why isn't message
serializable in LoggingEvent?
01:33 PM
Please
respond to
"LOG4J Users
Mailing List"
----------------------------------------- (on vwall1)
email-body was scanned and no virus found
---------------------------------------------------------
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]
