2016-10-27 0:44 GMT+02:00 Scott Marlow <smarlow(a)redhat.com>:
Just to be clear, Jipijapa doesn't use Javassist at all.
Ok. What is the reason then that it is declaring this module dependency?
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.
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.
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>
> 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
> - inclusion of Hibernate's own version of Javassist: <resource-root
> 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.
> hibernate-dev mailing list
hibernate-dev mailing list