<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 12 Feb 2016 at 07:41 Scott Marlow <<a href="mailto:smarlow@redhat.com">smarlow@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 02/11/2016 03:02 PM, Stuart Douglas wrote:<br>
> Have you considered a 3rd alternative, which is to use a custom<br>
> ProxyFactory instead of javassists built in one?<br>
><br>
> AFAIK the main issue is that javassist proxies require access to the<br>
> 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You could<br>
> create a similar org.hibernate interface, and a proxy factory that uses<br>
> this method handler instead.<br>
><br>
> Basically you just copy the code from javassist.util.proxy into<br>
> hibernate. This is a relatively small amount of code, so it should not<br>
> really add any maintenance burden.<br>
<br>
We talked about this as well via [1]. I understand the concept but have<br>
not tried doing this. I like this approach as well, if it works. One<br>
of the cons with cloning that Steve Ebersole pointed out (see response<br>
on Feb-03-2016 9:01am), is that that users lose the ability to drop a<br>
different version of Javassist in (since we maintain our own cloned copy<br>
of the Javassist proxy/runtime code).<br></blockquote><div><br></div><div>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.<br><br></div><div>If they do go down the shade route will this shaded hibernate+javassist be a different artifact (i.e. will they still publish a non javassist version of hibernate)?<br><br></div><div>Stuart<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we use a private packaged copy of the jars, in order to use a<br>
different version of Javassist, users would have to get a new version of<br>
Hibernate that is built with that different Javassist (as you point out).<br>
<br>
I would like to create a HHH jira for this issue that doesn't require a<br>
specific implementation technique, so we can track this issue.<br>
<br>
Scott<br>
<br>
[1] <a href="http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html</a><br>
<br>
><br>
> The inability to change javassist versions could be a major pain for<br>
> Hibernate later on, as it may mean that older hibernate versions fail to<br>
> work with newer JDK's if changes are made to the class file format.<br>
><br>
> Stuart<br>
><br>
> On Fri, 12 Feb 2016 at 03:03 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>
> As previously discussed, Hibernate applications need access to the<br>
> Javassist runtime classes (see example [1] enhanced application entity<br>
> if you didn't know this :). A proposal was discussed on the<br>
> hibernate-dev mailing list that I think is the best short term solution.<br>
> I wanted to raise this issue here also, as I would like to later<br>
> create a pull request to bring in a new Hibernate ORM that includes this<br>
> change. So, getting early feedback before we create JIRAs for the work,<br>
> is important.<br>
><br>
> The proposal is to private package (or shade), the Javassist classes, so<br>
> that Hibernate ORM has its own copy of the Javassist classes. On<br>
> WildFly, we still would include Javassist for the other components that<br>
> use it and for Hibernate applications that have "build-time enhanced<br>
> entity classes" by an earlier Hibernate release.<br>
><br>
> One downside of this change is that Hibernate applications cannot easily<br>
> switch to a different version of the Javassist classes.<br>
><br>
> Another downside is that applications that depend on an older Hibernate<br>
> ORM version that includes "build-time enhanced entity classes", will<br>
> need to be cracked open, to add dependencies on the Javassist module<br>
> (since we will stop automatically adding Javassist to JPA application<br>
> deployments).<br>
><br>
> The advantage of this change, is that Hibernate applications can include<br>
> their own version of Javassist.<br>
><br>
> This will also have an impact on Hibernate build-time enhancing of<br>
> entity classes (e.g. enhanced bytecode will no longer depend on the<br>
> public Javassist classes).<br>
><br>
> Scott<br>
><br>
> [1] <a href="https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e" rel="noreferrer" target="_blank">https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e</a><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>
> <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>
</blockquote></div></div>