• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • Reporter:
  • September 21, 2009
  • 8
  • Watchers: 4
  • July 27, 2012
  • November 06, 2009

Attachments

Description

see forum post for justification… It really is a good idea :) http://sourceforge.net/forum/message.php?msg_id=7596293

I cleaned up and hand optimized debug calls to minimize overhead. I’m human though, I have been known to make mistakes.

Attached is patch against 1.6.2 for using slf4j 1.5.8 Sourceforge Ticket ID: 2847111 - Opened By: exabrial - 30 Aug 2009 00:24 UTC

Comments

gluck 2009-09-25

We need to get something that suits everyone. Maybe the answer is a LogManager in Ehcache which can be configured.

sl4j seems to create tons of classloading issues, which is why I rolled it out of 1.6.

But I know logging is a huge issue.

gluck 2009-09-28

I think the right answer is to provide a configurable logger in ehcache.xml which will default to JUL but will allow simple plugging in of SL4J, commons logging, log4j and others. This is the approach that some other widely used open source projects take.

What do you think?

Also, with the sourceforge move I think we lost the patch. Can you please reattach.

Jonathan Fisher 2009-09-29

I have the patch on another machine, I’ll attach it later tonight.

I think there may be some confusion on what exactly slf4j is.

I think the right answer is to provide a configurable logger in ehcache.xml which will default to JUL but will allow simple plugging in of SL4J, commons logging, log4j and others. That’s exactly what SLF4J does!!! If you make a homegrown solution, there’s no point to using slf4j. SLF4J requires a jul, commons-logging, or log4j backend. By itself, slf4j cannot log anything. It is a logging abstraction framework that allows switching of logging technologies.

This is the approach that some other widely used open source projects take. imho, I think they’re wasting their time! I think we should be concentrating on caching domination rather than logging. Hibernate has now officially switched to slf4j… you can now log all of your hibernate calls out to JUL if you want! that’s the flexibility slf4j offers.

That’s why slf4j makes sense for ehcache though… since ehcache is a library, using slf4j would allow a developer freedom of choice of which logging framework to use.

I would really like to help with the class loading issues. Is there a particular situation or test case you were seeing them in?

Jonathan Fisher 2009-09-30

I recreated the patch.

Jonathan Fisher 2009-10-07

Is there any way we can get this into 1.7.0??? If I get some votes for the patch would that help?

gluck 2009-10-07

Thanks for recreating the patch.

I cannot find the email with the issue now

It is too late for 1.7.

Getting some votes would definitely help.

I will put out a note on the mailing list about it and see what the feedback is.

Paul Benedict 2009-10-09

I believe this is a definite priority for 1.7 so that logging can be adequately controlled in environments (like WebSphere) where JCL is a burden.

Eric Dalquist 2009-10-30

JUL is a pretty big issue for my development. I’m the developer lead for the uPortal project. Our deployments regularly consist of 20+ web applications usually under Tomcat. uPortal and many of the portlets that our deployers use make use of EhCache and trying to get per-webapp logging configured for EhCache is proving to be impossible due to JUL’s inherent lack of classloader specific logging support.

While JCL did have classloader issues at one point it time JCL 1.1 mostly resolved those.

Further as has been pointed out before SLF4J completely resolves the classloader issues by allowing the deployer to choose which underlying logging framework to use.

I really hope this can make it into 1.7.1

Eric Dalquist 2009-10-30

I applied the patch to 1.6.2 and published a maven artifact into uPortal’s 3rd-party repository:

http://developer.jasig.org/repo/content/repositories/3rd-party/net/sf/ehcache/ehcache/1.6.2-slf4j/

Feel free to use the repository and JAR

Eric Dalquist 2009-11-05

Here is a slf4j patch for the jgoups replication adapter

gluck 2009-11-05

Eric, applying your patches. First one I am doing is JGroups.

Have you completed a contributor agreement? We need this to use your patch.

http://www.terracotta.org/confluence/download/attachments/786516/Individual+Contributor+Agreement.pdf?version=2

Eric Dalquist 2009-11-05

Great, I’ll get the CLA faxed in tomorrow when I’m back in the office.

Also I just realized my jgroups patch includes changes to the pom.xml so I could push the artifacts into the Jasig repository. Let me know if you'd like an updated .patch.

gluck 2009-11-05

Applied the jgroups one to trunk, in anticipation of your contributor agreement. I reverted the repo and naming changes.

The test concrete logger uses j.u.l. but that is of course irrelevant to the module and assembly.

gluck 2009-11-05

The code base has moved on a bit far to easily apply the core patch. Implementing myself.

gluck 2009-11-06

HI everyone.

SLF4J has been committed to trunk and is available in 1.7.1-SNAPSHOT. It will be released in a few weeks.