commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: JCL problems
Date Sun, 13 Feb 2005 19:50:47 GMT
On Tue, 2005-02-08 at 11:30, Ceki Gülcü wrote:
> 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?

(i'm not sure whether i'm missing your point.)

it seems to me that it matters not whether the discovery is dynamic or
static: the log4j library needs to be available in the classloader.
static discovery would break in a similar fashion if a required library
is not present.

from a practical perspective, i don't really see having to put a number
of libraries together so that they are loaded by the same classloader is
really a restriction. what matters is that there are ways to achieve the
required results and definite instructions are available which are easy
for deployers to understand. 

- robert


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


Mime
View raw message