Discussion on log4j and logging in general are held on the log4j-user mailing list. To subscribe to this list send an e-mail to log4j-user-subscribe@jakarta.apache.org.

Development related discussions are held on the log4j-dev mailing list. To subscribe to this list send an e-mail to log4j-dev-subscribe@jakarta.apache.org.

All developers are encouraged to subscribe to the log4j-cvs list which will notify the subscribers of CVS any commits to the repository. To subscribe to this list send an e-mail to log4j-cvs-subscribe@jakarta.apache.org. Committers should subscribe to this list with their Apache e-mail address.

To prevent spam, we expect you to be subscribed to a list before posting to it. Otherwise, your mail needs to be approved by an administrator which delays your posting and creates needless work for us.

Most Jakarta mailing lists, in particular the log4j mailing lists, are archived. Some of the known archives are listed below:

• http://www.mail-archive.com
• Full mbox archives of all Jakarta lists are available at http://jakarta.apache.org/mail/
• http://marc.theaimsgroup.com

Please do your best to ensure that you are not sending HTML or "Stylelized" email to the list. If you are using Outlook or Outlook Express or Eudora, chances are that you are sending HTML email by default. There is usually a setting that will allow you to send "Plain Text" email.

Bugs should be reported by using the Apache Bug Database. Before reporting a problem, please make sure to check the database and the project history file to see if the problem is not already known. Before filing a report, you should first send email to the log4j-user mailing list describing the bug ensuring that you are not filing an already known problem. Only after these precautionary steps should you file a bug report with Bugzilla.

Although Bugzilla allows users to file enhancement requests as bugs, enhancement requests are not bugs and should not be treated as such. The preferred way to request for enhancements is by posting on the log4j-user list. This allows other interested parties to participate in the ensuing discussion.

Just reporting a bug will not fix it. A good bug report includes a detailed description of the problem and a succinct test case which can reproduce the problem.