Hi, I'd like to propose an alternative approach for proxy generation which would avoid version issues with Javassist.
The idea is to generate proxies which are fully "self-contained", i.e. their byte code contains no references to a library such as Javassist, but instead invocations of a either a custom method handler contract we define ourselves or something unproblematic such as java.lang.reflect.InvocationHandler. Such code generation could be done "by hand" using ASM, but there is a handy library named ByteBuddy [1] which essentially provides a nice DSL for creating types at runtime (it sits on top of ASM itself). It makes it very easy to create proxy classes which call out to an instance of InvocationHandler when the proxied methods are called. Note that it enables the usage of InvocationHandler not only for interfaces (such as the original usage in the JDK) but also for class proxies. The code generated for proxies does not contain any references to ButeBuddy's API, i.e. after creation they are usable without ByteBuddy being available (*). That way ByteBuddy should not have to be exposed to user deployments, unlike with the current Javassist solution. It'd only be a tool used *internally* within Hibernate. I've pushed a very rough draft of that approach to my fork of ORM at https://github.com/hibernate/hibernate-orm/commit/0b1739059b74aaab7d3aa91bba85b204ee367d92. It's not complete and some tests fail. I'd need to look into these in more depth, but I don't think they represent general problems. But this sketch might be good enough already to be dropped into WildFly and run some tests. Any feedback welcome. Cheers, --Gunnar [1] bytebuddy.net/ (*) I could serialize a generated proxy to disk and re-read+execute it subsequently from another application without ByteBuddy on the classpath 2016-02-16 20:07 GMT+01:00 Scott Marlow <smar...@redhat.com>: > https://hibernate.atlassian.net/browse/HHH-10536 is for tracking this. > Please revise as it makes sense. > > In the related WildFly dev discussion about $subject, Stuart asked if we > would have two separate Hibernate ORM jars (one that depends on the > shaded Javassist and one that depends on regular Javassist). That seems > like a separate concern but perhaps others will feel stronger about it. > > Also, in the WildFly discussion, I asked whether it makes a difference > to Hibernate, whether the javassist.util.proxy classes that we want to > shade, are in the javassist.jar or a new javassist-runtime.jar? If we > shade all of the classes in a javassist-runtime.jar, that might be a > better long term contract, then if we shaded the javassist.util.proxy > classes which could be renamed over time. Does it make a difference > whether we shade the javassist.util.proxy or entire javassist-runtime.jar? > > Thanks, > Scott > _______________________________________________ > 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
