[wildfly-dev] private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...
Steve Ebersole
steve at hibernate.org
Thu Feb 18 13:26:48 EST 2016
Guys chill about the shading :) That was only ever mentioned as a
preference over the original suggestion to copy large number of classes
from Javassist into Hibernate source. I simply said that if we are copying
these classes from Javassist that shading would be a better option for
achieving that. Neither of those are really good options, but forced to
choose between the 2 I'd chose shading.
I think we all agree that (if possible) Hibernate not using using Javassist
at all beyond actually generating the proxy and/or enhancing would be the
best option. So if this is possible lets go that route.
On Thu, Feb 18, 2016 at 12:17 PM Carlo de Wolf <cdewolf at redhat.com> wrote:
> Looks to me like Hibernate is exposing bad proxies to the user.
>
> Would it not be possible to use a custom class loader at the point where
> the proxy is defined?
> Than you could use one that takes the version of javassist that
> Hibernate requires and delegates everything else to the deployment class
> loader.
>
> I don't like to see any sort of shading as this means the full
> maintenance burden of those classes are carried over into Hibernate.
>
> Carlo
>
> On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
> > It seems we're discussing this issue in multiple places,
> > so to let you all know I'll repeat it hare:
> > I think shading is a really really bad idea :)
> >
> > Could we try to have the enhanced entities to not need Javassist in in
> > their *direct* classloader; we can still have a normal Javassist as a
> > module dependency of Hibernate?
> > That would require to just make sure the generated bytecode doesn't
> > directly refer to Javassist types but uses an indirection controlled
> > by Hibernate code.. which in turn can use Javassist or even
> > alternatives in future, if we'd like to experiment.
> >
> > I'm not familiar enough with Javassist to know if that's an option
> > as-is but we can either improve Javassist to allow such a thing or use
> > some alternatives, like Gunnar and Hardy also suggested on the
> > hibernate-dev mailing list.
> >
> > To summarize, I agree with Stuart and would hope that Scott's branch
> > can be improved by minimizing the amount of Javassist code which
> > actually needs to be copied by using some simple delegation to
> > Hibernte types, which in turn can use a private, non-shaded Javassist
> > taking advantage of the isolation provided by JBoss Modules.
> >
> > --Sanne
> >
> >
> >
> > On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
> >> What if Javassist packaged these same (proxy/runtime) classes in a
> >> separate javassist-runtime jar and we shaded only the proxy/runtime
> >> classes? That way we only repackage the same classes that we included
> >> for this hack test (e.g.
> >> org.hibernate.bytecode.internal.javassist.proxy.*).
> >>
> >> Early testing results of the hack test look good
> >> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
> >>
> >> Scott
> >>
> >> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
> >>> It depends if you are going to shade all the javassist classes or just
> >>> the "javassist.util.proxy" package (not sure if this is actually
> >>> possible with the shade plugin).
> >>>
> >>> The main advantage is that you can upgrade javassist to get fixes to
> >>> issues that affect bytecode generation. So if JDK9 comes out with new
> >>> bytecodes that the current version of Javassist does not understand
> then
> >>> upgrading javassist will allow the older version of hibernate to work
> >>> with classes compiled against the newer JDK version. If all of
> javassist
> >>> is shaded into hibernate then that version of hibernate will never work
> >>> with the newer bytecodes.
> >>>
> >>> I think this is less of an issue if you are still publishing the
> >>> non-Javassist shaded hibernate as well as a shaded version, but if the
> >>> only published artifact has javassist shaded in then it may limit
> >>> forward compatibility.
> >>>
> >>> Stuart
> >>>
> >>>
> >>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
> >>> <mailto:steve at hibernate.org>> wrote:
> >>>
> >>> Ugh. That is an awful lot of classes copied over. What exactly
> was
> >>> the benefit of this over shading again? I mean both case lose the
> >>> ability to simply drop in fixes from upstream Javassist. So what
> >>> does this "clone" approach gain versus shadowing?
> >>>
> >>>
> >>>
> >>> On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
> >>> <mailto: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.
> >>> >
> >>> > Thanks for the encouragement to go down this path. :)
> >>> >
> >>>
> >>> Started a hack attempt at the clone via
> >>>
> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
> >>> Seems
> >>> to pass the Hibernate ORM unit tests.
> >>>
> >>> Scott
> >>>
> >>> _______________________________________________
> >>> 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
> >>>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
>
> _______________________________________________
> 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/20160218/a1305808/attachment-0001.html
More information about the wildfly-dev
mailing list