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=33143>. 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=33143 ------- Additional Comments From [EMAIL PROTECTED] 2005-02-06 20:03 ------- > I have no personality conflict with Ceki, other than the fact that he chose to > split the logging API, rather than try to contribute and enhance standards. Log4j joined Apache in late 1999. Not only is calling log4j a fork of java.util.logging factually inaccurate, it is also insulting. As for participation by log4j community, have a look at pages 85 and 86 of the JSR-47 specification: 5.4 Changes between 0.71 and 0.80 Adopted some changes suggested by the Apache log4j community: - There is now a Logger.getParent method to allow you to find the nearest extant ancestor for a given Logger. To help implement this, a Logger.setParent method has been added. - Loggers may now inherit their effective level from their parent. If a Logger’s level is set to null then it will effectively inherit its parent’s level (recursively up the tree). This effective level is the level that will be used for all output checks. As a side effect of this change, the LogManager.getLevel and LogManager.setLevel methods have been removed, as they are now largely redundant and potentially confusing. - default Loggers will now also send their output to their parent’s Handlers (recursively up the tree) - default Loggers will now also send their output to their parent’s Handlers (recursively up the tree). As a side effect of this, the old "global handlers" has become obsolete. The global handlers are now replaced by the Handlers for the root Logger in the namespace. So the LogManager methods addGlobalHandler, removeGlobalHandler, getGlobalHandlers, removeAllGobalHandlers, publish, and flush have been removed. The Logger methods getUseGlobalHandlers and setUseGlobalHandlers have been replaced with the methods getUseParentHandlers and setUseParentHandlers. The LogManager "handlers" is now used to define the initial handlers for the root Logger. - a Logger does not have a resource bundle name defined, then it will inherit the resource bundle name defined for its parent, recursively up the tree. - There is a new class ErrorManager for handling errors during logging output. An ErrorManager may be added to a Handler using Handler.setErrorManager and retrieved using Handler.getErrorManager. When an output error occurs on the Handler the associated ErrorManager will be called to process the error. This has replaced the previous mechanism based on Handler.setException and Handler.getException, and those two methods have been removed. Note that some of these contributions are not insignificant. > UGLI is yet another fork attempt by Ceki of a well accepted API, > rather than try to contibute or enhance the said API. It's just lame, > I have nothing else to say. UGLI was developed in order to support logging generated by log4j components internally. (In log4j 1.3, log4j components use log4j itself when logging internally generated messages.) In case the log4j component cannot get a handle to a valid LoggingRepository, it must fallback to another implementation which is where UGLI comes in. Bugs caused by JCL's discovery mechanism do much harm to log4j's reputation. UGLI avoids these bugs with a simpler and more robust approach. I chose to ignore Remy's other more personal comments which are unbecoming of an ASF member. -- 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]
