Re: [hibernate-dev] 5.1 tentative release date
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