On 01/11/2016 11:04 AM, Steve Ebersole wrote: > On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smar...@redhat.com > <mailto:smar...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
