Log4jRequestedFeatures

landsLog4j - Initilization Requirement - posted by pwc@u.washington.edu Log4j issues message "Please initialize the log4j system properly". Log4j might want to request such initialization but it should nonetheless, perform a default init BasicConfigurator.configure (); and give the user the messages that he wanted to log without mandating.

Log4j - Documentation request - posted by djaquay@yahoo.com

Getting started with the simplest log4j setup requires three lines of code:

BasicConfigurator.configure();
Logger logger = Logger.getLogger( MyClass.class );
logger.debug( "your message here" );

There should be a quickstart page in the docs that says this. (Actually, I was quite annoyed at having to wade through the short manual and API docs to figure this out, when I was deciding whether or not I wanted to use log4j; I ranted about it on my blog here: http://javadave.blogspot.com/2006/04/setting-up-log4j.html)

Log4j - Logging as RSS or Atom - posted by thompsonbry@users.sourceforge.net

Add a new appender that outputs RSS. This would support the aggregation of application events through existing RSS syndication and aggregation mechanisms A trivial variant could output Atom instead of RSS.

The concept of an XML Layout tool would seem a better way to approach this, but the current XMLLayout class uses a constrained XML vocabulary, so it can't be configured for general XML document production. So perhaps this should be realized by an RssLayout and AtomLayout class which would maintain the separation of concerns from the appender logic.

Log4J - AsyncAppender - posted by marc.oesch@gmx.net Additional/optional parameter which defines a time (in seconds) to pause after subsequent waves of logEvents are released to the Appenders (and if not yet available specifiy the size of the circular buffer). In combination with an SMTPAppender this avoids to have mail flooding. Events can be grouped in mail messages. In my opinion only very small changes need to be done to the AsyncAppender like for ex.: Run method in inner class Dispatcher

public void run() {

    //Category cat = Category.getInstance(Dispatcher.class.getName());

    LoggingEvent event;
>>  long lastCycle = 0L;

    while(true) {
      synchronized(bf) {
        if(bf.length() == 0) {
          // Exit loop if interrupted but only if the the buffer is empty.
          if(interrupted) {
            //cat.info("Exiting.");
            break;
          }
          try {
            //LogLog.debug("Waiting for new event to dispatch.");
            bf.wait();
            // wait at least a given amount of time: waitMin. Interesting
            // if the appender are mail or messaging appenders
            // waitMin optional by configuration settings or 0
            // would be usefull to test if buffer is full before waiting more time
>>            if((System.currentTimeMillis() - lastCycle)/1000 < waitMin)
>>                bf.wait(waitMin*1000 -(System.currentTimeMillis()-lastCycle);
          } catch(InterruptedException e) {
            LogLog.error("The dispatcher should not be interrupted.");
            break;
          }
        }
...more lines
        if(aai != null && event != null) {
          aai.appendLoopOnAppenders(event);
        }
      }
>>      lastCycle = System.currentTimeMillis();
    } // while

Log4J - Requested Features

• Add an attribute to all appenders that specifies whether the stacktrace should be excluded in the log message.
• Add the customized filtering ability to the '.properties' config file (since today it exists only for the XML config file).
• Add the ability to truncate an attribute from its right side. Say we want to truncate the priority (have only the first left-most character). Non of the following meets our request: %1p / %-1p / %.1p / %-.1p / %-1.1p
• Add localization support. HERE HERE!
• Document log4j's support/behavior when used from multiple JVMs.

• DailyRollingFileAppender should have an optinal parametr to limit the maximun number of rotated files ( i.e. MaxBackupIndex )

• DailyRollingFileAppender should be able to put the datepattern as any part of the name, preferably by just using a date-pattern inside the File-property.

• Both (all) rolling appenders should be able to put rolled files in another directory.

• Assign LogLevels to Appender rather than Logger. So it could be possible to log TRACES, DEBUG to console only, while other logs (WARNINGS and above) go to a file. The method Logger.isEnabled(LogLevel) (or similar, don't remember the correct call) would subsequently ask all appenders.

• Add a pattern layout element that logs the hostname that the application is running on. YES! I agree! (Possibly using java.net.InetAddress.getLocalHost().getHostName(), or something similar) It's especially needed if you want multiple servers to log to a single place. -- Couldn't this be done in the current version by adding an MDC for the hostname and using it ( ... %X{HostName} ... ) in your pattern layouts? -- Check AppServerLoggingEvent. MDC is a pain if your app spawns threads, has MDBs etc. AppServerLoggingEvent means you extend lots of core Log4J classes and make ugly changes to your config.

• Add a pattern layout element that logs the username of the person who is logged into the application at the time of the logging event. -- Use NDC.
• Add a pattern layout element that logs the exception as a stack trace.
• Document JMX Supportx

• Add a method to AsyncAppender that waits until the buffer is empty... like close method but without closing the appender.

• Logging management for Threads, inherited ThreadGroup management object that is a pluggable framework to notify a user defined class of thread creation/destruction which can pass back specific reconfiguration instructions, like merge Thread-129 with existing Thread-101 configuration (share appender "tlog"), or create a new thread specific logger as "tlog" using "log4j.appender.tlog" configuration (thread specific log config) or fallback to some default action (no logging on "tlog" or log to "tlog" default output). log4j would co-operativly receive create+associate or destroy+deassociate events from application code thread manager.

• Filters should be able to rewrite the contents of a LoggingEvent. I need this to be able to cope with a logging device that only accepts up to 130 characters per line, so I need to massage the output.

• PropertyConfigurator.configure() and doConfigure() methods should return some sort of status to know if the loaded properties are valid.

• A Chainsaw extension for firefox to aid webapp development.
• Document dynamically changing the logging levels in a running application.

• Add a String variable to LoggingEvent which is configurable by the programmer such that a parameter in a properties- or xml-file can add this String as a Constant to every LoggingEvent of one Appender.

LogFactor 5 - Requested Features

• Allow Log Factor 5 to read log files based on the customer pattern for that file, instead of the logfile having to follow Log Factor 5's format.

• LogFactor 5 could read logfiles from disk, now it must read it "online".

• Allow LogFactor 5 / Chainsaw to display log messages from a JMS queue.

• Add Filtering to LogFactor 5. Would like to see filters for Date, Level, NDC, Thread, etc.