@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). 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 > >
