• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

The use of Thread.currentThread().getContextClassLoader() to obtain the classloader for creating new instances doesn’t work properly in all cases - the contextClassLoader isn’t always updated.

The usual approach in this situation is to try either the classloader used by the class, OR the contextClassLoader, and then, if the class is not found, fall back to the other.

Case in point: hloader can use ehcache depending on the config file being used. Using hloader inside Ant currently requires ehcache on the system class path, while with ehcache 1.1 it was sufficient to put in on the task’s classpath. Sourceforge Ticket ID: 1506399 - Opened By: robertdw - 14 Jun 2006 23:38 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320

Hi

I have added a fallback class loader which is tried if the context class loader fails.

/** * Gets a fallback ClassLoader that all classes in ehcache, and extensions, should use for classloading. * This is used if the context class loader does not work. * @return the ClassLoaderUtil.class.getClassLoader(); */ public static ClassLoader getFallbackClassLoader() { return ClassLoaderUtil.class.getClassLoader(); }

The code that uses it is:

try { clazz = Class.forName(className, true, getStandardClassLoader()); } catch (ClassNotFoundException e) { //try fallback try { clazz = Class.forName(className, true, getFallbackClassLoader()); } catch (ClassNotFoundException ex) { throw new CacheException(“Unable to load class “ + className + “. Initial cause was “ + e.getMessage(), e); } }

This is in trunk and will be in ehcache-1.2.1.

Greg Comment by: gregluck - 15 Jun 2006 10:54 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira