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 <st...@hibernate.org (mailto:st...@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<emman...@hibernate.org > > > > > (mailto:emman...@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@lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) > > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > > > > hibernate-dev mailing list > > > > > hibernate-dev@lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > -- > > > > Steve Ebersole <st...@hibernate.org (mailto:st...@hibernate.org)> > > > > http://hibernate.org > > > > _______________________________________________ > > > > hibernate-dev mailing list > > > > hibernate-dev@lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
