On Oct 14, 2012, at 11:38 PM, Jason Pell <[email protected]> wrote:
> Its right there: > > http://ehcache.org/documentation/get-started/key-classes-methods > > So I guess my point to the dev's is if you want to upgrade to ehcache > 2.5.2 or even 2.6.1+ there is a significant change in behaviour post > 2.5.1. > > Any suggestions for how CXF would either handle both versions with > perhaps a different EHCacheManagerHolder? Well, I think we could updated the CXF dependency to 2.5.2. That would get the newInstance method available at compile time. Then the EHCacheManager could do something like: private CacheManager tryNewInstance(….) { try { return CacheManager.newInstance(….); } catch (Error e) { return CacheManager.create(…..); } } or similar. I think it's a NoSuchMethodError or similar raised if 2.5.1 is picked up. You'd have to experiment a bit to check. You could also do something like; static final boolean SUPPORTS_NEWINSTANCE; static { boolean b = false; try { CacheManager.class.getMethod("newInstance"); b = true: } catch (Throwable t) { b = false; } SUPPORTS_NEWINSTANCE = b; } and then use that boolean to determine which method to use. Dan > On Mon, Oct 15, 2012 at 2:31 PM, Jason Pell <[email protected]> wrote: >> Ok so I understand now. We are using ehcache 2.5.2. And >> create(Configuration) method in 2.5.2 is different to 2.5.1. >> >> In 2.5.1 if you call it checks the name of the Configuration and >> creates a new cache manager with this name. >> >> In 2.5.2 the same method does something quite different. If any code >> has called CacheManager.create() previously this will cause the >> singleton to be initialised and in 2.5.2 all the create methods ignore >> the Configuration name if the singleton has a value. >> >> The newInstance methods in CacheManager do what is expected of them by >> CXF in 2.5.2 and onwards. >> >> Very strange to have such a significant change in behaviour between >> point releases. >> >> On Mon, Oct 15, 2012 at 10:07 AM, Jason Pell <[email protected]> wrote: >>> Realised its not what I thought. The cache manager is named according >>> to the cxf bus id and thus is not the same name as the default cache >>> manager. So I must have another problem. Will investigate further. >>> >>> Please ignore my issue for now :-) >>> >>> On Mon, Oct 15, 2012 at 8:30 AM, Jason Pell <[email protected]> wrote: >>>> Hi, >>>> >>>> I have run into a problem because by default the ehcache replaycache code >>>> results in sharing the global eh cache manager. (The CacheManager.create() >>>> call) >>>> >>>> This is a problem if using ehcache for ldap user cache if i restart an >>>> endpoint because the cache manager is shutdown by cxf. >>>> >>>> I am still investigating the ideal approach to this whether its to >>>> implement >>>> my own replay cache or contribute patches to configure whether to shut down >>>> the manager or let some other non cxf trigger do that. >>>> >>>> I am leaning towards the latter. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
