EHC ❯ LibraryInit makes it very hard to use Ehchache in OSGi
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
teck
-
Reporter: mattbish
-
January 10, 2013
-
0
-
Watchers: 6
-
February 19, 2014
-
January 29, 2013
Description
Post-2.6.0 (I found this in 2.6.2, but Jira doesn’t have a version for 2.6.2 yet), Ehcache-core introduced LibraryInit, a class that uses the JDK’s ServiceLoader mechanism to find an implementation of EhcacheInit.class to use to init the cache.
This initService() method uses a different classloader (hard-coded to CacheManager.class.getClassLoader() to search META-INF/services for the implementation class. This causes a failure in OSGi environments (I am using felix) because the OSGi environment does not give that classloader access to the META-INF dir.
The more acceptable approach is to use the context classloader, like this:
ServiceLoader.load(EhcacheInit.class);
This can be reasoned with by the OSGi environment to provide access to the proper META-INF dirs to successfully locate the implementation.
Probably a better approach altogether to make the ServiceLoader definition an optional configuration path. If ServiceLoader cannot find an instance of EhcacheInit, then just default to EhcacheCoreInit directly. The default init class does nothing anyways, so no harm is done.
Comments
Tim Eck 2013-01-16
Matt Bishop 2013-01-18
OSGi provides a weird cl to classes but TCCL gets one that can see the resources.
I was just using core not big memory. Have a search for OSGi and service loaders for details on how to design this successfully. I am happy to test it
Tim Eck 2013-01-18
from what I’ve read it seems like the sanest thing I can do with using java.util.ServiceLoader would be to try both the current loader and TCCL. At least when I try to consider all potential environments ehcache might be used in. Feel free to comment more, but I’ve tentatively decided to change the code to prefer TCCL first on the ServiceLoader call and fallback to signature that takes an explict loader (ie. the current code)
Matt Bishop 2013-01-18
Ok. I’d still plan a fallback to a specific loader class if all the service loaders come up empty.
Tim Eck 2013-01-29
prefer TCCL loader for service lookup
fix applied to 2.6.x and 2.7.x
Gaurav Mangalick 2014-01-27
Already released with 3.7.4, marking this issue as closed.
thanks for the feedback. This LibraryInit business is a bit of a moot point at the moment since it only serves to require the bigmemory.jar when using ehcache-ee.jar (as opposed to ehcache-core-ee.jar which is not intended to be mixed with bigmemory.jar). This jar business is all very confusing for the 2.6.x line of ehcache. We’re simplifying the world for 2.7.x and this LibraryInit doesn’t exist there (yet).
I’ll admit I’m not a felix (or OSGi for that matter) expert but why can’t the bundle loader for ehcache see it’s own resources under META-INF but the TCCL would?
Perhaps you could tell me if you were using ehcache-ee.jar + bigmemory.jar or if you’re just using ehcache-core.jar it might clarify things for me a bit too. You didn’t explicitly say it, but I suspect you maybe got an exception with message “No EhcacheInit services found”. Were you able to workaround it?