[hibernate-dev] 5.1 tentative release date

[Petar Tahchiev]

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