Re: [hibernate-dev] Ehcache integration
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/fc5d94e8b0b15b43fc7d5e27db426d16bd93 > > 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 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 Liumailto: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
Re: [hibernate-dev] Ehcache integration
On Wed, Jul 13, 2011 at 4:46 PM, Strong Liu 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/fc5d94e8b0b15b43fc7d5e27db426d16bd93 >> >> 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 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 Liumailto: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
Re: [hibernate-dev] Ehcache integration
On Jul 13, 2011, at 11:40 PM, Alex Snaps wrote: > On Wed, Jul 13, 2011 at 4:46 PM, Strong Liu 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/fc5d94e8b0b15b43fc7d5e27db426d16bd93 >>> >>> 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 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 Liumailto: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
Re: [hibernate-dev] save the planet one non character stroke at a time
I guess maybe this is hassle based on which project key you are talking about. For HHH- that is not an undue burden imo. On Tue 12 Jul 2011 04:50:08 AM CDT, Sanne Grinovero wrote: > +1. > Often we mix many issue numbers in a pull request - as far as I see > we're all fine in picking one of them as most significant, let me know > if somebody strongly prefers 1:1 pull requests and issues.. that's > more time consuming as it means we can't start working on depending > issues until the first one is approved. > > The jboss.org JIRA has an automated process to automatically mark > issues as fixed when the relevant pull request is merged in master. > For this to work when issuing the pull request you still have to add a > link to the pull request on a field in JIRA, so you still have to > switch contexts, I'm not sure yet if we're winning some time. > > A definite improvement would be a "search provider" plugin for firefox, so > that > 1) I can paste issue numbers in the search box without opening JIRA first > 2) As the Skype plugin does with telephone numbers converting them in > "call this number links, have a plugin scanning the HTML of any > service and email to convert them in JIRA links. This would be > reasonable only if we keep the project part of the issue name too, but > I guess we'll still have that in many other places (apart of the > branch name). > Something to try creating when all issues are solved :) > > Cheers, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Ehcache integration
On 07/13/2011 09:46 AM, Strong Liu wrote: > On Jul 11, 2011, at 10:48 PM, Alex Snaps wrote: > > 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 ? org.hibernate.cache.internal.RegionFactoryInitiator -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Ehcache integration
Or do you mean java.util.ServiceLoader ? On Wed 13 Jul 2011 03:54:16 PM CDT, Steve Ebersole wrote: > On 07/13/2011 09:46 AM, Strong Liu wrote: >> On Jul 11, 2011, at 10:48 PM, Alex Snaps wrote: >> >> 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 ? > > org.hibernate.cache.internal.RegionFactoryInitiator -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Ehcache integration
On Jul 14, 2011, at 4:57 AM, Steve Ebersole wrote: > Or do you mean java.util.ServiceLoader ? yes, i think Alex means this > > On Wed 13 Jul 2011 03:54:16 PM CDT, Steve Ebersole wrote: >> On 07/13/2011 09:46 AM, Strong Liu wrote: >>> On Jul 11, 2011, at 10:48 PM, Alex Snaps wrote: >>> >>> 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 ? >> org.hibernate.cache.internal.RegionFactoryInitiator > > -- > st...@hibernate.org > http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
