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]
