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).
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? 2/ How do you configure UGLI? Does it use directly the configuration from the underlying logging system? 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... ;-) Thanks -Vincent > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED] > Sent: samedi 8 janvier 2005 17:47 > To: [email protected] > Cc: [email protected] > Subject: Log4j integration testing with Application Servers > > > Hello, > > In the log4j project, we need to perform integration tests between > log4j and various Application Servers. Sounds familiar? :-) > > Our tests check that log4j correctly solves the "logging separation > problem" [1] when ContextJNDISelector is installed. Unfortunately, > since commons-logging relies on classloader tricks, and Cactus uses > commons-logging, we can't rely on the test results. > > I was thinking of replacing c-l calls with UGLI [2] but that sounds > awfully stupid. Redoing some of Cactus without CL sounds just as bad. > It looks like we are stuck. > > [1] http://www.qos.ch/logging/sc.jsp > [2] http://logging.apache.org/log4j/docs/ugli.html > > > -- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
