 | | | Renderers and Events | Renderers and Events 2003-05-27 - By Avner BenHanoch
Back
if you pass object to the logger debug/info/.. methods, then it is fine if
you don't supply a renderer, since log4j will call toString of your object
upon need. so it is the same as suppling a renderer.
If you pass a string, created by something like toString to log4j, then
you'll have decrese in performance. Sourrounding each call to the logger
with "if(logger.isDebugEnabled())" can solve part of the problem, with the
price of the reduction in readability of your code. However, there is still
another problem. Because you call 'toString' from your threads. If you
pass object instead of String, then the rendering (either by a registered
renderer or by toString) will take place in log4j threads. This can be
important, if you use AsyncAppender.
At any case, using a Renderer does not break the meaning of toString, since
there is no problem that 'toString' itself will use the Renderer.
Another reason for OR, is that you can configure it thru log4j configuration
file. This enables you to change the format of the log without needing to
compile anything.
bellow is a copy from log4j manual for your convinience:
-- ---- ---- ---- ---- ---- ---- ---- --
Object Rendering
Object rendering is a powerful and unique log4j feature. Log4j will render
the content
of the log messages according to user specified criteria. For example, if
you frequently
need to log oranges, an object type used in your current project, then you
can
register an OrangeRenderer that will be invoked whenever an orange object is
passed as the message parameter in a logging statement. The previously
registered
OrangeRenderer will be invoked to render a string representation of orange
objects.
Here is an (incomplete) example of how object rendering might work.
Orange orange = new Orange("89", "jaffa");
logger.debug("Here is how a rendered orange looks:");
logger.debug(orange);
Here is a possible outcome assuming the appropriate renderer and object
types were
properly registered.
4309 DEBUG [main] example.orange - Here is how a rendered orange looks:
4312 DEBUG [main] example.orange - jaffa brand, weighing 89 grams.
Object rendering follows the class hierarchy. For example, assuming oranges
are
fruits, if you register a FruitRenderer, all fruits including oranges will
be rendered
by the FruitRenderer, unless of course you registered an orange specific
OrangeRenderer.
Object renderers are required to implement the org.apache.log4j.or.Object-
Renderer interface. Log4j comes with a few useful renderers. For example,
you
can use the AttributesRenderer6 to render org.xml.sax.Attributes  objects.
-- ---- ---- ---- ---- ---- ---- ---- --
-- -- Original Message -- --
From: "Shapira, Yoav" <Yoav.Shapira@(protected)>
To: "Log4J Users List" <log4j-user@(protected)>
Sent: Tuesday, May 27, 2003 3:47 PM
Subject: RE: Renderers and Events
Howdy,
>Registering a Renderer should be used for classes that are often being
>logged.
I disagree. This is not a necessary, much less sufficient, criterion
for using a Renderer. Personally, I much rather have good toString()
methods for my classes, including complex classes. This is for two main
reasons:
- toString() is a lower common denominator and can be easily used
outside log4j for debugging, displaying state, etc. There are some
automated tools out there, such as profilers, which use toString() to
show object information that is invaluable, but these tools don't/can't
work with log4j (or any logging system outside their own).
- I surround debug-level logging with if(logger.isDebugEnabled())
clauses. If the logger is debug-enabled in production, that's because
I'm troubleshooting a problem and at that point I don't care about the
logging performance. Similarly, if it's a WARN / ERROR / FATAL message,
I don't care how long it takes to log, as the message itself is much
more important.
So obviously the use of Renderers is a design choice. I can see how
they'd be useful in the general case. However, every time I've started
using them I've always gone back to writing toString() methods.
Part of my reasoning is that I also think systems shouldn't be logging a
ton of stuff on a regular basis in production. In development and
testing, sure.
It's a tool in the log4j tool box. It may be useful for you, maybe not.
But I don't think the above quoted statement is true in general case:
don't use it as your sole guideline.
Yoav Shapira
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe, e-mail: log4j-user-unsubscribe@(protected)
For additional commands, e-mail: log4j-user-help@(protected)
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe, e-mail: log4j-user-unsubscribe@(protected)
For additional commands, e-mail: log4j-user-help@(protected)
Earn $52 per hosting referral at Lunarpages.
|
|
|