Howdy, I've written initial versions of both (ResultSetRenderer and BeanRenderer). I've submitted them to Bugzilla as enhancement request, because my WinCVS is not working here at work. I'll commit them into the sandbox (unless someone wants them elsewhere), hopefully tonight. Feel free to comment on them, add features, etc: Bugzilla issues 23945, 23946.
Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Monday, October 20, 2003 10:54 AM >To: [EMAIL PROTECTED] >Subject: RE: Useful Object Renderers > >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] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
