1:23 p.m.
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.
2:26 p.m.
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 <emmanuel(a)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
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:02 p.m.
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.
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<emmanuel(a)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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
4:38 p.m.
Moving it to the hibernate-testing module seems like a good idea to me.
On 8 juin 2011, at 15:02, 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.
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<emmanuel(a)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
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
4:39 p.m.
+1, people can still use it by depending on that. at least they will
be aware that it's recommended to run tests only, which is IMO a
correct use case.
2011/6/8 Emmanuel Bernard <emmanuel(a)hibernate.org>:
Moving it to the hibernate-testing module seems like a good idea to
me.
On 8 juin 2011, at 15:02, 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.
>
> 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<emmanuel(a)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
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
4:47 p.m.
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.
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<emmanuel(a)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
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:49 p.m.
Yeah, I have spoken with them about it via email as well, so they are
aware of it.
On 06/08/2011 09:47 AM, 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.
>
> 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<emmanuel(a)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
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Steve Ebersole<steve(a)hibernate.org>
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
9:01 p.m.
Moving it to the hibernate-testing module seems like a good idea to
me.
Sounds good to me too - the only quirk for it that I recall was that tools like
schemaexport etc.
shouldn't require cacheproviders, but if the cacheprovider is lazily loaded (i.e. not
actually instantiated
until used) or there is a way to globally disable it easily just for running schemaexport
then that would
solve that.
-max
On 8 juin 2011, at 15:02, 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.
>
> 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<emmanuel(a)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
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
/max
http://about.me/maxandersen
10:42 a.m.
New subject: Ehcache integration
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<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 <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
11:39 a.m.
New subject: Ehcache integration
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 <stliu(a)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<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 <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
11:56 a.m.
New subject: Ehcache integration
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 <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<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 <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
12:04 p.m.
New subject: Ehcache integration
yes, but thats the pain we must take....
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
On Jun 21, 2011, at 5:56 PM, 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 <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<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 <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
1:58 p.m.
New subject: Ehcache integration
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<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<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<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>
http://hibernate.org
4:48 p.m.
New subject: 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> 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<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<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<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>
http://hibernate.org
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
4:46 p.m.
New subject: 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/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?
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 <steve(a)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<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<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<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>
> http://hibernate.org
>
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
5:40 p.m.
New subject: Ehcache integration
On Wed, Jul 13, 2011 at 4:46 PM, Strong Liu <stliu(a)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/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?
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 <steve(a)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<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<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<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>
>> http://hibernate.org
>>
>
>
>
> --
> Alex Snaps <alex.snaps(a)gmail.com>
> Senior Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
5:49 p.m.
New subject: Ehcache integration
On Jul 13, 2011, at 11:40 PM, Alex Snaps wrote:
On Wed, Jul 13, 2011 at 4:46 PM, Strong Liu
<stliu(a)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/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?
>
> 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 <steve(a)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<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<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<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>
>>> http://hibernate.org
>>>
>>
>>
>>
>> --
>> Alex Snaps <alex.snaps(a)gmail.com>
>> Senior Software Engineer - Terracotta
>> http://twitter.com/alexsnaps
>> http://www.linkedin.com/in/alexsnaps
>
>
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
10:54 p.m.
New subject: 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
--
steve(a)hibernate.org
http://hibernate.org
10:57 p.m.
New subject: 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
--
steve(a)hibernate.org
http://hibernate.org
3:18 a.m.
New subject: 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
--
steve(a)hibernate.org
http://hibernate.org
10:57 a.m.
New subject: Ehcache integration
Yeah.
I wanted to have an EhcacheIntegratorService registered, that would,
during the integrate call, do the potential mapping from old to new
name (so this would be able to use ....class.getName()).
Also, I could keep a ref to the ServiceRegistry, so I'd be able to
address any classloader concerns you mentioned.
Not sure what that would give wrt to the hack on getting the
RegionFactory in org.hibernate.cfg.SettingsFactory.createRegionFactory
But anyways, I don't really see how to plug that integrator in... So
that seems like the wrong path.
On Thu, Jul 14, 2011 at 3:18 AM, Strong Liu <stliu(a)hibernate.org> wrote:
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
>
> --
> steve(a)hibernate.org
> http://hibernate.org
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
11 a.m.
New subject: Ehcache integration
Alex
(i already commented in your pull request)
cache provider is integrated by org.hibernate.cache.internal.RegionFactoryInitiator, and
the mapLegency should go into this class too.
it is in process of moving from SettingsFactory.createRegionFactory to
RegionFactoryInitiator
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
On Jul 14, 2011, at 4:57 PM, Alex Snaps wrote:
Yeah.
I wanted to have an EhcacheIntegratorService registered, that would,
during the integrate call, do the potential mapping from old to new
name (so this would be able to use ....class.getName()).
Also, I could keep a ref to the ServiceRegistry, so I'd be able to
address any classloader concerns you mentioned.
Not sure what that would give wrt to the hack on getting the
RegionFactory in org.hibernate.cfg.SettingsFactory.createRegionFactory
But anyways, I don't really see how to plug that integrator in... So
that seems like the wrong path.
On Thu, Jul 14, 2011 at 3:18 AM, Strong Liu <stliu(a)hibernate.org> wrote:
>
>
> 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
>>
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
>
>
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
11:05 a.m.
New subject: Ehcache integration
Strong,
I did fix that that way now indeed (moved the static method to
RegionFactoryInitiator and made it public for now, given the hack
still in place). I'll look into having the EhcacheIntegratorService
loaded none the less and so I get the ClassLoaderService available in
the EhcacheRegionFactories.
Thanks!
On Thu, Jul 14, 2011 at 11:00 AM, Strong Liu <stliu(a)hibernate.org> wrote:
Alex
(i already commented in your pull request)
cache provider is integrated by org.hibernate.cache.internal.RegionFactoryInitiator, and
the mapLegency should go into this class too.
it is in process of moving from SettingsFactory.createRegionFactory to
RegionFactoryInitiator
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
On Jul 14, 2011, at 4:57 PM, Alex Snaps wrote:
> Yeah.
> I wanted to have an EhcacheIntegratorService registered, that would,
> during the integrate call, do the potential mapping from old to new
> name (so this would be able to use ....class.getName()).
> Also, I could keep a ref to the ServiceRegistry, so I'd be able to
> address any classloader concerns you mentioned.
> Not sure what that would give wrt to the hack on getting the
> RegionFactory in org.hibernate.cfg.SettingsFactory.createRegionFactory
> But anyways, I don't really see how to plug that integrator in... So
> that seems like the wrong path.
>
> On Thu, Jul 14, 2011 at 3:18 AM, Strong Liu <stliu(a)hibernate.org> wrote:
>>
>>
>> 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
>>>
>>> --
>>> steve(a)hibernate.org
>>> http://hibernate.org
>>
>>
>
>
>
> --
> Alex Snaps <alex.snaps(a)gmail.com>
> Senior Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
11:13 a.m.
New subject: Ehcache integration
okay, so the problem is you need ServiceRegistry in your ehcache RegionFactory impl,
right?
you can do it this way:
class EhcacheRegionFactory implements RegionFacotry{
private ClassLoaderService classLoaderService;
@InjectService
public void setClassLoaderService(ClassLoaderService classLoaderService) {
this.classLoaderService = classLoaderService;
}
.....
}
then the ClassLoaderService will be injected automaticly
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
On Jul 14, 2011, at 5:05 PM, Alex Snaps wrote:
Strong,
I did fix that that way now indeed (moved the static method to
RegionFactoryInitiator and made it public for now, given the hack
still in place). I'll look into having the EhcacheIntegratorService
loaded none the less and so I get the ClassLoaderService available in
the EhcacheRegionFactories.
Thanks!
On Thu, Jul 14, 2011 at 11:00 AM, Strong Liu <stliu(a)hibernate.org> wrote:
> Alex
>
> (i already commented in your pull request)
>
> cache provider is integrated by org.hibernate.cache.internal.RegionFactoryInitiator,
and the mapLegency should go into this class too.
> it is in process of moving from SettingsFactory.createRegionFactory to
RegionFactoryInitiator
>
> -----------
> Strong Liu <stliu(a)hibernate.org>
> http://hibernate.org
> http://github.com/stliu
>
> On Jul 14, 2011, at 4:57 PM, Alex Snaps wrote:
>
>> Yeah.
>> I wanted to have an EhcacheIntegratorService registered, that would,
>> during the integrate call, do the potential mapping from old to new
>> name (so this would be able to use ....class.getName()).
>> Also, I could keep a ref to the ServiceRegistry, so I'd be able to
>> address any classloader concerns you mentioned.
>> Not sure what that would give wrt to the hack on getting the
>> RegionFactory in org.hibernate.cfg.SettingsFactory.createRegionFactory
>> But anyways, I don't really see how to plug that integrator in... So
>> that seems like the wrong path.
>>
>> On Thu, Jul 14, 2011 at 3:18 AM, Strong Liu <stliu(a)hibernate.org> wrote:
>>>
>>>
>>> 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
>>>>
>>>> --
>>>> steve(a)hibernate.org
>>>> http://hibernate.org
>>>
>>>
>>
>>
>>
>> --
>> Alex Snaps <alex.snaps(a)gmail.com>
>> Senior Software Engineer - Terracotta
>> http://twitter.com/alexsnaps
>> http://www.linkedin.com/in/alexsnaps
>
>
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
12:52 p.m.
New subject: Ehcache integration
Right, which would work once the ServiceRegistry will be used. Just
did a couple of test with changing the RegionFactory Lookup code and
it seems like it's all working fine. So that is injected, it'll use
ClassLoaderService.locateResource now. Still have to look into why it
didn't work when the method was declared on the Abstract class
though... Given the quick look I had, it should have had. Anyways...
Also tried the Integrator approach to map legacy names in the prop and
replace it there, but it looks like this happens after the
RegionFactory has been instantiated already. So I'll leave the mapping
code in the RegionFactoryInitiator.
I'll delete that code and cleanup and will do another pull request later today.
Thanks a lot for you help Strong!
On Thu, Jul 14, 2011 at 11:13 AM, Strong Liu <stliu(a)hibernate.org> wrote:
okay, so the problem is you need ServiceRegistry in your ehcache
RegionFactory impl, right?
you can do it this way:
class EhcacheRegionFactory implements RegionFacotry{
private ClassLoaderService classLoaderService;
@InjectService
public void setClassLoaderService(ClassLoaderService classLoaderService) {
this.classLoaderService = classLoaderService;
}
.....
}
then the ClassLoaderService will be injected automaticly
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
On Jul 14, 2011, at 5:05 PM, Alex Snaps wrote:
> Strong,
> I did fix that that way now indeed (moved the static method to
> RegionFactoryInitiator and made it public for now, given the hack
> still in place). I'll look into having the EhcacheIntegratorService
> loaded none the less and so I get the ClassLoaderService available in
> the EhcacheRegionFactories.
> Thanks!
>
> On Thu, Jul 14, 2011 at 11:00 AM, Strong Liu <stliu(a)hibernate.org> wrote:
>> Alex
>>
>> (i already commented in your pull request)
>>
>> cache provider is integrated by
org.hibernate.cache.internal.RegionFactoryInitiator, and the mapLegency should go into
this class too.
>> it is in process of moving from SettingsFactory.createRegionFactory to
RegionFactoryInitiator
>>
>> -----------
>> Strong Liu <stliu(a)hibernate.org>
>> http://hibernate.org
>> http://github.com/stliu
>>
>> On Jul 14, 2011, at 4:57 PM, Alex Snaps wrote:
>>
>>> Yeah.
>>> I wanted to have an EhcacheIntegratorService registered, that would,
>>> during the integrate call, do the potential mapping from old to new
>>> name (so this would be able to use ....class.getName()).
>>> Also, I could keep a ref to the ServiceRegistry, so I'd be able to
>>> address any classloader concerns you mentioned.
>>> Not sure what that would give wrt to the hack on getting the
>>> RegionFactory in org.hibernate.cfg.SettingsFactory.createRegionFactory
>>> But anyways, I don't really see how to plug that integrator in... So
>>> that seems like the wrong path.
>>>
>>> On Thu, Jul 14, 2011 at 3:18 AM, Strong Liu <stliu(a)hibernate.org>
wrote:
>>>>
>>>>
>>>> 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
>>>>>
>>>>> --
>>>>> steve(a)hibernate.org
>>>>> http://hibernate.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Alex Snaps <alex.snaps(a)gmail.com>
>>> Senior Software Engineer - Terracotta
>>> http://twitter.com/alexsnaps
>>> http://www.linkedin.com/in/alexsnaps
>>
>>
>
>
>
> --
> Alex Snaps <alex.snaps(a)gmail.com>
> Senior Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
4663
days inactive
4699
days old
24 comments
6 participants
participants (6)
-
Alex Snaps -
Emmanuel Bernard -
Max Rydahl Andersen -
Sanne Grinovero -
Steve Ebersole -
Strong Liu