Well ATM log4j2 doesnt work well, didnt get time to dig into it but tested last week for another topic and lost all my shutdown messages (guess cleanup is called too early).
3 would be an option if we dont rely on [logging] anymore but the impl directly which would be a regression IMHO + either would be JUL (where loghelper is needed) or another dependency... Le 2 juin 2014 00:01, "Gary Gregory" <garydgreg...@gmail.com> a écrit : > There is also log4j 2. > > Gary > > <div>-------- Original message --------</div><div>From: Romain Manni-Bucau > <rmannibu...@gmail.com> </div><div>Date:06/01/2014 15:26 (GMT-05:00) > </div><div>To: Commons Developers List <dev@commons.apache.org> > </div><div>Subject: [jcs] logging </div><div> > </div>Hi > > I have two main point to discuss regarding the logging: > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if > (boolean) complexity and not go through the logging framework which can > imply several layers (filter, appender, handler, logger...) for nothing and > slow down caching (which has more perf constraints than other backends. > This really depends on the logger you use but we can't suppose it is the > one we benched against. Solutions I see: a) keep LogHelper, b) remove logs > (some are useless I think), 3) other? > > 2) logger api used. ATM we use [logging] but it will surely be an issue for > TomEE when integrated ([logging] is the less integrated framework - > compared to JUL or SLF4J where we don't have the choice at all) and I think > we'd be happy to remove it from the container to let it be application > oriented if we can. Any idea to make it hurtless? This doesn't urge and > doesn't block anything but if someone has an awesome idea it would be > welcomed ;) > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau >
