[hibernate-dev] 5.1 tentative release date
Sanne Grinovero
sanne at hibernate.org
Thu Jan 14 15:35:23 EST 2016
On 14 January 2016 at 15:16, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> 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.
I don't think a BOM would help you in this case.
you just need to depend on :
org.hibernate:hibernate-core:5.0.7.Final
org.hibernate:hibernate-infinispan:5.0.7.Final
and use the dependencies that these provide.
The only thing you have to be careful about is this '5.0.7.Final' is
the same for all your libraries from Hibernate ORM, but that's easily
done with a property.
Thanks,
Sanne
>
> 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