[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