Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev