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 <st...@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.sn...@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 <st...@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 <paranoia...@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 <smar...@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-txt-L1 >>>>> >>>>> [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 <smar...@redhat.com >>>>> > <mailto:smar...@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@lists.jboss.org <mailto: >>>>> hibernate-dev@lists.jboss.org> >>>>> >>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > > >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
