actually these logs are really debug log not intended to be activated in prod excepted if there is a big issue (@thomas: if you can confirm it would be great).
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-06-02 16:20 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > On 6/1/14, 12:26 PM, Romain Manni-Bucau wrote: > > 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? > > Let me ask the obvious, probably naive question: does this component > really need logging at all? Could you expose what clients need via > JMX or other means? It would be good to know what clients are > actually using / depending on. > > Phil > > > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
