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).

If we use a private packaged copy of the jars, in order to use a
different version of Javassist, users would have to get a new version of
Hibernate that is built with that different Javassist (as you point out).

I would like to create a HHH jira for this issue that doesn't require a
specific implementation technique, so we can track this issue.

Scott

[1] http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html

>
> The inability to change javassist versions could be a major pain for
> Hibernate later on, as it may mean that older hibernate versions fail to
> work with newer JDK's if changes are made to the class file format.
>
> Stuart
>
> On Fri, 12 Feb 2016 at 03:03 Scott Marlow <smarlow@redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
>     As previously discussed, Hibernate applications need access to the
>     Javassist runtime classes (see example [1] enhanced application entity
>     if you didn't know this :).  A proposal was discussed on the
>     hibernate-dev mailing list that I think is the best short term solution.
>        I wanted to raise this issue here also, as I would like to later
>     create a pull request to bring in a new Hibernate ORM that includes this
>     change.  So, getting early feedback before we create JIRAs for the work,
>     is important.
>
>     The proposal is to private package (or shade), the Javassist classes, so
>     that Hibernate ORM has its own copy of the Javassist classes.  On
>     WildFly, we still would include Javassist for the other components that
>     use it and for Hibernate applications that have "build-time enhanced
>     entity classes" by an earlier Hibernate release.
>
>     One downside of this change is that Hibernate applications cannot easily
>     switch to a different version of the Javassist classes.
>
>     Another downside is that applications that depend on an older Hibernate
>     ORM version that includes "build-time enhanced entity classes", will
>     need to be cracked open, to add dependencies on the Javassist module
>     (since we will stop automatically adding Javassist to JPA application
>     deployments).
>
>     The advantage of this change, is that Hibernate applications can include
>     their own version of Javassist.
>
>     This will also have an impact on Hibernate build-time enhancing of
>     entity classes (e.g. enhanced bytecode will no longer depend on the
>     public Javassist classes).
>
>     Scott
>
>     [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>