[logging] Class Loading Problems

[Juozas Baliuka <ba...@mail.lt>]

Hi,
I was reported a few moths ago, but I see it is not fixed in current CVS
version,
can I add myself to logging comiters list and fix this problem ? It is not
possible to solve all problems
with current API. but it is possible to solve some of them like described in
this message posted to hibernate list.
Sorry, I have pasted citation  (I can not find it in archyve to link it at
this time) :

"I'm getting really angry at commons-logging. I thought I'd never find
anything worse than Tomcat, but the Jakarta folks did it again:

The completely undocumented, useless and broken commons logging package.

For month, I've all kind of problems with this code: I can never say
what classloader loads my log4j.properties (they don't know either, just
look in their code!). Sometimes I get it from context A, sometimes the
classloader of context C finds it, even if I'm only working in context
B. The funny thing is: Everytime I restart all contexts, I get a
different log4.properties file.

I tried to fix the classloading code in commons logging, but no go. I'm
really busy right now with a new project using Hibernate and I've so far
just used System.out (log4j has crazy bugs, too). But Hibernate uses
commons logging, so everytime I change something I get alot of output in
my logfiles, because the damn commons logging decided to use the
log4j.properties file of my colleague, working in a different context
(and vhost).

Please, can we reduce the Jakarta dependencies in Hibernate? I see no
real use for log4j and commons logging. The standard is the JDK, and if
1.4 is not available, fall back to a selfwritten simple stdout default."

--
Christian Bauer
turin@incubus.de




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