Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: Re[2]: Strange problem with Digester and Log4j
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: Christian Hufgard <christian.hufgard@gmx.de>
Cc: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: <1463403358.20060329123631@gmx.de>
References: <20060328211629.0084CE5BC7@ws7-2.us4.outblaze.com>
	 <624257450.20060328232050@gmx.de>
	 <1143628299.4627.35.camel@localhost.localdomain>
	 <1463403358.20060329123631@gmx.de>
Content-Type: text/plain
Date: Wed, 29 Mar 2006 23:37:31 +1200
Message-Id: <1143632251.4627.88.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2006-03-29 at 12:36 +0200, Christian Hufgard wrote:
> Hi Simon,
> 
> > Most of those problems never existed. That page is just wrong in many
> > places.
> 
> This is -erm- weird. The information seems to be quit reasonable, is
> it just a try from the log4j author to prevent people from using
> commons-logging?
> 

Ceki is a very bright guy, and has done some great work with logging.
He's also come up with some nice ideas for SLF4J that may well influence
upcoming releases of commons-logging. However that particular page
really is misleading.

It would appear that the article was written shortly after having
identified a bug in Tomcat that was obscured by a misconfiguration of
logging. I've been there myself; computers can be damn frustrating
things. However that never leads to a fair and balanced view. 

Much of the article is arguing against using JCL for *applications*.
That's quite reasonable, and I personally agree (though some do not;
Tomcat uses JCL for example). However the article isn't clear that these
arguments apply to only "application" scenarios (and not to "library"
code); it appears to be arguing against using JCL at all which is wrong.
I don't know if this was just accidental implication when writing or if
Ceki hadn't realised the critical difference between libraries and
applications when writing this.

The bits about JCL being a "lowest common denominator" lib are true.
Again, though, this is about *applications* vs *libraries*. For apps,
JCL adds complexity for a dubious gain - agreed. However for libraries,
you just *cannot* bind to a specific concrete lib; a wrapper of some
sort is the only sane option.

The bits about "wrappers increase the complexity" are true. So for apps,
don't use wrappers. However for *libraries* you don't have any option.

The stuff complaining about "auto-discovery" (which is about 50%) is
only partly relevant. A commons-logging.properties file really should be
used with each deployment - in which case no auto-discovery of the
library "type" occurs at all. Only if this file is missing is discovery
attempted. Agreed, the JCL documentation should have been clearer on
this issue.

Yes, there *are* some problems that can occur as a result of
classloading. However in many cases these are really limitations due to
the design of java rather than JCL. The options are to either reduce
functionality or document the necessary deployment rules. Unfortunately
commons-logging *is* a little light on documentation. And in the end,
there is little option - log4j is *not* applicable to libraries. The
SLF4J project *is* an alternative to JCL, but it achieves greater
reliability by sacrificing some significant functionality; that's ok but
should be pointed out.

The complaints about a lack of diagnostics in JCL to help investigations
is fair; JCL 1.1 (currently RC6) has this feature.

Complaints about JCL not supporting a NULL classloader (ie everything
loaded via the "bootloader") - well, ok it didn't support this. However
it's a pretty odd case. And like any other project, it just needed
someone to step up and make the changes; JCL 1.1 will handle this
(hopefully; there hasn't been a great herd of volunteers to test this,
and it's not testable on normal JVMs).

If you read Rodney Waldhof's article, you see he says very much the
same: don't use it for *apps*, but do use it for *libs*.

Referencing "The Bile Blog" in support of an argument really can't be
taken seriously :-)


So in summary, this page makes some good arguments for using a real
logging lib from applications. For libraries, it shows few real issues
and proposes no practical alternatives.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org