Hi Ceki,
Re: BeanWrapper
I find the BeanWrapper the most useful, because it does not require the developer to
add anything to the bean. That decreases the overhead of writing the logging code. In
exchange, it increases the overhead of running it.. Having very low overhead for
adding logging code is very useful for me because I find myself working on other
people's code a lot these days, and having to debug obscure problems with that code, I
have been using log4j extensively to be able to follow what's going on. When adding
log statements to large amounts of other people's code, the quicker it happens the
best it is, in my experience..
Also when writing new code, you are more likely to add a log statement if it is a
minor "typing overhead" (not to mention maintenance overhead) than not. I think the
best solution might be to offer both possibilities, with the advice that if you are
using the BeanWrapper, you should surround your log statement with an if
(log.isDebugEnabled()) just like for string concatenation. On the other hand, if your
bean implements LoggableBean you don't need to. I think that would give the best of
both worlds, so when you're writing new code and you've got enough time you tag your
beans as LoggableBeans, and when you're hastily adding log statements to someone
else's code you can do so at the expense of an if() check with just a BeanWrapper.
For the rendering of it, I think the idea when outputting a bean's fields to the log
would be to show as much data as is available (within reason). Showing all available
public bean properties, and maybe truncating the ones which are too long, would be the
way I would expect such a renderer to work. Maybe this could be configurable from the
log4j config file (log4j.renderer.bean.truncateLength?)
Re: Generic ObjectRenderers
Yes, I think so. It encourages more logging, which I think is a good thing, and
removes "logging display logic" code. In an ideal world, log4j would become so closely
integrated with java that much code (such as log.debug("entering");) would be
automatically generated by the compiler or the VM! However until hell freezes over,
the closest we can get is to make it really easy for people to write log statements
and decrease maintenance time.
If I have time I'll probably write a few generic object renderers when I'm home. The
resultset one, for instance... most useful.
Daniel
PS: Btw, I've been meaning to say, thank you for writing log4j. I don't think I'd
stand a ghost of a chance of finishing this project on time if it wasn't for log4j and
the ease and flexibility with which I've been able to insert it all over the place to
figure out what this code was doing (and be able to turn the debugging on and off at
will). So thanks a lot for making this available :-)
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: 20 October 2003 15:11
To: Log4J Users List
Subject: Re: Useful Object Renderers
Hi Daniel,
Comments below.
At 11:55 AM 10/20/2003 +0100, [EMAIL PROTECTED] wrote:
>Hi all,
>
>I'm wondering whether there are any useful object renderers that I haven't
>heard about, hopefully downloadable and easily integratable. Things I'd be
>looking to output without having to have long debugging logic in my code
>would be beans, JDBC ResultSet rows, and so on. Looking around the log4j
>codebase all I can see is one jms and one sax renderers, both rather basic.
>
>It seems to me that this would be a very useful feature, improving the
>quality of usage practice with log4j. Just like layout patterns which
>allow you to log the locational information and avoid keeping such
>information in the log messages themselves (and thus having to maintain
>log messages such as log.debug("entering xyz.foo()") - much better as
>log.debug("entering")), standard object renderers reduce the complexity of
>the logging code. For instance, when wanting to output the contents of a
>bean, it would be nice to be able to just type:
>
>log.debug(myBean);
>
>Given the way object renderers work, that is of course not possible since
>beans are not subclasses of a particular class. One way to get around that
>would be for the logger to recognize an org.apache.log4j.BeanWrapper class
>so that this could be called like:
>
>log.debug(new BeanWrapper(myBean));
Creating a BeanWrapper for each bean to be logged is certainly one way to
mark a bean for object rendering. There are other ways which can complement
new BeanWrapper creation. For example, one could program certain beans as
implementing a certain interface, say "ObjectRenderedBean". The new
BeanWrapper approach requires no support from the bean writer but creates
an extra object for each log. The ObjectRenderedBean is the opposite:
requires support from the programmer but no object creation.
Assuming log4j will try to render the bean contained within the new
BeanWrapper object, how should BeanWrapperObjectRenderer look like? I mean
the code of BeanWrapperObjectRenderer? Should all the getter fields of the
bean be retrieved and rendered?
>In any case, I think the inclusion of more useful standard Object
>Renderers into the log4j codebase would be a very good thing for log4j,
>and I'm wondering why this hasn't been done yet. Are there any reasons
>that I'm not aware of?
Including standard object renderers is an excellent idea. If those
renderers were also generic, that would be really powerful.
>Thanks,
>
>Daniel
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
