Hi all, I don't think it's a travesty - I actually use ehcache 2.x now :) Thanks Sanne - I'll research infinispan more. One other thing - I see there's a module hibernate-infinispan here:
http://repo1.maven.org/maven2/org/hibernate/hibernate-infinispan/ and inside I see they are using the 7.2.1.Final version. Here's an idea - is it possible the hibernate team to provide a BOM with all the versions definied. Just like the Drools team and the Spring team has provided. This way if I want to upgrade the hibernate version, I would simply upgrade the Bom version and this will eventually upgrade the EHCache, Infinispan, jboss-logger, hikaricp, c3p0 or any other module to a compatible version. I think this would help a lot, not just me but also any other users out there. Thanks. 2016-01-14 16:59 GMT+02:00 Sanne Grinovero <sa...@hibernate.org>: > Hi Petar, > Infinispan can work as a separate service, but that's not the default. > It's primarily designed for embedded caching, is OSS, implements > JSR-107 and also has integration helpers for Spring. > > There are several other OSS implementations too; AFAIR cache2k is a > good one and also implements JSR-107. > > That said, you can use EHcache 2 as well? It doesn't have to be > JSR-107 compliant to be used as Hibernate 2nd level cache, since the > integration with JSR-107 wan't released yet. > > Sanne > > On 14 January 2016 at 14:45, Petar Tahchiev <paranoia...@gmail.com> wrote: > > 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 > -- 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
