[hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
gunnar at hibernate.org
Wed Oct 26 17:39:15 EDT 2016
Would be interesting to know why JipiJapa is depending on it. In a quick
search I couldn't spot any actual usages.
JPADependencyProcessor adds a dependency to "org.javassist", maybe that
could be avoided by having the ORM module re-export the version of JipiJipa
it is using? For that he module ZIP would have to contain a module for the
new JipiJapa version and ORM's module.xml would depend on it and re-export
2016-10-26 23:19 GMT+02:00 Sanne Grinovero <sanne at 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 at lists.jboss.org
More information about the hibernate-dev