2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>: > 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? >
I'd vote 6. Switching is a lot of trouble with little benefit. What would be the changes for 1 exactly ? The thing is/was supposed to be simple already. At JBoss, they use a logging tool with strong typing and a preprocessing tool. I was initially skeptical, but it worked well after a while. The extra robustness is nice in a way, it gives a bit more. Rémy
