>>
>>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>       > Have you considered a 3rd alternative, which is to use a custom
>>       > ProxyFactory instead of javassists built in one?
>>       >
>>       > AFAIK the main issue is that javassist proxies require access to the
>>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You
>>      could
>>       > create a similar org.hibernate interface, and a proxy factory
>>      that uses
>>       > this method handler instead.
>>       >
>>       > Basically you just copy the code from javassist.util.proxy into
>>       > hibernate. This is a relatively small amount of code, so it
>>      should not
>>       > really add any maintenance burden.
>>
>>      We talked about this as well via [1].  I understand the concept but have
>>      not tried doing this.  I like this approach as well, if it works.  One
>>      of the cons with cloning that Steve Ebersole pointed out (see response
>>      on Feb-03-2016 9:01am), is that that users lose the ability to drop a
>>      different version of Javassist in (since we maintain our own cloned copy
>>      of the Javassist proxy/runtime code).
>>
>>
>> The proxy code is a relatively small part of javassist, so unless a bug
>> is in the proxy code itself this should not be that big a deal.
>
> Thanks for the encouragement to go down this path.  :)
>

Started a hack attempt at the clone via
https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.  Seems
to pass the Hibernate ORM unit tests.

Scott
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev