[hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

[Steve Ebersole]

On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow <smarlow at redhat.com> wrote:

> On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling <gunnar at 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