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

[Scott Marlow]

Just to be clear, Jipijapa doesn't use Javassist at all.  For JPA
deployments that are using Hibernate, the (WildFly) JPA container is
exporting the org.javassist:module to the application deployment
classloader, so that the Javassist proxy runtime classes can be
referenced by application classes that are rewritten by ORM.  If we
were to use ByteBuddy, there are no runtime proxy classes needed on
the application classpath.

There is currently no way to tell the JPA container how to export a
different Javassist module to the application deployment.  The best
solution is for the JPA container to stop exporting Javassist to the
application classpath, which means an ORM change to that effect
(either shadow the Javassist runtime proxy classes or something like
that, or try using ByteBuddy instead).

If we were to add a configuration hint for the JPA compiler to inject
a different version of javassist, I don't have confidence that the
code change would be merged, since we really want a better fix.

On Wed, Oct 26, 2016 at 5:19 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi all,
>
> there's a conflict in the Javassist versions of the WildFly modules of
> Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not
> familiar with this functionality.
>
> The module declares *both*:
>  - a dependency to the WildFly provided Javassist: <module
> name="org.javassist"/>
>  - inclusion of Hibernate's own version of Javassist: <resource-root
> path="javassist-3.20.0-GA.jar"/>
>
> Having both is causing trouble as they are both visible to the
> Hibernate classloader; however I couldn't score a quick win with the
> testsuiste by disabling either (all tests using these modules in the
> Hibernate Search testsuite fail).
>
> I suspect the problem is that JipiJapa also depends on the <module
> name="org.javassist"/>, while ORM obviously needs the more recent
> version of it.
>
> I'm not familiar with what JipiJapa's business around Javassist; could
> we keep the two clearly separated?
>
> Especially if we want to make Byte Buddy a viable alternative, I
> suspect the solution is that JipiJapa should not depend on Javassist
> directly, but invoke a generic instrumentation SPI on Hibernate; also
> with JipiJapa not able to see Javassist at all, we'd be in control of
> the one and only Javassist version visible to ORM: the one we compile
> and test with.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev