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

[Scott Marlow]

On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> 2016-10-27 0:44 GMT+02:00 Scott Marlow <smarlow at 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?

No reason, looks like an unneeded dependency that could be removed.

>
>>
>>   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.
>
>
> 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.

Is the ORM testsuite building the WildFly app server from source?  if
yes, perhaps we could build WildFly with the newer Javassist:

   ./build.sh clean install -Dversion.org.javassist=3.20.0-GA

Other option would be to use ByteBuddy to generate proxies instead of
Javassist to eliminate the application dependency on the Javassist
runtime classes.

>
>>
>>   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
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>