ehcache 2.5.x jcache wrapper

[lorban]

I've updated the ehcache-core dependency to the latest released version and I fixed an annoying bug in JCacheManager.getCaches().

[ryangardner]

These changes look good to me. I'll try to merge this tonight or tomorrow after I verify that the TCK tests for the 0.4 jsr107 api still pass.

(It will be good to get these changes in before starting the work on updating the wrapper to work against the 0.5 version of the spec)

[gregrluck]

I tested the pull request.

Failed tests: removeCache_There(javax.cache.CacheManagerTest)
getCaches_MutateCacheManager(javax.cache.CacheManagerTest): expected:<2> but was:<3>
iterator_Empty(javax.cache.CacheTest)

Tests in error:
shutdown_cachesEmpty(javax.cache.CacheManagerTest): The CacheManager has been shut down. It can no longer be used.

Tests run: 236, Failures: 3, Errors: 1, Skipped: 0

Ludovic. Please run mvn clean install to reproduce these failures.

[ryangardner]

I have looked into this and also saw the same TCK failures that Greg saw. (To see them, you can run "mvn package" on the top level of the directory structure - after it compiles the ehcache-jcache module it will run the ehcache-jcache-tck-runner module build which runs through all the tck tests for you)

Curiously, the upgrade to ehcache 2.5.1 without any other changes causes one test failure:

Failed tests:   iterator_Empty(javax.cache.CacheTest)

I'll dive into this some more - but I might not get time until Saturday to do so. (There's another issue that was fixed in 2.5.1 that the current ehcache-jcache 1.4-beta-1 contains a workaround for that will be nice to remove.)

Regarding the cache manager ones, I'll have to dive into those - I seem to remember having to put that behavior in specifically to get those tests to pass, but in the long run the behavior of getCaches<> might be best to have it return any cache that is configured (such as through an xml config or something). Because the external configs of the caches are not part of the spec, the TCK doesn't have any tests around expectations for behavior with additional caches, and in this case some of the tests might be accidently forbidding behavior that will be useful when an external config is used.

(I assume that's what this issue is about, right Ludovic? - because if the cache isn't configured externally from the JSR107 cache manager and the caches are only configured via the getCache method - then the getCaches returning only caches created via getCache would give you the expected set of caches)

[ryangardner]

I've fixed the issue that was causing the TCK tests to fail when it was running against 2.5.1 and pushed those changes (plus upgrading the pom to 2.5.1) to the master branch. I haven't had a chance to look at why the other change set causes the other tests to fail yet.

[gregrluck]

Does this mean we can release it?

On 25/03/2012, at 9:35 PM, Ryan Gardner wrote:

I've fixed the issue that was causing the TCK tests to fail when it was running against 2.5.1 and pushed those changes (plus upgrading the pom to 2.5.1) to the master branch. I haven't had a chance to look at why the other change set causes the other tests to fail yet.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

Regards

Greg Luck

web: http://gregluck.com
skype: gregrluck
yahoo: gregrluck
mobile: +61 408 061 622

[ryangardner]

The only change between 1.4-beta-1 and the current master branch is that the version of ehcache specified in the pom for the current one is 2.5.1. It's still using 0.4 of the spec and TCK.

At this point, it's safe to release 1.4-beta-2 that goes against the 0.4 spec and uses ehcache 2.5.1.

There is another branch that I just pushed up that compiles against the 0.5 spec but doesn't pass the 0.5 TCK yet (I just opened issue #6 to use to track the progress on the 0.5-related refactoring)