Send from my mobile device
> Am 02.06.2014 um 21:51 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > @Thomas: never said [logging] is bad and JUL is better. Sorry if I was not > clear. All logging facades don't handle very well EE case for several good > or bad reasons. [logging] is as good as slf4j for it (even better out of > the box IIRC). JUL is far to be perfect but is in the JVM (so no > dependency). The second point was just an open one. We'll want to get > JCS/JCache in TomEE in few months and logging is not the best solution we > have ATM. A little facade/factory would be great but once again this is not > a blocker now. Mentionned it to let you have it in mind when it will come > back. > > > About 1 you are right and wrong. Right that I keep in mind in memory case > (concurrenthashmap to caricature it a bit) because it is a very common > case. Right that JCS is not only it and its biggest value is not here. > However I can't agree when you say you don't care about this case. JCS is a > cache and if caching is as slow as the cached computation then it is not as > useful as it could be. Back to the logging I benched it months ago for > OpenEJB and it really depends the configuration of the logger and the impl. > Most of the time it is fine but if you want business debug logs only and > you have several appenders by logger then you get an noticeable overhead > (it was shouting in Tomcat classloader which is called very often at boot > and had a lot of isLogEnabled(FINE) some month ago). > > That said I don't want to fight too long on it so if you really think it is > wrong you can revert this part and I'll come back with a sample when I'll > find time to work with it on a real project (until now I only used > test/sample projects). I trust Romains assement of this topic. Benedikt > > > > > 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 20:51 GMT+02:00 Thomas Vandahl <t...@apache.org>: > >>> On 01.06.14 21:26, 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? >> >> Remember what I said about use cases. You have your one-and-only use >> case in your mind. Others may have other use cases, accept dependencies, >> need debugging. A quick scan of the net shows several places where the >> performance issue has been discussed. Examples: >> >> http://learnertobeginner.blogspot.de/2010/06/how-to-use-isdebugenabled-effectly.html >> or http://logging.apache.org/log4j/2.x/performance.html >> >> Both suggest that the isDebugEnabled() call can be neglected for most of >> the cases. It is not ConcurrentHashMap you are competing with. >> >> Create a benchmark, run it and see for yourself. Logging is the least of >> our performance issues, I promise. >> >>> 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 ;) >> >> I'm not sure I understand what you want to tell me. Do you consider it >> good manners to jump into a community and tell them right away how >> shitty their logging framework is? My experiences with JUL are no better >> by the way. >> >> That said, I don't really care about the logging framework. Move to JUL >> if you believe it's faster. But please avoid shooting yourself in the >> foot by prematurely optimizing things and removing important features. >> >> Bye, Thomas. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
