Hi, I had some needs with respect to logging in JSPs, and have enhanced the Log Taglib project to accommodate my needs. I'm contributing back to the project because they already saved me time. Here's a quick list of the enhancements: * Added <log> tag, requiring "level" attribute for more flexible logging. * Added <trace> tag to support trace-level logging. * Genericized message attribute from String to Object to support custom log4j ObjectRenderers. * Provided default implementations of formerly abstract methods as a result of refactoring message from String to Object. * Added optional "throwable" attribute to all tags. See "TODO" placeholders in xml/log.xml for release-related data -- I didn't know what you wanted me to put in there. FYI, patch is relative to trunks-proper/log.
Created attachment 20197 [details] Patch for this issue
Looks good to me at first glance. * The <log> tag is good regardless; allowing for custom log levels. * The <trace> tag depends on what we decide to do with the Log taglib. Do we use c-logging, or do we make two taglibs that are very similar, one for log4j and one for jdk-logging. Other parts look good.
(In reply to comment #2) > * The <trace> tag depends on what we decide to do with the Log taglib. I see one of two options for the <trace> tag: * get rid of it & stick with lowest common demoninator * keep it and if the underlying logging framework doesn't support it, just redirect it to debug level. Any thought to making the underlying logging framework configurable between log4j, commons-logging, & JDK 1.4 logging? I haven't looked at it much, but the thought occurred to me while writing this comment...
(In reply to comment #2) > Looks good to me at first glance. [SNIP] > Other parts look good. Any idea when this could be released, then? I'd rather have my apps depend on a genuine Apache version of this than a one-off...
Making things configurable between log4j/commons-logging/jdk doesn't seem a good direction; that's what commons-logging does. There are other libraries out there now, but I think they're commons-logging replacements rather than real logging libraries in their own right. So my idea is to have one library, with abstract classes with much of the work in and concrete classes and tlds for log4j and the jdk. Effectively this reimplements some part of commons-logging, but just the easy part (I think). The tlds would allow map down to the relevant underlying library, so you wouldn't be able to hop between one and the other. ie) one would have <log:fine> and one would have <log:trace>. You would be able to hop between (by changing the tld url) if all you use are the ones that are in both. Maybe. It may be a half-cocked idea. I think it'll be a while before a release happens; the thread about moving this stuff into a single 'unstandard' release would determine whether we have a log release (depending on answer to the which logging apis question) or an unstandard release that contains the log taglib.
> I think it'll be a while before a release happens; the thread about moving this > stuff into a single 'unstandard' release would determine whether we have a log > release (depending on answer to the which logging apis question) or an > unstandard release that contains the log taglib. I'd like to see at least the stuff contributed in this patch released in a taglibs-log update release. That way, our projects are not depending on an orphaned version of taglibs-log (we're calling it version 1.0-f5). Can you do that? What would the version of that release be?