Mailing-List: contact turbine-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Turbine Users List" <turbine-user@jakarta.apache.org>
To: turbine-user@jakarta.apache.org
Path: not-for-mail
From: "Henning P. Schmiedehausen" <hps@intermeta.de>
Newsgroups: hometree.jakarta.turbine.users
Subject: Re: Turbine 2.3 loggin problem.
Date: Fri, 20 Aug 2004 10:40:49 +0000 (UTC)
Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
Lines: 121
Message-ID: <cg4kfh$e8h$1@tangens.hometree.net>
References: <200408130800.39522.mphee@jump-technologies.com>
 <411DC16E.9040707@sankya.com>
 <200408161337.19410.mphee@jump-technologies.com>
 <4122FD63.8070607@sankya.com>
Reply-To: hps@intermeta.de
NNTP-Posting-Host: forge.intermeta.de
NNTP-Posting-Date: Fri, 20 Aug 2004 10:40:49 +0000 (UTC)
User-Agent: nn/6.6.5

Babu Kalakrishnan <babu@sankya.com> writes:

>This article (and the links referred to in the article) makes 
>interesting reading :

>http://www.qos.ch/logging/thinkAgain.html

[Ceki, you probably get pointed at this article by someone. This is
not a personal attack against you. I disagree with some points in the
thinkAgain article and we discussed this many months ago. We agreed to
disagree. This is just a recollection of the discussion that went in
the 2.3 time frame and led to the migration of Turbine to c-l. We had
our own logging layer at a time, too.]

My problem with this article (which is cited widely and used as case
against c-l) is:

Ceki attacks c-l problems. However, the problems he is mentioning and
saying "commons-logging was a bad idea" are actually

- Tomcat problems. The Tomcat classloader has all sorts of bugs which
  are mentioned in the article but not credited as "these are tomcat 
  problems triggered by c-l", but "these are c-l problems".

  Most problems can be solved by using the "delegate" switch in the 
  tomcat loader configuration.

- Deployment problems / Developer errors. If you rely on c-l in your
  application matching log4j in the common/lib directory, you ask for
  trouble. Same thing vice versa, if you ship a log4j version with
  your app and rely on the tomcat provided c-l. The common/lib directory
  of Tomcat was and is a really bad idea (BTW: Tomcat 5 no longer has
  c-l in its commons/lib directory, so the problems mentioned by Ceki
  are gone here). 

  The example he cites (Bug # 17323), who of you has really looked at
  the bug report? There is a complete, correct analysis of the exception
  (java.net.SocketException) and cited exception is only thrown if your
  own application uses c-l and (!) log4j.

  c-l bug? Hardly. Tomcat bug? Yes. It is a class loader issue. What Ceki
  does not mention is, that you can get the same bug from applications 
  using pure log4j. Because it is an inherent problem with multiple 
  classloaders. It is magnified by c-l, because Tomcat uses c-l and is a
  widely used web container. Using this as a case for "logging should not
  confuse the user, so don't use c-l", is really thin IMHO.

- Ideology. log4j is Cekis' brain child and a damn good one too. But with
  c-l, people get choice of the logging system and not the lock-in into
  log4j, that Ceki promotes. Yes, c-l _is_ the lowest common
  denominator, but for many application types, this is enough. Not
  everyone does enterprise logging style with nested context. If you
  do, you get xxx lockin, anyway, so you can lock yourself into a
  logging system, too.

  Don't take his references too seriously. Yes, there are people
  blogging their c-l problems. But if you look at e.g. 
  http://www.dribin.org/dave/blog/archives/2003/12/24/commons_logging/
  which he cites, you see, that this article simply cites Cekis'
  article. Self reference, this is called in CS.

And last, but not least, because he _has_ a valid point here:

- the discovery mechanism in c-l to find the underlying logging system
  is, well, "obfuscated" at the best and "plain ugly" at the worst of
  times. The mechanism to auto-detect the available logging system is
  convenient, but should IMHO be faded out in favour of the
  commons-logging.properties file, which clearly defines which logging
  implementation to use. However, there is the problem of "we
  configured fooLogging, but the fooLogging.jar is not on the
  classpath" issue remains.

All in all, Ceki has some valid points: Using a layer between your
application and the logging implementation, especially a layer that
tries to be user friendy by doing auto-discovery is a source of
possible problems. But nine out of ten problems with c-l don't stem
from c-l but either from application bugs (Tomcat) or user errors (not
deploying the needed jars with the application, but relying on a
random assortment of jars in commons/lib).

The more important question for Turbine was: Do we want to have a
consolidated, unified layer that is quite stable (c-l)? Or do we want
to have each and every application roll its own layer (For a good
time, look at the Velocity logging subsystem)? Or do we want to commit
Turbine to log4j and leaving everyone out in the cold, who is forced
for corporate or other reasons to use a different logging system?

In an ideal world according to Ceki, everyone and everything would use
log4j. This is not going to happen. End of story. Main reason IMHO is
the lack of freely available documentation. When I started with log4j,
it took me a long time to find anything remotely resembling a
reference of the statements and switches that are available in
log4j.properties You have to pull these out of the apidocs and you
have to know, where to look.

Of course, there is commercial documentation available (which is
pretty usable and good. I still cannot grep in a book, though).

Finally, I don't see my 250 line tools set up a complete logging
subsystem. Just using commons-logging and configuring SimpleLog by
commons-logging.properties is enough for me to get a glorified
System.err.println(). And if they grow, I simply change to a bigger
logging system. Like log4j or jdk14 logging.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

"Fighting for one's political stand is an honorable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems."
                       -- Michelle Levesque, "Fundamental Issues with
                                    Open Source Software Development"

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