4:40 p.m.
On Fri, 12 Feb 2016 at 07:41 Scott Marlow <smarlow(a)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.
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)?
Stuart
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(a)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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>