12:40 a.m.
On 02/11/2016 05:40 PM, Stuart Douglas wrote:
On Fri, 12 Feb 2016 at 07:41 Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@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.
Thanks for the encouragement to go down this path. :)
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)?
Good question, I'm not really sure.
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>
> <mailto: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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>