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