Mailing-List: contact general-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Logging General" <general@logging.apache.org>
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <000f01c55bc4$b8c40960$5df6fea9@hogwarts>
From: "Mark Womack" <mwomack@apache.org>
To: "Logging General" <general@logging.apache.org>,
	<hhartley@pobox.com>
References: <20050518094838.F22368C@orb.sasl.smtp.pobox.com>
Subject: Re: Is Log4J Dead on the Java Platform?
Date: Wed, 18 May 2005 09:14:47 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

Harry,

Thanks for your email.  To answer your question, log4j is not dead.

To your specific points:

> 1)       The documentation for Log4J is pitiful. I have not purcha$ed the
> 'full' manual, and will not. Maybe its as simple as that.

The primary documentation for log4j is currently the JavaDoc.  You have a 
point that the current documentation could be better.  It is something we 
are looking at as part of the v1.3 release.

> 2)       The download seems very incomplete. There are MANY directories 
> that
> are empty. The various examples directories are incomplete.

I take that you are referring to the 1.2.9 release package?  I'll take a 
look as this might be a release issue.  There are lots of new directories in 
the current cvs head, and even though the code was is not included in the 
1.2 release, the empty dirs probably are.  That is a simple cvs checkout 
issue.  But I can see where it is confusing, no doubt, and I will make sure 
it is fixed for the next upcoming release.

> 3)       There are references to classes in the documentation that do not
> exist. Specifically XMLSocketAppender.

In the v1.2.9 release?  Can you point me at an example?

> 4)       Since early this year, log4j mailing lists are essentially 
> silent.

I'm not sure which mailing list you are referring to.  There has been 
substantial traffic on the log4j-dev list, and ongoing questions and traffic 
on the log4j-user list.

> There seems to be more functionality in log4cxx. Is log4cxx the flagship 
> and
> log4j the follower?

The Logging Services project started with log4j as the first subproject with 
several other projects, like log4cxx, in "incubation".  So, from that point 
of view I guess you can say that log4j was/is the flagship.  There are 
discussions underway (on this list) to bring all the projects together in 
ways that will make them more similar than dissimilar api and functionality 
wise.

There is a future release of log4j planned for later this year which will 
have lots of new features that have been in the works for almost 2 years 
(too long, I know).  It will be quite a jump in functionality, and will take 
some features and usage to a new level.

> Java  based Chainsaw has several receivers that are not supported by
> appenders under log4j? Again, specifically XMLSocketAppender.

Chainsaw is currently meant to be used with log4j v1.3 as it is based on 
several of the new features in that release.

> The 'full' manual is for a fee, is this standard practice under apache? 
> This
> is the first time I've seen this under the apache initiative.

Many projects in Apache have private books written about them, and available 
separate from the project documentation.  This is the same in this case, 
though it being listed on the website is a bit different than other 
projects.  That being said, it is not meant to be the only documentation for 
the project, and updating the documentation for the 1.3 release is an 
identified task for the upcoming v1.3 release.  If you are having a specific 
issue or question, please ask it on the log4j-user list.

> I notice that tomcat itself seems to opt for a default of 
> java.util.logging
> and support log4j as a compatibility issue. Is this accurate?

Like many projects, Tomcat insulates itself from the specific logging 
implementation by using the Jakarta Commons Logging (JCL) api for logging 
messages (somone correct me if I am wrong here).  The JCL provides a 
"wrapper" for log4j, jdk logging, Avalon LogKit, and can be configured to 
"discover" the a logging implementation package at runtime (with issues in 
web applcation containers around class loading, but that is another thread). 
I thought Tomcat ships with log4j as the logging implementation as their 
default.  I am not totally familiar with this aspect of Tomcat, but I assume 
that you could configure it to use the jdk logging package as the 
implementation if so desired.  Best bet is to ask the Tomcat folks.

> Or maybe I should ask a slightly different question. What is the best
> logging package to use with tomcat?

I think you should ask that question of the Tomcat team.  The concept of the 
JCL is good, even though the implementation has issues.  The fact that you 
can write code to a common client interface (JCL) but still maintain the 
power of the logging implementation configuration (log4j) is really strong. 
Log4j provides a lot more power and ease of use (in our opinion) than the 
jdk logging package.  And v1.3 is going to be even better.  Another related 
project that has just gotten underway is the slf4j project.  You should 
visit their website for an overview.

I invite you to join the conversation and effort on the log4j-dev mailing 
list.  Having people like yourself being engaged and helping us make 
decisions in log4j's future is what the community is all about.

The log4j committers recently decided on a release plan for log4j for the 
rest of this year, and we will be detailing it on the mailing lists and web 
site shortly.

thanks for your email, please follow up if you have more comments.

hope it helps,
-Mark