[wildfly-dev] private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...
Scott Marlow
smarlow at redhat.com
Thu Feb 11 20:13:01 EST 2016
>>
>> 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
More information about the wildfly-dev
mailing list