I've been looking at Bug 58588 [1]. It looks clear that the JULI extras JARs no longer add value and I'm happy to remove them. That bug also raises the question "How would users switch Tomcat's internal logging to LOGBack, log4j2 or something else?".
A quick look at the respective manuals suggest the following: LOGBack inserts itself via the root logger so that should be OK. In this case we'd have: Tomcat -> JULI -> JUL -> LOGBack log4j2 replaces the LogManager. Providing a suitable selector (class loader or JNDI was used) this should be fine. In this case we'd have: Tomcat -> JULI -> log4j2 Thinking about all of this got me wondering. A primary driver for JULI was the lack of class loader aware logging frameworks. This particular problem appears to be solved (at least log4j and logback have solved it). Do we want to consider a change to the logging framework? Possible options include: 1. Simplified JULI that uses JUL directly but with our existing LogManager and configuration extensions. 2. Native log4j2. 3. Use SLF4j API with log4j2 by default. 4. Use SLF4j API with logback by default. 5. Something else... 6. Do nothing. Currently, I'm leaning towards either doing nothing (what we have works) or option 1. Options 2-5 all involved adding additional libraries which I instinctively prefer not to do without a really good reason. Thoughts? [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58588 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
