[hibernate-dev] 5.1 tentative release date

Steve Ebersole steve at hibernate.org
Thu Jan 14 09:31:16 EST 2016


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
>>>
>>


More information about the hibernate-dev mailing list