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

[Sanne Grinovero]

On 27 October 2016 at 13:38, Scott Marlow <smarlow at redhat.com> wrote:
> Only a WildFly deployment unit processor (DUP) can add dependencies to
> an application deployment.  Jipijapa is not a DUP.

Ah, thanks Scott that helps to understand this all.
Still, I agree with Gunnar that any additional dependencies belong in
the static module definition of the JPA provider implementation.

Could you remove that javassist injection please?

While at it, are other dependencies being injected? Would be nice to
remove as much as possible, and leave it up to the specific
implementations to choose its dependencies.

Thanks,
Sanne

>
> On Thu, Oct 27, 2016 at 6:12 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Ok well that's also odd isn't it?
>>
>>
>> On 27 Oct 2016 10:38, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>>
>>> No, JPADependencyProcessor - which is adding the dependency - is part of
>>> "wildfly-jpa", not "jipijapa-hibernate".
>>>
>>>
>>> 2016-10-27 11:23 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>>
>>>> We could fix 1) as well by incorporating the sources for
>>>> jipijapa-hibernate52 in ORM.
>>>>
>>>> I think it belongs within Hibernate, as it won't be the last time that a
>>>> new ORM version requires some adaptation of bootstrap.
>>>>
>>>>
>>>> On 27 Oct 2016 09:51, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>>>>
>>>>> 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 :)
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>