[hibernate-dev] 5.1 tentative release date
Steve Ebersole
steve at hibernate.org
Mon Jan 11 11:00:40 EST 2016
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