• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache,ehcache-core
  • mallen
  • Reporter: lima
  • November 12, 2009
  • 0
  • Watchers: 2
  • July 27, 2012
  • October 12, 2010


A client reported an issue with EHCache 1.7. Looks like it has something to do with Java security and logging 1.7 is using. There was no problem when they were using EHCache 1.5. After they replaced the jar, the problem shows up.

Hi Li,

So far, I was unable to replicate the problem on a standalone application. In other words, the problem persists in the context of Escenic enterprise application which is our Presentation Tier.

However, I conducted more experiments in Escenic environment.

  1. To answer your question: the actual placement of ehcache-core-1.7.0.jar file may be irrelevant or may be not. But, for the presentation tier, ehcache is being used for those tasks that necessitate its placement into the shared lib directory - there is simply no other way around. OK, let us forget about this for now.

  2. One of web applications that comprise Escenic enterprise archive is “Escenic Content Studio”. This is in fact a rich client application being launched using Java Web Start technology. Details of its implementation and source code won’t be disclosed to us. However, based on my observations, the application uses its own security manager which is kind of restrictive and ignores java.security.policy setting which refers to the file granting all possible permissions:

grant { permission java.security.AllPermission; };

As a result, an exception is thrown on the first attempt to access ehcache in the static initializer of com.tgam.escenic.util.CacheUtils class (I wrote it).

java.lang.ExceptionInInitializerError at com.tgam.escenic.util.CacheUtils.(CacheUtils.java:15) at com.tgam.escenic.jel.JELCache.(JELCache.java:15) at com.tgam.escenic.jel.JELSupport.getCompiledExpression(JELSupport.java:206) at com.tgam.escenic.jel.JELSupport.evaluate(JELSupport.java:224) at com.tgam.escenic.util.ProtectionUtils.isFree(ProtectionUtils.java:86) at com.tgam.escenic.transfilters.ProtectionArticleFilter.doUpdate(ProtectionArticleFilter.java:29) at neo.xredsys.api.IOObjectUpdater.applyFiltersTo(IOObjectUpdater.java:3377) at neo.xredsys.api.IOObjectUpdater.applyUpdateFiltersTo(IOObjectUpdater.java:3356) at neo.xredsys.api.IOObjectUpdater.updateArticle(IOObjectUpdater.java:677) at neo.xredsys.api.ArticleTransactionImpl.update(ArticleTransactionImpl.java:62) at neo.xredsys.rio.RIOAdapterImpl.update(RIOAdapterImpl.java:614) at neo.xredsys.rio.RIOSessionImpl$10.run(RIOSessionImpl.java:1482) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at neo.xredsys.rio.RIOSessionImpl.update(RIOSessionImpl.java:1477) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.security.AccessControlException: access denied (java.util.logging.LoggingPermission control) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.util.logging.LogManager.checkAccess(LogManager.java:936) at java.util.logging.Logger.setParent(Logger.java:1367) at com.caucho.log.EnvironmentLogger.setParent(EnvironmentLogger.java:102) at com.caucho.log.LogManagerImpl.buildParentTree(LogManagerImpl.java:123) at com.caucho.log.LogManagerImpl.buildParentTree(LogManagerImpl.java:120) at com.caucho.log.LogManagerImpl.buildParentTree(LogManagerImpl.java:120) at com.caucho.log.LogManagerImpl.addLogger(LogManagerImpl.java:77) at java.util.logging.Logger.getLogger(Logger.java:278) at net.sf.ehcache.CacheManager.(CacheManager.java:78) ... 29 more

Obviously, the problem arises on attempt to log which is made by net.sf.ehcache.CacheManager.

There was no such problem in the previous version of ehcache that relied on commons-logging.

I can try and ask Escenic tech support as to whether there is an undocumented way to set up permissions for their Content Studio application.

Probably there is a way to switch ehcache logging back to jakarta commons or use log4j - which are obviously less restrictive in terms of security permissions. Actually, based on what I saw on http://ehcache.org/documentation/logging.html , it should be easy since, starting with version 1.7.1, you switched over to slf4j which is supposed to plug in preferred loggin mechanism fairly easily. But I could not locate ehcache 1.7.1 on the download page . Your advice/help would be appreciated.

Just want to stress it again: transition to ehcache 1.7 on Presentation Tier is not critical for the purposes of the project we are working on now, It would be a showstopper in the future when we’ll move on with either merging PT and MT or replacing RMI/REST as communication medium between tiers by Terracotta.




Alex Miller 2009-11-17

Of interest is that Ehcache 1.7.1 uses SLF4J for logging instead of directly using the java.util.logging framework. With SLF4J you can choose to use another logger and that might avoid this issue entirely.

gluck 2010-10-12

Ehcache 1.7.1 and higher uses SLF4J. You can plug your own logger in under this. So the java.util.logging problem will be resolved by switching in another logger.