Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow <smarlow(a)redhat.com> wrote:
On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling
<gunnar(a)hibernate.org>
wrote:
> Couldn't this be achieved by having the ORM module re-export the
Javassist
> module it depends on (in the module.xml of ORM, that is)?
>
> <module name="org.javassist" export="true"/>
>
> That way JipiJapa would make no assumption about Javassist at all, it'd
be
> left to the ORM module as added by JipiJapa to the deployment.
I agree.
We created a pull request (Pull request link is
https://github.com/wildfly/wildfly/pull/8474) for that previously but
it didn't get merged because ORM shouldn't require the application
classpath to contain Javassist classes, as that could conflict with
the application also wanting to include a different version of
Javassist for the application to use.
Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module
(the WF module) export Javassist. Not the application.
Is the ORM testsuite building the WildFly app server from source?
Good god no :)
Other option would be to use ByteBuddy to generate proxies instead
of
Javassist to eliminate the application dependency on the Javassist
runtime classes.
Rafael Winterhalter is actually pretty far along on defining support for
Byte Buddy in Hibernate[1]. So that might soon be an option.
[1] https://hibernate.atlassian.net/browse/HHH-11152