[hibernate-dev] Ehcache integration

Steve Ebersole steve at hibernate.org
Tue Jun 21 07:58:23 EDT 2011


It would not necessarily require users to change config values.  Just 
update the code that instantiates the RegionFactories 
(org.hibernate.cache.internal.RegionFactoryInitiator) to understand the 
legacy class FQN as well.  Have a look at 
org.hibernate.engine.transaction.internal.TransactionFactoryInitiator 
for an example of somewhere else we do that.

On 06/21/2011 04:56 AM, Alex Snaps wrote:
> Did that... I'll replace internal with ehcache then, as in the infinispan module. But that would still require existing users to change their config though!
>
>
> On Tuesday 21 June 2011 at 11:39, Strong Liu wrote:
>
>> take a look of hibernate-infinispan, we should change hibernate-ehcache package name like that, using "internal" in user's configuration file is not a good ghing
>>
>> -----------
>> Strong Liu<stliu at hibernate.org (mailto:stliu at hibernate.org)>
>> http://hibernate.org
>> http://github.com/stliu
>>
>> On Jun 21, 2011, at 4:42 PM, Alex Snaps wrote:
>>
>>>
>>> On Wednesday 8 June 2011 at 16:47, Strong Liu wrote:
>>>
>>>>
>>>> On Jun 8, 2011, at 9:02 PM, Steve Ebersole wrote:
>>>>
>>>>> The only use case I am really interested in for "simple map based"
>>>>> caching is the test suite. Its the whole reason I did not do the things
>>>>> Strong and I discussed on the other thread already.
>>>>>
>>>>> Perhaps we move "simple map based" caching impl to the hibernate-testing
>>>>> module? The the test suite can continue to use it but we have
>>>>> explicitly published the intent.
>>>>
>>>> actually this was the next question i was going to ask :D
>>>> I have started on this (fyi http://opensource.atlassian.com/projects/hibernate/browse/HHH-6297), but i can't make it into today's release.
>>>> so, if there is no other objection, i will move the concurrent hash map based 2l cache impl into testing module.
>>>>
>>>> btw, the ehcache integration is broken due to the cache spi change, the RegionFactory impl in ehcache project still uses old hibernate package, i have filed them a jira.
>>>
>>> I'm looking into this and am planning to remove the dependency Ehcache currently has on Hibernate and move all the 2LC code to the Hibernate-ehcache module. I think this addresses two issues:
>>> - Packages the right provider code with the right Hibernate version
>>> - Avoids the code duplication between the ehcache module&  ehcache core (I had recently have the hibernate-ehcache code wrap the core code, but that leads us into this kind of trouble now).
>>>
>>> I've somewhat been wondering about the current packaging though. I see it all is packaged in org.hibernate.cache.internal but configuring hibernate.cache.region.factory_class with a class in an "internal" package seems kinda counterintuitive... or is it only to me ? I wonder whether this couldn't remain the org.hibernate.cache package. Also this wouldn't require users to change their config file. But I guess there was a reason for the move...
>>>
>>>>
>>>>>
>>>>> And yes I totally agree that we should be driving folks to proper cache
>>>>> integrations, namely the infinispan and/or ehcache integrations. The
>>>>> others (oscache, swarmcache, etc) have been removed already.
>>>>>
>>>>>
>>>>> On 06/08/2011 07:26 AM, Sanne Grinovero wrote:
>>>>>> I always try to understand what's the main reason motivating people to
>>>>>> use it. Likely the zero dependencies, "let's just try one" ?
>>>>>>
>>>>>> We could bake a very simple implementation based as you say on a
>>>>>> ConcurrentHashMap, and implement a simple eviction is simple. But I'm
>>>>>> afraid that offering such a feature would drive away from proper
>>>>>> implementations, which we should encourage to use.
>>>>>>
>>>>>> Sanne
>>>>>>
>>>>>> 2011/6/8 Emmanuel Bernard<emmanuel at hibernate.org (mailto:emmanuel at hibernate.org)>:
>>>>>>> I always die a little when I see someone using HashtableCacheProvider.
>>>>>>>
>>>>>>> What do you think of removing it entirely. Worse case, we could provide an implementation that is backed by ConcurrentHashMap but even with that, we would get no eviction policy etc.
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>> --
>>>>> Steve Ebersole<steve at hibernate.org (mailto:steve at hibernate.org)>
>>>>> http://hibernate.org
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org



More information about the hibernate-dev mailing list