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

[Stuart Douglas]

On Fri, 12 Feb 2016 at 07:41 Scott Marlow <smarlow at 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 at redhat.com
> > <mailto: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 <mailto: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/2c814ee4/attachment.html