[wildfly-dev] private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...
Paul Benedict
pbenedict at apache.org
Fri Feb 19 14:55:49 EST 2016
I think the answer should depend on how the Hibernate developers view
Javassist. Is Javassist seen as a pluggable part of the API? Or is it seen
as fundamentally an internal component? If it's the former, then do not
shade it; otherwise do shade it. I think the latter is very sensible as
long as that perspective is maintained in the code base.
Cheers,
Paul
On Fri, Feb 19, 2016 at 11:47 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 02/18/2016 01:17 PM, Carlo de Wolf wrote:
> > Looks to me like Hibernate is exposing bad proxies to the user.
>
> Its not bad or new, just how we always did it. Other Javassist users
> have also done the same and ended up shading Javassist classes.
>
> >
> > 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.
>
> This sounds similar to my https://github.com/wildfly/wildfly/pull/8474
> pull request that changes the Hibernate ORM static module to export the
> Javassist classes.
>
> >
> > 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/20160219/3514c6cb/attachment-0001.html
More information about the wildfly-dev
mailing list