[wildfly-dev] private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...

[Stuart Douglas]

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.

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/90ec20e0/attachment-0001.html