<div dir="ltr">Guys chill about the shading :) That was only ever mentioned as a preference over the original suggestion to copy large number of classes from Javassist into Hibernate source. I simply said that if we are copying these classes from Javassist that shading would be a better option for achieving that. Neither of those are really good options, but forced to choose between the 2 I'd chose shading.<div><br></div><div>I think we all agree that (if possible) Hibernate not using using Javassist at all beyond actually generating the proxy and/or enhancing would be the best option. So if this is possible lets go that route.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 18, 2016 at 12:17 PM Carlo de Wolf <<a href="mailto:cdewolf@redhat.com">cdewolf@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looks to me like Hibernate is exposing bad proxies to the user.<br>
<br>
Would it not be possible to use a custom class loader at the point where<br>
the proxy is defined?<br>
Than you could use one that takes the version of javassist that<br>
Hibernate requires and delegates everything else to the deployment class<br>
loader.<br>
<br>
I don't like to see any sort of shading as this means the full<br>
maintenance burden of those classes are carried over into Hibernate.<br>
<br>
Carlo<br>
<br>
On 02/18/2016 12:11 PM, Sanne Grinovero wrote:<br>
> It seems we're discussing this issue in multiple places,<br>
> so to let you all know I'll repeat it hare:<br>
> I think shading is a really really bad idea :)<br>
><br>
> Could we try to have the enhanced entities to not need Javassist in in<br>
> their *direct* classloader; we can still have a normal Javassist as a<br>
> module dependency of Hibernate?<br>
> That would require to just make sure the generated bytecode doesn't<br>
> directly refer to Javassist types but uses an indirection controlled<br>
> by Hibernate code.. which in turn can use Javassist or even<br>
> alternatives in future, if we'd like to experiment.<br>
><br>
> I'm not familiar enough with Javassist to know if that's an option<br>
> as-is but we can either improve Javassist to allow such a thing or use<br>
> some alternatives, like Gunnar and Hardy also suggested on the<br>
> hibernate-dev mailing list.<br>
><br>
> To summarize, I agree with Stuart and would hope that Scott's branch<br>
> can be improved by minimizing the amount of Javassist code which<br>
> actually needs to be copied by using some simple delegation to<br>
> Hibernte types, which in turn can use a private, non-shaded Javassist<br>
> taking advantage of the isolation provided by JBoss Modules.<br>
><br>
> --Sanne<br>
><br>
><br>
><br>
> On 12 February 2016 at 03:19, Scott Marlow <<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>> wrote:<br>
>> What if Javassist packaged these same (proxy/runtime) classes in a<br>
>> separate javassist-runtime jar and we shaded only the proxy/runtime<br>
>> classes? That way we only repackage the same classes that we included<br>
>> for this hack test (e.g.<br>
>> org.hibernate.bytecode.internal.javassist.proxy.*).<br>
>><br>
>> Early testing results of the hack test look good<br>
>> (<a href="https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7" rel="noreferrer" target="_blank">https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7</a>).<br>
>><br>
>> Scott<br>
>><br>
>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:<br>
>>> It depends if you are going to shade all the javassist classes or just<br>
>>> the "javassist.util.proxy" package (not sure if this is actually<br>
>>> possible with the shade plugin).<br>
>>><br>
>>> The main advantage is that you can upgrade javassist to get fixes to<br>
>>> issues that affect bytecode generation. So if JDK9 comes out with new<br>
>>> bytecodes that the current version of Javassist does not understand then<br>
>>> upgrading javassist will allow the older version of hibernate to work<br>
>>> with classes compiled against the newer JDK version. If all of javassist<br>
>>> is shaded into hibernate then that version of hibernate will never work<br>
>>> with the newer bytecodes.<br>
>>><br>
>>> I think this is less of an issue if you are still publishing the<br>
>>> non-Javassist shaded hibernate as well as a shaded version, but if the<br>
>>> only published artifact has javassist shaded in then it may limit<br>
>>> forward compatibility.<br>
>>><br>
>>> Stuart<br>
>>><br>
>>><br>
>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <<a href="mailto:steve@hibernate.org" target="_blank">steve@hibernate.org</a><br>
>>> <mailto:<a href="mailto:steve@hibernate.org" target="_blank">steve@hibernate.org</a>>> wrote:<br>
>>><br>
>>> Ugh. That is an awful lot of classes copied over. What exactly was<br>
>>> the benefit of this over shading again? I mean both case lose the<br>
>>> ability to simply drop in fixes from upstream Javassist. So what<br>
>>> does this "clone" approach gain versus shadowing?<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a><br>
>>> <mailto:<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>>> wrote:<br>
>>><br>
>>> >><br>
>>> >> On 02/11/2016 03:02 PM, Stuart Douglas wrote:<br>
>>> >> > Have you considered a 3rd alternative, which is to<br>
>>> use a custom<br>
>>> >> > ProxyFactory instead of javassists built in one?<br>
>>> >> ><br>
>>> >> > AFAIK the main issue is that javassist proxies<br>
>>> require access to the<br>
>>> >> > 'javassist.util.proxy.MethodHandler|RuntimeSupport'<br>
>>> classes. You<br>
>>> >> could<br>
>>> >> > create a similar org.hibernate interface, and a<br>
>>> proxy factory<br>
>>> >> that uses<br>
>>> >> > this method handler instead.<br>
>>> >> ><br>
>>> >> > Basically you just copy the code from<br>
>>> javassist.util.proxy into<br>
>>> >> > hibernate. This is a relatively small amount of<br>
>>> code, so it<br>
>>> >> should not<br>
>>> >> > really add any maintenance burden.<br>
>>> >><br>
>>> >> We talked about this as well via [1]. I understand the<br>
>>> concept but have<br>
>>> >> not tried doing this. I like this approach as well, if<br>
>>> it works. One<br>
>>> >> of the cons with cloning that Steve Ebersole pointed<br>
>>> out (see response<br>
>>> >> on Feb-03-2016 9:01am), is that that users lose the<br>
>>> ability to drop a<br>
>>> >> different version of Javassist in (since we maintain<br>
>>> our own cloned copy<br>
>>> >> of the Javassist proxy/runtime code).<br>
>>> >><br>
>>> >><br>
>>> >> The proxy code is a relatively small part of javassist, so<br>
>>> unless a bug<br>
>>> >> is in the proxy code itself this should not be that big a deal.<br>
>>> ><br>
>>> > Thanks for the encouragement to go down this path. :)<br>
>>> ><br>
>>><br>
>>> Started a hack attempt at the clone via<br>
>>> <a href="https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy" rel="noreferrer" target="_blank">https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy</a>.<br>
>>> Seems<br>
>>> to pass the Hibernate ORM unit tests.<br>
>>><br>
>>> Scott<br>
>>><br>
>>> _______________________________________________<br>
>>> wildfly-dev mailing list<br>
>>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
>>><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
><br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div>