Exactly,
I'm struggling to find a JSR-107 second-level cache to plug in my project.
EHCache 3.x does not integrate with hibernate yet, neither does hazelcast -
they have a PR, but they'll merge it in the next couple of months. Oracle
Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a
one-year old beta release, which I'm not sure is jcache compliant, and
Infinispan, as I understand, works as a separate service, and I want to
have it embedded in my spring project. This is really embarrassing - a
cache is essential to any application and seems like there is no free,
robust, open-source, embeddable, JSR-107-compatible cache implementation.
2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
So then it sounds like "no" to this, which is fine. We
already have
updated to a much newer Ehcache and as pointed out earlier the stability in
the Ehcache API actually used in the integration means any 2.x version of
Ehcache should be fine to drop in.
Ehcache 3.x support will be based on that JSR 107 work...
On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps(a)gmail.com> wrote:
> Right, there was no plan to provide something for Ehcache3 quite yet.
> That being said, I wonder whether we ever will. I have a 107 compliant
> H2LC implementation. I also went over it with Sanne during Javaone and we
> think it can be made into something suiting for bunch of providers.
> Now, small caveat, while I still plan to work on this, as of this year
> I'm not working for Terracotta anymore... Basically, that's whenever
I'll
> find time to do so.
> cc'ed Louis, in case some he wants to provide some more formal stance...
> Alex
>
>
> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> Petar, Alex Snaps (in CC) has been doing some work to update the version
>> of Ehcache used in Hibernate ORM. Alex, any updates? As I understood it
>> though Ehcache 3.x was not part of that effort, but Alex can of course say
>> for sure.
>>
>>
>>
>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla(a)gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>> hibernate-ehcache module updated in 5.1?
>>>
>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow(a)redhat.com>:
>>>
>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>
>>>> Should we also look at changing Hibernate to not require Javassist
>>>> classes be on the deployment classpath? This might require cloning
>>>> some
>>>> Javassist runtime classes so that we don't get CNFE on
>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>> enhanced entity classes).
>>>>
>>>> [1] contains one of the CNFE's that I see with WildFly during
>>>> deployment
>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>> application classpath). I am seeing
>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>> entity class with references to Javassist classes (see disassembled
>>>> bytecode output [2]). The generated class extends
>>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler.
>>>> +
>>>> javassist.util.proxy.RuntimeSupport +
>>>> javassist.util.proxy.SerializedProxy.
>>>>
>>>> I'm sure that there are other Javassist classes that we probably
also
>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>
>>>> I have no idea exactly how to resolve this. I'm not sure if it
would
>>>> entail cloning the above javassist runtime classes into javassist. Or
>>>> separating them into a different (Javassist) library, so at least the
>>>> application doesn't include the other Javassist classes.
>>>>
>>>> Sanne had some ideas that he mentioned [3]. By only exposing the
>>>> needed
>>>> classloaders to the deployment, I think he meant the above idea of
>>>> separating Javassist into different jars. Or something like that.
>>>>
>>>> Jason Greene also liked Sanne's suggestion of not requiring
>>>> applications
>>>> to have Javassist on their classpath, as applications might also
>>>> include
>>>> their own copy of Javassist because they want to generate some bytecode
>>>> also.
>>>>
>>>> What do others think about the idea of not requiring Javassist to be on
>>>> the Hibernate application classpath? Again, I'm not sure if this
only
>>>> a
>>>> problem on WildFly. If it is, I'm not sure why. :)
>>>>
>>>> Scott
>>>>
>>>> [1]
>>>>
>>>>
https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t...
>>>>
>>>> [2]
https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>
>>>> [3]
>>>>
https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>
>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>> >
>>>> >
>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com
>>>> > <mailto:smarlow@redhat.com>> wrote:
>>>> >
>>>> > Should we upgrade to javassist latest in 5.1 still?
>>>> >
>>>> > On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>> > > Just a heads up that I tentatively set Jan 27th as the
release
>>>> > date for
>>>> > > 5.1. Please let me know if that does not work for
anyone.
>>>> Also
>>>> > please
>>>> > > keep that date in mind if there is anything you want to
get
>>>> into 5.1.
>>>> > > _______________________________________________
>>>> > > hibernate-dev mailing list
>>>> > > hibernate-dev(a)lists.jboss.org <mailto:
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>>
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>>
>>
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611