| Summary: | [PATCH] Log Taglib enhancements | ||
|---|---|---|---|
| Product: | Taglibs | Reporter: | Matthew T. Adams <matthewadams> |
| Component: | Log Taglib | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | NEW --- | ||
| Severity: | enhancement | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
| Attachments: | Patch for this issue | ||
|
Description
Matthew T. Adams
2007-05-14 11:39:25 UTC
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?
|