On Jul 11, 2011, at 10:48 PM, Alex Snaps wrote:
> Hey guys, > I've finished the port of all the Hibernate h2lc from the ehcache > source base into the hibernate-ehcache module. > Now, polishing this, I also addressed this mapping from old to new names. > You can see the simple fix here: > https://github.com/alexsnaps/hibernate-core/commit/fc5d94e8b0b15b43fc7d5e27db4666626d16bd93 > > But I have a couple of questions here: > - Shouldn't the fact that some mapping happens be logged? Are there > going to stick around? Shouldn't the user be made aware of the fact > that he should change his config? a warning > - Second level cache isn't (yet?) using "ServiceInitiator approach", > is this going to change ? I don't pre-see it, Steve? > - Right now the mapping plan is "weak" in terms of typing since core > doesn't know anything about hibernate-ehcache. I guess, if second > level caching also goes the ServiceInitiator path, that will change, > right ? > > I'll do the pull request as soon as I'm sure it's all ready for it. > Probably sometime tomorrow. > Thanks, > Alex > > On Tue, Jun 21, 2011 at 1:58 PM, Steve Ebersole <st...@hibernate.org> wrote: >> 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<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 >>> >>> >> >> -- >> Steve Ebersole <st...@hibernate.org> >> http://hibernate.org >> > > > > -- > Alex Snaps <alex.sn...@gmail.com> > Senior Software Engineer - Terracotta > http://twitter.com/alexsnaps > http://www.linkedin.com/in/alexsnaps _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
