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

[Gunnar Morling]

Hi,

2016-10-27 4:27 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

>
> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module
> (the WF module) export Javassist.  Not the application.
>

Right, Hibernate ORM's module should be the one exposing it, not the
application nor JipiJapa.

This allows the ORM module to expose the right version of Javassist (or
none at all eventually) without requiring JipiJapa to have the knowledge
about this. As things stand, Javassist can be considered as part of ORM's
API, hence it's module.xml should be the one making it available to the
user.

Of course eventually we don't want to expose Javassist at all, but as long
as we do, the ORM module should be in charge of doing so.

> >
>
> I agree, that is what our WF pull request did, which I think is an
> incremental improvement but that wasn't approved for the reason I gave.
>

I don't quite get the reasoning here. We all agree that Javassist shouldn't
be exposed at all (and there is good progress being made towards this by
using ByteBuddy).

But as long as we do, leaving this responsibility to the ORM module is the
right thing to do IMO. E.g. what if a JPA provider doesn't need Javassist
at all? Still JipiJapa would currently add it to the deployment.

I've done the following changes locally:

1) Altered JPADependencyProcessor to not add the Javassist dependency to
the deployment
2) Altered module.xml of jipijapa-hibernate5 to not depend on Javassist
3) Added a new module for the latest Javassist
4) Altered module.xml of ORM itself to depend on that new module *and*
re-export it

With all this in place, the tests in Hibernate Search pass successfully.

Scott, do you think we can try another PR with that? Again, it doesn't
change things in terms of exposure of Javassist to the application (it is
exposed, just as it was before). But it puts the responsibility for doing
so to ORM's module, allowing us (via the ORM module ZIP we provide) to
expose a newer Javassist version as needed.

Note that 2 - 4 can be done via the ORM module ZIP. But 1) is a change that
needs to be done on the WF side, at least I don't see how this could be
overridden?

I.e. the module ZIP is rather pointless atm. and we don't have a good way
to put the latest ORM into WF user's hands. Would be nice to change this.

>> Is the ORM testsuite building the WildFly app server from source?
> >
> >
> > Good god no :)
> >
> >
> >>
> >> Other option would be to use ByteBuddy to generate proxies instead of
> >> Javassist to eliminate the application dependency on the Javassist
> >> runtime classes.
> >
> >
> >
> > Rafael Winterhalter is actually pretty far along on defining support for
> Byte Buddy in Hibernate[1].  So that might soon be an option.
> >
> > [1] https://hibernate.atlassian.net/browse/HHH-11152
> >
> +100 :)
>