Vincent,
Thanks for your quick response. It is much appreciated.
At 11:38 AM 1/9/2005, Vincent Massol wrote:
Hi Ceki,
Everything is open. However, I've never seen any issue WRT classloaders. Maybe because I always force CL to use a specific implementation (instead of letting it decide automatically)? Do the classloader issues still exist when you configure CL to use a specific implementation (f.e. org.apache.commons.logging.Log = org.apache.commons.logging.impl.Log4JLogger).
Yes, they do. The org.apache.commons.logging.LogFactory class *always* caches the actual LogFactory implementation it uses. The cache is keyed by thread context class loader. In case of failure our tests will be impossible or at least very hard to debug (due to the side effects created by JCL).
Moreover, you Cactus 1.6 is compiled against JCL version 1.0.3 which is not compatible with log4j 1.3.
See http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin g for how we currently configure Cactus logging.
I wouldn't mind using UGLI but I think we would need some good reasons for using it. I have a few questions:
1/ Our configuration sounds a bit complex to me. Could UGLI improve it?
UGLI is about reliability. It won't make configuration any easier nor more difficult.
2/ How do you configure UGLI? Does it use directly the configuration from the underlying logging system?
The jar file you drop in determines the logging API to use. If you drop in ugli-nop.jar, then you'll get NOP loggers. If you in drop ugli-jdk14.jar, you'll use JDK 1.4 loggers. If you drop in log4j.jar you'll get log4j loggers. The UGLI paradigm is extremely simple.
Other than that, UGLI does not try to configure the underlying logging API.
There is another solution: to use a custom logging monitor as explained here (http://paulhammant.com/blog//000241.html) - I've done that for Cargo and it looks good. I'm sure it is less powerful than using CL or UGLI but it has the advantage of reducing the mandatory jar dependencies by one. Also we have very simple logging needs and no performance required, so it would be enough.
All that said, I personally don't have the bandwidth at this point in time to make the move but if we feel it's a good thing and someone wants to do it, then I wouldn�t be against it... ;-)
I am still getting the hang of Cactus. It's way too early for me to make a proposal.
Thanks -Vincent
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
