Ugh. That is an awful lot of classes copied over. What exactly was the benefit of this over shading again? I mean both case lose the ability to simply drop in fixes from upstream Javassist. So what does this "clone" approach gain versus shadowing?On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow@redhat.com> wrote:>>
>> 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