EHC ❯ ClassLoading
-
Bug
-
Status: Open
-
2 Major
-
Resolution:
-
ehcache,ehcache-core
-
-
teck
-
Reporter: anthoncb
-
September 14, 2012
-
1
-
Watchers: 7
-
January 13, 2017
-
Attachments
Description
When you use EHCache in OSGi Environment, if you are using EHCache in OSGi Container and Applicactions Server classpath, inside same JVM, you get a ClassCastException because EHCache first resolve in thread classpath and after in bundle classpaath, and it should the other way around: first bundle classpath and after in thread classpath. This bug is located in net.sf.ehcache.util.ClassLoaderUtil.loadClass method. It must be like taht:
public static Class loadClass(String className) throws ClassNotFoundException { Class clazz; try { clazz = Class.forName(className, true, getFallbackClassLoader()); } catch (ClassNotFoundException e) { // try standard clazz = Class.forName(className, true, getStandardClassLoader()); } return clazz; }
Regards.
Comments
Tim Eck 2013-01-16
Antonio Simon 2013-01-21
Hi Tim. I´m Antonio who post the bug. I can’t replay the error but I got the follow excepction when I created a instance of net.sf.ehcache.CacheManager:
net.sf.ehcache.CacheException: Unable to load class net.sf.ehcache.store.DefaultElementValueComparator. Initial cause was net.sf.ehcache.store.DefaultElementValueComparator.
The ClassLoaderUtil class is the problem because first call a loadClass method from ClassLoaderUtil class. This method first load in TCCL and if a exception ocurrs then load in FallbackClassLoader. In that situation, TCCL find and load the class but the clazz obtained belong a different ClassLoader and not match with de parameter type ClassLoader.
In my situation, there are two ehcache.jar in the same JMV process because one is for classpath server aplication and other is for OSGi container. In OSGi container, every jar (called bundle) has his own ClassLoader.
Regards.
Antonio Simon 2013-01-21
I add the exception is thrown by the ehcache.jar (bundle in osgi) becasuse its ClassLoader is different than Aplication Server ClassPath (TCCL).
Tim Eck 2013-01-22
thanks for the details. I think I’ve already captured the same issue here in EHC-989 (not that it is fixed though).
Shravya Yakkali 2017-01-13
@Antonio Simon, thanks for the detailed analysis of the issue. I am facing the exact same issue, where I am using ehcache within an osgi bundle deployed in an osgi container embedded in a java application. I am resetting the TLCC with the bundle’s classloader when I enter the bundle and putting back when I am exiting.
Not all paths into ClassLoaderUtil.loadClass() I think are appropriate for such a reversal of the loaders I think. Preference for the TCCL I think is appropriate for loading the values of objects in the cache. One place where the current logic doesn’t make sense is when loading classes that are part of the ehcache library implementation itself.
Can you be a little more specific about which class load you encountered this in? I can see that if there are multiple ehcache.jars present that things can get messy, but I’m not convinced yet about the proper solution. In particular just changing the logic as described I don’t think is appropriate in all cases