• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • drb
  • Reporter: lima
  • November 26, 2009
  • 0
  • Watchers: 0
  • July 27, 2012
  • November 26, 2009

Description

Here’s problem report from a client. Looks like the MBean registration triggered security issue in some deployment environment:

Thanks for your quick response. I’m sure you’ll manage to resolve this issue.

I should have probably been more specific in describing the problem. Sometimes, especially when dealing with software written by external provider and having no source code available (or no rights to make any changes whatsoever), it is simply impossible to alter the behaviour of the security manager being used, as in our case. In context of ehcache, that means; there should be a way to prevent it from performing operations that might raise security exception, or handle this exception gracefully. After all, I’m sure ehcache can function without MBeans been registered.

Cheers,

Igor.

================= On Nov 26, 2009, at 10:43 AM, Kaner, Igor wrote:

Hello Li,

We discussed it in the past that there are problems in getting ehcache 1.7.0 work on our Presentation Tier, that is, Escenic - publishing system our Editorial is using here in “The Globe and Mail” (see www.escenic.com).

The last thing I informed you about is that the problem has been narrowed down to logging that does not work under Security Manager been used by Escenic content Studio application. I managed to solve this problem by switching from java.util.logging to log4j which became possible with ehcache 1.7.1 - the version not officially released.

However, my conclusion that our problems are over happened to be a bit premature. If I resort to slightly different workflow, there is another exception thrown on an attempt to instantiate CacheManager. Exception trace follows.

java.security.AccessControlException: access denied (javax.management.MBeanServerPermission createMBeanServer) 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.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:500) at net.sf.ehcache.management.sampled.SampledMBeanRegistrationProvider.(SampledMBeanRegistrationProvider.java:73) at net.sf.ehcache.management.provider.MBeanRegistrationProviderImpl.(MBeanRegistrationProviderImpl.java:46) at net.sf.ehcache.management.provider.MBeanRegistrationProviderFactoryImpl.createMBeanRegistrationProvider(MBeanRegistrationProviderFactoryImpl.java:37) at net.sf.ehcache.CacheManager.initializeMBeanRegistrationProvider(CacheManager.java:328) at net.sf.ehcache.CacheManager.init(CacheManager.java:320) at net.sf.ehcache.CacheManager.(CacheManager.java:234) at net.sf.ehcache.CacheManager.create(CacheManager.java:608) at com.tgam.escenic.util.CacheUtils.(CacheUtils.java:16) ...

I did not find any ways to prevent net.sf.cache.CacheManager from registering MBeans with the Platform Bean Server. Could you please advise, perhaps send request to Greg Luck in this matter?

Overall, I’m getting a feeling that Mr. Luck and his team introduced a lot of new features since version 1.5 we are currently using on PT. With that said, they forgot that cache instantiation might happen under a very restrictive security manager. And, they should have provided for this use case which they obviously failed to do.

Thanks,

Igor.

Comments

gluck 2009-11-26

This got fixed for Google App Engine independently.