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