Hi Guys. I really like using EHCache at my job and I keep finding ways to use it in crazy ways. In a recent project, I used an arcane combination of Javassist and Ehcache to dynamically enhance a tracking mechanism for our webservices. The performance improvement was amazing!
My only complaint is logging is a PITA: JUL Logging + WebSphere = Nuclear Explosion. (WebSphere as a whole has the qualities of a parasite...) Actually JUL logging in JEE environments as a whole leaves much to be desired.
I was thinking though, I would really like to contribute back to the project. How about converting to SLF4j? I've read on here this project wants to remain 'Dependency Free'. Which is good... avoid bloat, unused code, stay fast and light, etc... perfectly understandable. However, is this really what's best? Perhaps there can be one exception.
I think switching to SLF4J will not interfere with that goal. SLF4J is actively maintained, small and lightweight (API Jar is ONLY 22.9kb). This would reduce the amount of running around users have to deal with (JUL for ehcache, log4j for hibernate, commons logging for legacy... argh!)
Finally, there is a free speed bump that comes with SLF4J. Parameterized logging is all the rage these days and all the cool kids are doing it. We're all about speed here at EHCache! How about reducing some parasitic drag from logging?
If I were to generate a patch set, would the committers be interested? Think about it and let me know! I would really like to see this happen!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I went ahead and I made a patch set against 1.6.2. Seems to run spectacularly well, though Having some strange messages in unit tests ("broken pipe?")
Doesn't seem to be an attach button so is there some place I can send it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Join the club. :) I emailed the first patch I created to Greg before noticing the patch section in the tracker. By the way, I'm fine with SL4J, but I also appreciate the convenience of having no dependencies - a bit of a toss up.
--Matt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually implemented this in the last beta of 1.6.0. It caused nothing but trouble with ClassNotFound Exceptions with people that actually tried to use it.
My guess is the CNF errors were because they didn't select an impl jar (log4j, jul, commons, or no-op) in their build. It's *one* extra step, but anyone using 3.3.1 of Hibernate (a very common use for this project) will already have slf4j in their build path (Hibernate switched to slf4j). Other projects (like mine) will have to build with something like slf4j-log4j12 as a runtime dependency.
I don't like the bridge route, the SLF4J says you take a major performance hit. :(
Despite this though (looking for a quick solution) I did try the bridge last week for two days, with no luck. I tried several approaches. My first was to instantiate a factory bean in my Spring configuration that installed the handler. The only result was that all the Tomcat logging calls were routed to my log4j instance (not good). I also tried modifying the Ehcache code to do the handler instantiation directly, but that didn't work either (but again the tomcat calls did). I know I'm doing it wrong, but I didn't have any more time to play. So I wrote the patch, which is working great :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Guys. I really like using EHCache at my job and I keep finding ways to use it in crazy ways. In a recent project, I used an arcane combination of Javassist and Ehcache to dynamically enhance a tracking mechanism for our webservices. The performance improvement was amazing!
My only complaint is logging is a PITA: JUL Logging + WebSphere = Nuclear Explosion. (WebSphere as a whole has the qualities of a parasite...) Actually JUL logging in JEE environments as a whole leaves much to be desired.
I was thinking though, I would really like to contribute back to the project. How about converting to SLF4j? I've read on here this project wants to remain 'Dependency Free'. Which is good... avoid bloat, unused code, stay fast and light, etc... perfectly understandable. However, is this really what's best? Perhaps there can be one exception.
I think switching to SLF4J will not interfere with that goal. SLF4J is actively maintained, small and lightweight (API Jar is ONLY 22.9kb). This would reduce the amount of running around users have to deal with (JUL for ehcache, log4j for hibernate, commons logging for legacy... argh!)
Finally, there is a free speed bump that comes with SLF4J. Parameterized logging is all the rage these days and all the cool kids are doing it. We're all about speed here at EHCache! How about reducing some parasitic drag from logging?
If I were to generate a patch set, would the committers be interested? Think about it and let me know! I would really like to see this happen!
Well I went ahead and I made a patch set against 1.6.2. Seems to run spectacularly well, though Having some strange messages in unit tests ("broken pipe?")
Doesn't seem to be an attach button so is there some place I can send it?
Join the club. :) I emailed the first patch I created to Greg before noticing the patch section in the tracker. By the way, I'm fine with SL4J, but I also appreciate the convenience of having no dependencies - a bit of a toss up.
--Matt
I love talking to myself... I submitted the patch here:
https://sourceforge.net/tracker/?func=detail&aid=2847111&group_id=93232&atid=603561
I actually implemented this in the last beta of 1.6.0. It caused nothing but trouble with ClassNotFound Exceptions with people that actually tried to use it.
Have you seen http://ehcache.org/documentation/logging.html? You can still log via SL4J using the SLF4JBridgeHandler. Can you try that out?
My guess is the CNF errors were because they didn't select an impl jar (log4j, jul, commons, or no-op) in their build. It's *one* extra step, but anyone using 3.3.1 of Hibernate (a very common use for this project) will already have slf4j in their build path (Hibernate switched to slf4j). Other projects (like mine) will have to build with something like slf4j-log4j12 as a runtime dependency.
I don't like the bridge route, the SLF4J says you take a major performance hit. :(
Despite this though (looking for a quick solution) I did try the bridge last week for two days, with no luck. I tried several approaches. My first was to instantiate a factory bean in my Spring configuration that installed the handler. The only result was that all the Tomcat logging calls were routed to my log4j instance (not good). I also tried modifying the Ehcache code to do the handler instantiation directly, but that didn't work either (but again the tomcat calls did). I know I'm doing it wrong, but I didn't have any more time to play. So I wrote the patch, which is working great :)
Mr Luck, do we stand a chance to have this go official? :)