On Jul 13, 2011, at 11:40 PM, Alex Snaps wrote: > 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 ?
this is a different case, since we do not provide a non-internal impl for transaction factory. (but we may improve this by adding an alternative name for that three like 'jta', 'jdbc', 'cmt') > >>> - 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
