Hi Steve and al. Any chance we could make progress on HHH-7610 <https://hibernate.atlassian.net/browse/HHH-7610> and https://github.com/hibernate/hibernate-orm/pull/1080 for 5.1?
I'll revisit the PR tomorrow to fix the conflicts. -- Guillaume On Tue, Jan 12, 2016 at 5:08 PM, Scott Marlow <smar...@redhat.com> wrote: > > > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
