Re: [hibernate-dev] Ehcache integration

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&lt;stliu(a)hibernate.org (mailto:stliu@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&lt;emmanuel(a)hibernate.org >>>>>> (mailto:emmanuel@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(a)lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> -- >>>>> Steve Ebersole&lt;steve(a)hibernate.org (mailto:steve@hibernate.org)> >>>>> http://hibernate.org >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org