headers
bugzilla | 2 Jun 2002 19:13
Picon
Favicon

Bug report for Log4j [2002/06/02]

+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker     CRI=Critical    MAJ=Major             |
|     |   |           MIN=Minor       NOR=Normal      ENH=Enhancement       |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
|  569|Ver|Cri|2001-02-09|fully qualified class name used as category name c|
|  851|Ass|Min|2001-03-05|DOM Configurator not throwing exception when targe|
|  900|New|Cri|2001-03-08|RollingFileAppender does not work properly under W|
| 4561|Ass|Nor|2001-11-01|Log4J threads don't seem to terminate incase of th|
| 4861|Ass|Min|2001-11-14|log4j:ERROR Failed to flush writer                |
| 5211|Ass|Nor|2001-11-30|DailyRollingFileAppender should check renameTo res|
| 5695|Ass|Nor|2002-01-04|Can't use log4j from two servlet contexts         |
| 8505|Ass|Maj|2002-04-25|LOG4J - No stacktrace on unix platform            |
| 8529|New|Maj|2002-04-25|JDBCAppender doesn't take throwable stack trace   |
| 9150|New|Maj|2002-05-16|No check in FileAppender if parent-path exists    |
| 9305|Ass|Enh|2002-05-22|Use thread context class loader for loading       |
| 9357|New|Nor|2002-05-23|Misleading warning: result of incorrect code in Co|
| 9397|New|Nor|2002-05-24|org/apache/log4j/jmx/T.java missing package statem|
| 9438|New|Nor|2002-05-27|Counter of  logging-events missing                |
| 9462|Opn|Enh|2002-05-28|make default initialization available as a public |
| 9506|New|Enh|2002-05-29|Tool to debug appender duplications               |
+-----+---+---+----------+--------------------------------------------------+
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Womack | 3 Jun 2002 19:40

RE: More Filter Thoughts

I propose the following:

- new, changed filters under the package name o.a.log4j.filters
- In this package, a new abstract base class, ChainableFilterBase.java.
This will be a base class that supports a property, ChainPolicy, and a
decide() method that uses it's setting.  ChainPolicy will support the 4
values we have outlined previously.  It is expected that subclasses of this
base class will be "chainable" together in a filter chain.
- Move the current filter functionality available in o.a.log4j.varia into
o.a.log4j.filters, and make them subclasses of the ChainableFilterBase class
as needed/required.  Previous functionality of the AcceptOnMatch property
will not be supported in the new package.
- Create new filter classes for filtering on NDC, MDC, logger names, etc.

As noted, we will need to write up some useful documentation to better
explain the usage of these filters.

-Mark

> -----Original Message-----
> From: Mark Womack 
> Sent: Friday, May 31, 2002 9:53 AM
> To: 'Log4J Developers List'
> Subject: RE: More Filter Thoughts
> 
> 
> Ceki,
> 
> > >1) Do you think that exposing the match/nomatch return 
> > values directly will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Hager | 3 Jun 2002 19:51

TRACE level

Before I subclass the level class and add in a TRACE level, is there any
chance log4j will add in a TRACE level?

I really see the need to have a TRACE level that just details path of the
program without cluttering up the DEBUG level output.

Sean.
Permalink | Reply | 1 comment |
headers
Jim Moore | 3 Jun 2002 19:59

RE: TRACE level

I'll save you some programming:

public class TraceLevel extends Level {
  public static final int TRACE_INT = 800;

  // We assimilate TRACE to DEBUG on Syslog
  private static final int SYSLOG_TRACE_INT = 7;

  public static final TraceLevel TRACE =
      new TraceLevel(TRACE_INT, "TRACE", SYSLOG_TRACE_INT);

  final static public Level ALL = new TraceLevel(ALL_INT, "ALL", 9);

  protected TraceLevel(int level, String strLevel, int syslogEquiv) {
    super(level, strLevel, syslogEquiv);
  }

  public static Priority toPriority(String sArg) {
    return toPriority(sArg, TraceLevel.TRACE);
  }

  public static Priority toPriority(int i) throws IllegalArgumentException {
    return toPriority(i, TraceLevel.TRACE);
  }

  public static Priority toPriority(int i, Priority priority) {
    Priority p = (i == TRACE_INT) ?
        TraceLevel.TRACE :
        Priority.toPriority(i, priority);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ceki Gülcü | 3 Jun 2002 22:33
Picon
Gravatar

Re: TRACE level


No, a TRACE level is not being considered.

At 12:51 03.06.2002 -0500, you wrote:
>Before I subclass the level class and add in a TRACE level, is there any
>chance log4j will add in a TRACE level?
>
>
>I really see the need to have a TRACE level that just details path of the
>program without cluttering up the DEBUG level output.
>
>Sean.

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?
Permalink | Reply | 0 comments |
headers
Ceki Gülcü | 3 Jun 2002 22:51
Picon
Gravatar

RE: More Filter Thoughts


I hate to be pedantic but ChainableFilterBase is a bad name because
the o.a.log4j.spi.Filter class is already "ChainableFilterBase." The
o.a.log4j.spi.Filter class is an abstract class supporting precisely
the "chainable filter" behavior.  It is also a "base" class because
all filters derive from it. (Again Filter is an abstract class not an
interface.)

Consequently, either

1) we change Filter to become an interface, with FilterBase supporting
chaining of filters

or

2) we find a different name for ChainableFilterBase, for example
BasicFilter or FilterCore.

The second option seems somewhat wiser because the basic notion of
chaining filters is not being challenged.

More comments in line:

At 10:40 03.06.2002 -0700, you wrote:
>I propose the following:
>
>- new, changed filters under the package name o.a.log4j.filters

+1
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 4 Jun 2002 00:28
Picon
Favicon

DO NOT REPLY [Bug 9592] New: - Logger.getLogger(String, LoggerFactory) caching bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592

Logger.getLogger(String, LoggerFactory) caching bug

           Summary: Logger.getLogger(String, LoggerFactory) caching bug
           Product: Log4j
           Version: 1.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Other
        AssignedTo: log4j-dev <at> jakarta.apache.org
        ReportedBy: jonwilmoth <at> hotmail.com

The problem lies in the existing org.apache.log4j.Hierarchy line 254.  The 
CategoryKey used to access the Logger instance cache only uses the 
String "name" param, which may only be a portion of the full category name if 
a custom factory is used.  So if the cache is not empty for String name, it 
returns the existing logger instance and does not call 
factory.makeNewLoggerInstance(name) which may produce a category with a  
different name.  Assuming a custom factory's makeNewLoggerInstance(String) 
always returns a Logger instance with the same category name given the same
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 4 Jun 2002 00:35
Picon
Favicon

DO NOT REPLY [Bug 9592] - Logger.getLogger(String, LoggerFactory) caching bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592

Logger.getLogger(String, LoggerFactory) caching bug

------- Additional Comments From jonwilmoth <at> hotmail.com  2002-06-03 22:35 -------
Created an attachment (id=1995)
JUnit Test Case demonstrating bug
Permalink | Reply | 0 comments |
headers
bugzilla | 4 Jun 2002 00:36
Picon
Favicon

DO NOT REPLY [Bug 9592] - Logger.getLogger(String, LoggerFactory) caching bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592

Logger.getLogger(String, LoggerFactory) caching bug

------- Additional Comments From jonwilmoth <at> hotmail.com  2002-06-03 22:36 -------
Created an attachment (id=1996)
Sample Consumer of Logger.getLogger(String,LoggerFactory)
Permalink | Reply | 0 comments |
headers
bugzilla | 4 Jun 2002 00:37
Picon
Favicon

DO NOT REPLY [Bug 9592] - Logger.getLogger(String, LoggerFactory) caching bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592

Logger.getLogger(String, LoggerFactory) caching bug

------- Additional Comments From jonwilmoth <at> hotmail.com  2002-06-03 22:37 -------
Created an attachment (id=1997)
Custom LoggerFactory which produces contatinated category names
Permalink | Reply | 0 comments |

Gmane