Howdy, >I thought I should add a note about Log4jCRS so people can understand how >it is differently implemented than the way Ceki describes it in his doc ( <snip>
Thank you for the explanation. I agree with Senor Womack that this should be documented in the log4jCRS distribution. I have a couple of minor code comments/questions: >(the latter being the best choice). Before any call to any configure() >method, the following gets run... > >Log4jCRS crs = new Log4jCRS(); >crs.initLoggerRepository(); Why doesn't the log4jCRS constructor init the logger repository itself? I don't usually like to see init() methods as public unless there's no other choice. >Using the contextDestroyed() method of a servlet context listener, one can >do the following.... > >ClassLoader cl = Thread.currentThread().getContextClassLoader(); >Log4jCRS crs = Log4jCRS.getCRS(cl); >crs.getLoggerRepository().shutdown(); >crs.remove(cl); Same type of question: I would prefer a Log4jCRS.shutdown() method which does both the logger repository shutdown() and the remove(cl) call. That way in the future other/different functionality could be incorporated into the Log4jCRS shutdown() without changing the interface. >existence and the fact that it is stored in a WeakHashMap, it will clean Small note, and I meant to bring this up earlier: WeakHashMap is JDK 1.2 and later. I know log4j v1.3 was considering (or maybe has decided already) to drop support for JDK 1.1 (and I agree with that decision), but it's still worth noting. With GC implementations being a topic of relatively active development at sun, blackdown, and other places, we should be careful when using a WeakHashMap and consider using a normal HashMap unless the Weak version offers significant gains. >The classes that load Log4jCRS *must* exist in the WebappClassLoader of >*each* webapp. So, if you have a Log4jInit servlet or a servlet context >listener that initializes Log4j, they must be loaded from WEB-INF/lib or >WEB-INF/classes. This is because when Log4jCRS is loaded, it uses the >classloader that loaded it as the key for the logger repositories. I think this is a very reasonable caveat. >So, Log4jCRS *must* exist in or beside log4j.jar *and* the classes that >load Log4jCRS *must* exist in the WebappClassLoader. This would suggest placing them in the same jar. However, I'm a proponent of modularity. I don't know if any of you are on the tomcat-dev mailing list, but we're having some fiery discussions over there on this topic. I would consider the log4jCRS to be an optional accessory to log4j. Therefore, I think it should be packaged separately, in its own jar. In retrospect, I think the same is true for LogFactor and other viewers. I'd like to see a log4j core (log4j.jar or log4j-core.jar) and a host of optional modules (logFactor5.jar, log4jCRS.jar, etc.) available separately, so users can pick and choose. I realize the above makes packaging more difficult and time consuming. I would be willing to help with the relevant build and package scripts, as well as documentation on what's what. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
