[hibernate-dev] 5.1 tentative release date

Petar Tahchiev paranoiabla at gmail.com
Thu Jan 14 10:16:25 EST 2016 

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 <sanne at 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 <paranoiabla at 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 <steve at 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 at 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 at 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 at 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 at 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 <smarlow at redhat.com
> >>>>>> > <mailto:smarlow at 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 at lists.jboss.org <mailto:
> >>>>>> hibernate-dev at lists.jboss.org>
> >>>>>>
> >>>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>> >      >
> >>>>>> >
> >>>>>> _______________________________________________
> >>>>>> hibernate-dev mailing list
> >>>>>> hibernate-dev at 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 at 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

More information about the hibernate-dev mailing list