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 > >
