EHC ❯ Funny classloading semantics in ehcache
-
Bug
-
Status: Open
-
2 Major
-
Resolution:
-
-
-
teck
-
Reporter: teck
-
October 17, 2012
-
0
-
Watchers: 6
-
April 16, 2015
-
Description
There are places in ehcache where we use ClassLoaderUtil to dynamically locate internal components. That is well and good but I don’t think we should use the policy of preferring the TCCL for loading these classes.
Additionally it is very odd that we allow the TCCL load the desired class but we .class literals to load the argument types.
Examples of this include the enterprise features manager or the TC clustered instance factory.
It seems at least for classes that are internal to the ehcache impl we should always only explicitly use the defining loader of ehcache for these loads (ie. never TCCL)
Comments
d d 2013-09-20
Aliabbas Surti 2014-02-18
Hi Tim,
We are facing the same issue in Liferay version 6.2. I have tried the solution that donino has mentioned in the above post but that did not work for us.
I tried using the latest version ehcache 2.8.0 but that did not help too.
Is there any timeline on when this bug is scheduled to be fixed? It would be great if you could please provide us that.
Many thanks.
Tim Eck 2014-03-20
There are _some_ changes around this but only planned for ehcache 2.9.0 at the moment
Aliabbas –> Can you share anymore information? In particular I’d like to see what exception you’re getting (presumably a ClassCastException) and the stack trace involved. Simply hacking the order of order lookups in ClassLoaderUtil is not the right thing to do.
Aliabbas Surti 2014-03-23
Hi Tim,
Here is the stack trace,
05:13:39,643 ERROR [localhost-startStop-2][HotDeployImpl:208] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering plugins for
Tim Eck 2014-03-24
Thanks for the stack trace. That certainly looks like the kind of issue that can arise from the problem I describe in this ticket.
The changes I’ve made in ehcache trunk (slated to become ehcache 2.9.0) I think you would at least give you a different result here, but hopefully just “work”
I don’t understand why flipping the order of classloaders in ClassLoaderUtil wouldn’t work for you, that doesn’t add up me for me. Again I don’t reccommend hacking on that class to make things work, but it suspicious that it wouldn’t at least change the problem.
All this said, I think I can assert that there is more than version of ehcache floating around in your system somehow. The thread in the stack trace above has it’s thread context class loader set to something that can load ehcache classes. That loader also differs from the classloader which defined the instance of CacheManager that com.liferay.portal.cache.ehcache.EhcachePortalCacheManager calls upon.
As a data point you could try setting the TCCL explicitly to see what happens:
ClassLoader prev = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(cacheManager.getClass().getClassLoader());
cacheManager.addCache(...);
finally {
Thread.currentThread().setContextClassLoader(prev);
}
Sampsa Sohlman 2015-04-16
Hey Tim Eck,
Could you point out the correct fix location?
Sampsa Sohlman 2015-04-16
To be more precise:
“The changes I’ve made in ehcache trunk (slated to become ehcache 2.9.0) I think you would at least give you a different result here, but hopefully just “work””
It seems that ehcache 2.9.0 is solving the problems with Liferay, so I’m looking the correct changes.
Hi,
We run into this issue with Liferay portal 6.2: Both the portal and a portlet plugin ship with Ehcache 2.7.1, and because of TCCL priority we keep jumping from the portal classloader to the plugin classloader.
So i modified net.sf.ehcache.util.ClassLoaderUtil to give priority to ClassLoaderUtil.class.getClassLoader(), and it solved all troubles. Is it planned to do a such update in a future ehcache version?
Thanks!