tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
Date Sun, 06 Feb 2005 19:03:02 GMT
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 ceki@apache.org  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message