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(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<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 <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