• New Feature
  • Status: Closed
  • 1 Critical
  • Resolution: Fixed
  • alexsnaps
  • Reporter: stliu
  • May 30, 2011
  • 1
  • Watchers: 1
  • July 27, 2012
  • July 19, 2011


from hibernate 4.0.0.Alpha3, the old cache api has moved into org.hibernate.cache.spi, see http://opensource.atlassian.com/projects/hibernate/browse/HHH-6191

and the current ehcache version (used in hibernate-ehcache module) is broken, http://opensource.atlassian.com/projects/hibernate/browse/HHH-6276


Alexander Snaps 2011-06-01

Basically they’ve changed packaging, resulting in a non backward compatible change from their side. In order to support 4.0, I see three options here :

  • Isolate all loading of 3.x Hibernate API/SPI classes that changed and provide 2 H2LC provider. We then either sort the Hibernate version out at runtime for the user, or ask him to configure the right provider in his config.
  • Keep core as is with the 3.x providers and have an additional module for Hibernate 4.0. As previously, either the user configures his provider with the right version, or we programmatically use the proper one automatically if the 4.0 jar is present (or again through figuring out the hibernate version)
  • Or, finally, we have the both hibernate providers live in their own module.

The last option comes in two flavors:

  • either we use the existing ones in the hibernate repo (and distributions);
  • or we maintain them ourselves.

I find the first option pretty messy, as ehcache-core would depend on both versions of Hibernate, or requires some maven packaging tricks to “merge” the hiberante modules into the core distribution. Option 2 would require to be clear about problems related to people upgrading hibernate, but not dropping the new jar on their classpath. i.e. a clear error message. I personally am in favor of the 3rd option, with the code living on the Hibernate repo and being distributed with each Hibernate version. That way the user wouldn’t have to know or even care what hibernate-ehcache module he requires. Also, what ever the future might bring, we’ll be able to support all changes. It fixes the issue of the user having to choose between 2 different providers as well: the hibernate packaged one, or the ehcache-core one. Not mentioning the single code base to maintain, rather than 2 as we do now… Downside of the approach is that only Greg has currently commit access and I don’t know whether we could have dedicated releases for the hibernate-ehcache module (if it is currently only released as part of a Hibernate release or should that ever be required).

Fiona OShea 2011-06-01

I can’t find a dup of this. Perhaps we were thinking of the previous updates we did DEV-5690. Anyway this does need further discussion, prioritization and planning. Leaving assigned to DRB so that we can discuss at our meeting on Tuesday. Greg do you have any comments to add to this?

Alexander Snaps 2011-06-09

Hibernate 4.0.0 beta 1 has been released… We might want to start looking in addressing this.

Alexander Snaps 2011-07-12

Pull request send to the hibernate team: https://github.com/hibernate/hibernate-core/pull/128

Alexander Snaps 2011-07-14

Have done different changes based on the comments on the pull request. New pull request, with the desired changes here: https://github.com/hibernate/hibernate-core/pull/129

Alexander Snaps 2011-07-19

Pull request accepted on master