[hibernate-dev] 5.1 tentative release date

Scott Marlow smarlow at redhat.com
Tue Jan 12 11:08:56 EST 2016



On 01/11/2016 11:04 AM, Steve Ebersole wrote:
> On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Should we also look at changing Hibernate to not require Javassist
>     classes be on the deployment classpath?
>
>
> I just don't see how that is ever going to be realistically possible.
> If you have specific suggestions, we are all ears ;)

I'm thinking that we should defer the Javassist upgrade until we figure 
out what we want to do exactly to address this problem.  I would expect 
that other modular classloading environments besides WildFly may also 
need a fix.

For a possible workaround (for proxies), if we were able to clone the 
needed Javassist runtime classes, into the application classloader and 
generate proxies that use the cloned copies, I think that could help. 
We would have to clone them into a private package name (e.g. something 
like org.hibernate.javassist.runtime.*).  We would also have to generate 
the proxies using the cloned classes.

There may be other ways to change Hibernate applications to not depend 
on the Javassist runtime classes.  For example if we change the bytecode 
that we generate, to not reference the Javassist runtime classes, that 
also would address this.


More information about the hibernate-dev mailing list