Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <6.0.3.0.0.20050208110617.03b392d8@mail.qos.ch>
Date: Tue, 08 Feb 2005 12:30:54 +0100
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch>
Subject: Re: JCL problems
In-Reply-To: <OF29C8ACE3.10CD51E7-ON86256FA1.006D52ED-86256FA1.0072AA54@
 us.ibm.com>
References: <6.0.3.0.0.20050207201810.03afc4c0@mail.qos.ch>
 <OF29C8ACE3.10CD51E7-ON86256FA1.006D52ED-86256FA1.0072AA54@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable


Richard et al.,

Before discussing relatively complex cases you mention, I think it
would benefit everyone to realize that even in the most basic cases
JCL will not work as expected.

In your examples you refer to commons-logging-api.jar but
commons-logging-api.jar and commons-logging.jar are not
equivalent. The former does *not* include the classes
org.apache.commons.logging.impl.Log4JLogger nor
org.apache.commons.logging.impl.AvalonLogger. Thus,
commons-logging-api.jar cannot bridge to log4j, for the simple reason
that the bridge, Log4JLogger, is not there.

Consider the following simple set up

      Parent [commons-logging.jar]
         ^
         |
      Child  [log4j.jar]

Depending on how the thread context class loader is set,and the
delegation model followed by the child loader, the above configuration, in
the best case, will ignore log4j and in many other cases
will throw a LogConfigurationException.

The following set up will not fair much better (regardless of the
delegation model):

      Parent [commons-logging.jar]
         ^
         |
      Child  [commons-logging.jar, log4j.jar]


The only setup that will not blow in your face is the following:

      Parent [commons-logging-api.jar]
         ^
         |
      Child  [commons-logging.jar, log4j.jar]

Note this is the set up used by Tomcat. Also note that it precludes
the use of log4j by Tomcat itself as commons-logging-api.jar includes
support for java.util.logging but not log4j. If you replace
commons-logging-api.jar with commons-logging.jar, then you must place
log4j.jar next to it unless you enjoy JCL throwing
LogConfigurationExceptions at you.

The bottom lines is that when compared with any statically bound
bridging mechanism found in UGLI, JCL's dynamic discovery brings no
added value but has a significant cost in aggravation.

Richard, is there a point discussing complex cases when even the
simplest ones don't work? Were you aware of problems in the above
cases?


At 09:52 PM 2/7/2005, Richard Sitze wrote:

>One problem that we encounter, in one form or another, is when we look for
>a resource that "may or may not" be visible.  For example, a configuration
>file.
>
>As delivered, the JCL jar files do *not* include a configuration file.
>
>      Parent [commons-logging-api.jar, Log4J.jar]
>         ^
>         |
>      Child
>
>This works as expected, for the most part [other ClassLoader problems
>aside].  So how do you configure the child application, in this case, to
>use a different logger?  You might introduce a configuration file.
>
>      Parent [commons-logging-api.jar, Log4J.jar]
>         ^
>         |
>      Child  [commons-logging.properties, LogKit.jar]

[cut]


--=20
Ceki G=FClc=FC

   The complete log4j manual: http://www.qos.ch/log4j/


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