I have created a jira and attached a project which demonstrates the problem with cxf + ehcache 2.5.2
https://issues.apache.org/jira/browse/CXF-4577 I will be working on a fix when I have an opportunity. On Tue, Oct 16, 2012 at 5:23 AM, Jason Pell <[email protected]> wrote: > Ok cool I was not sure if that was ok to do or not here. I was thinking I > might do some refactoring to make it easier to say share a app wide cache > manager and being a good citizen by not calling shutdown in that case. It > would be configurable the default would be to create own cache manager > > Sent from my Galaxy S2 > > On Oct 16, 2012 2:40 AM, "Daniel Kulp" <[email protected]> wrote: >> >> >> 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 >> >
