DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42413>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42413 ------- Additional Comments From [EMAIL PROTECTED] 2007-05-21 10:59 ------- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
