Hi all, I am interested in helping finalising that JSR-107 H2LC. I will start looking into the code Alex has on his branch on github and take it from there. I may need to ping hibernate devs directly at one point since I do not have a very good knowledge of Hibernate currently. Regards, Louis On Thu, Jan 14, 2016 at 3:45 PM Petar Tahchiev <paranoiabla(a)gmail.com&gt; 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 <steve(a)hibernate.org&gt;: > >> 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&gt; >> 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&gt; >>> 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&gt; >>>> 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&gt;: >>>>> >>>>>> 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&gt; >>>>>> >>>>> > > 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 >