On 14 January 2016 at 15:16, Petar Tahchiev <paranoiabla(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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-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>
> >>>>>>
> >>>>> > >
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
> > _______________________________________________
> > 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