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.
