Yes I have looked into those..however, it appears that when I want to log
to a remote server, I will be sending the string representation down the
wire, which I'd have to then parse into an object on the log server so I
can access the individual fields. It would be much more useful to send the
object down the wire so we can then work on the message object whether it
was local or remote.
- 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
Robert Bergstrom
<rbergstrom@isolution To: "'LOG4J Users Mailing List'"
<[EMAIL PROTECTED]>
scorp.com> cc:
Subject: RE: Design: How to do
the following with Log4j
07/25/2001 03:47 PM
Please respond to
"LOG4J Users Mailing
List"
Tim:
Have you looked into ObjectRenderer/RenderMap? They allow you to control
how a message is converted to a string. You could map each one of your
custom objects to a different renderer.
Log4j is configurable at runtime. It can watch its configuration files or
be configured programmatically.
The overhead associated with logging is covered in detail here:
http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/performance/Logging.html
If your system can handle the load, careful logging shouldn't impact the
system adversely.
HTH,
Robert Bergstrom
Solutions Architect
iSolutions Corp.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 25, 2001 1:09 PM
To: [EMAIL PROTECTED]
Subject: Design: How to do the following with Log4j
1. 3 custom "logevent" objects, one for each type to log: PAGE, TRADE, and
QUOTE
2. Each object shares a set of common fields and then each object has one
or two custom ones
3. We want to log the event to a remote log server from the client side and
not just locally if we choose. From what I've seen from the LoggingEvent,
the actual message is NOT serialized as a whole object, but rather its
string representation.
4. Support for generic logging of text to either the central server or
locally
5. Must handle a high load of requests, we sometimes get 1000+ requests per
second depending on traffic
6. Must be configurable at runtime
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
