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&gt; 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&gt;: > >> 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&gt; >> > > > 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 >