On Wed, Jul 13, 2011 at 4:46 PM, Strong Liu <st...@hibernate.org> wrote: > > > 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
Sounds fair. I already did a pull request. But I think this warning should be for all these mappings, afaict the TransactionFactoryInitiator should probably also get it right ? Should I file a jira for this ? >> - 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 > > -- 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
