On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow <smar...@redhat.com> wrote:
> On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling <gun...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
