We are talking about two completely different things. The formatting of the LoggingEvent is done by the layout attached to a given appender. I was talking about object renderers which is a different topic.
On object rendering see: http://www.qos.ch/ac2001/F11-110.html (for these two links search for "renderer") http://jakarta.apache.org/log4j/docs/manual.html http://www.vipan.com/htdocs/log4jhelp.html The following thread is also very likely to help: http://marc.theaimsgroup.com/?t=103764346200005&r=1&w=2 Coming back to your question, actually I don't understand it. At 10:06 20.11.2002 +0000, you wrote:
> Message rendering is done prior to serialization. After serialization
> calling getMessage and getRenderedMessage always give the same result
> regardless of how you configure the server (receiving) side. Object
> rendering should be configured on the clients. HTH,
Hi Ceki,
I'd always assumed the message rendering would be provided by the appender
sending the LoggingEvent.
If I'd had an appender with a pattern layout such as [%-5p] [%d{DATE}]
[%C.%M] - %m%n, and made a
call such as log.debug("Hello World"), I'd expect two different strings in
the serialized LoggingEvent.
getMessage() would return Hello World, and
getRenderedMessage() would return [DEBUG] [20 Dec 2002 10:07:00,513]
[myClass.myMethod] - Hello World
If the rendering is provided on the client, then how can I render the
message?
Do I simply build it up using the components (using LocationInformation,
Message, Timestamp etc) or is there a utility class to help with this
rendering?
Regards,
Peter
********************************************************************
This email may contain information which is privileged or confidential. If you are not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person
Thank you
Check us out at http://www.syntegra.com
********************************************************************
-- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
