Quoting James Stauffer <[EMAIL PROTECTED]>: > How would log4j-all.jar have classloader problems? Would it have > something in it besides log4j code? >
I think Ceki is referring to the case where, let's say we have log4j-all.jar in CATALINA_HOME/common/lib and somejdbcdriver.jar in WEB-INF/lib. Using the DBAppender, we'd get ClassNotFoundException or NoClassDefFoundError for the JDBC stuff. Then again, if we put log4j.jar in CATALINA_HOME/common/lib and log4j-db.jar in WEB-INF/lib alongside somejdbcdriver.jar, how would Log4j find the DBAppender itself? Instantiate it via the thread context classloader? I suppose that's doable. Ceki, is that what we're doing? I'm at work and can't look at the code ATM. I'm probably forgetting something here, but I'm not sure I agree that separate jars are all that useful other than decreasing the size of log4j.jar in the case where one doesn't need all the extra optional stuff. Jake > On Apr 7, 2005 9:39 AM, Ceki Gülcü <[EMAIL PROTECTED]> wrote: > > At 03:09 AM 4/7/2005, Jacob Kjome wrote: > > >At 10:37 AM 4/7/2005 +1000, you wrote: > > > >The build system now builds core, and optional jars. If you don't setup > > > >your build.properties correctly, the build system will detect it does > > > >not have enough of the dependencies to build the other optional jars, > > > >which is where the DBAppender will sit. > > > > > > > > > >Paul, > > > > > >I think he's saying that the official download from logging.apache.org is > > >missing the dbappender. What I think he missed was the log4j-db.jar. The > > >optional stuff has been slplit out to separate jar files. I still think > > >we should have a log4j-all.jar for those who want to deal with a single > > >jar file with all that log4j has to offer. > > > > While a log4j-all.jar file would yield certain immediate benefits, e.g. > > simplification, it would also open the possibility for class loader > > problems in app servers. Keep in mind that log4j.jar was split into several > > parts for technical reasons. It wasn't done with an aim to make life > > difficult for our users. Honest. :-) > > > > Do we want to trade immediate comfort to our users with long term usability > > of our product in real-world situations? Does John Ferron prefer to face a > > missing class problem (missing log4j-db.jar file) or incompatible class > > version problem (JCL+Tomcat+log4j+DBAppender combination)? > > > > With the split jar approach we can offer a deployment recipe which stable > > under a wide range of conditions whereas the single jar solution is stable > > only in simple (trivial?) cases. Admittedly, it's a fine point which is > > neither immediately obvious nor convincing. > > > > >Jake > > > > -- > > 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] > > > > > > > -- > James Stauffer > Are you good? Take the test at http://www.livingwaters.com/good/ > > --------------------------------------------------------------------- > 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]
