Re: [hibernate-dev] Ehcache integration

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/fc5d94e8b0b15b43fc7d5e... 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?

- Second level cache isn't (yet?) using "ServiceInitiator approach", is this going to change ?

- 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 <steve(a)hibernate.org&gt; 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&lt;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&lt;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&lt;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 >> >> > > -- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > -- Alex Snaps <alex.snaps(a)gmail.com&gt; Senior Software Engineer - Terracotta http://twitter.com/alexsnaps http://www.linkedin.com/in/alexsnaps