https://issues.apache.org/bugzilla/show_bug.cgi?id=48716
--- Comment #17 from Mark Thomas <ma...@apache.org> 2010-10-07 17:21:52 EDT --- (In reply to comment #16) > (In reply to comment #15) > > Imposing JULI on the world just to be right is not reasonable. > > I cannot agree more. Tomcat, as a Java application like any other, should NOT > be imposing a logger but rather reuse the existing logger. That simply isn't an option. This isn't about being right, neither is it about not liking the standard LogManger, it is the result of long - and in some cases bitter - experience of committers, contributors and users of the issues (memory leaks, locked JARs, mixed up log messages) associated with log managers of all forms in the complex class loader environment that is a Servlet container. This isn't limited to the default LogManager implementation, if you look back in the archives you'll find similar issues associated with commons logging and - if memory server me correctly - log4j as well. JULI was the Tomcat community's solution to these problems and it has worked very well. There are far less class loader / memory leak / logging type issues reported to the users list now than there were when I first got started on this project. Like any code, JULI has had some bugs along the way but is now very stable. Like any requirement, support for working with the standard LogManager is going be considered based on: - how invasive any change is - how many users are likely to use it - the likelihood of it causing problems for users that turn into questions on the users list. This last point is a real concern in this case. Not using JULI would cause potentially hard to diagnose problems for many users. The user's mailing list doesn't need the extra questions. Despite the tone of the previous comments (please try and remember the committers are doing this because they enjoy it - people don't do things by choice that aren't fun and this bug is heading rapidly towards not being fun), I have been giving this some more thought. A previous suggestion was to only call reset() if JULI was the LogManager. My objection to that approach remains - it doesn't allow for alternative class loader aware LogManager implementations. However, a slight variation of that idea could work - call reset() unless the current LogManager is the standard java.util.logging.LogManager. The downside is that unless exactly that LogManager is used, reset() is still going to get called. Would a change to LogFactory.release() that checked for java.util.logging.LogManager and logged a warning rather than called reset() in that case meet your requirements? (Might have to skip logging a message - could get into circular dependency issues) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
