[hibernate-dev] 5.1 tentative release date

Petar Tahchiev paranoiabla at gmail.com
Thu Jan 14 09:45:30 EST 2016


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


More information about the hibernate-dev mailing list