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

[Sanne Grinovero]

Hi Scott,

no I don't think that's possible. There are many ways of bootstrapping
Hibernate, and "using code" is also a valid option, which implies end
users have the option to read configuration properties from custom
sources or even hard-code configuration.

Granted in practice they'll likely use Spring or other frameworks to
boot it, but a list of such frameworks would necessarily be
open-ended.

Not least, I wouldn't want you to automatically add Hibernate ORM
dependencies as it's very likely in most of these cases that the end
user will want to use a different version of Hibernate ORM to match
the requirements of the framework do jour, or otherwise include a
custom version.

The only "safe default" would be to inspect the bytecode of the
deployment and see if both conditions are true:
 - any class refers to Hibernate (JPA) code / annotations
 - no Hibernate version is included

On top of this not being simple to perform, it would also not be a
safe operation as Hibernate evolves so you can't really be sure if
some future version has not been included.

I'd highly prefer the simplicity of WildFly behaving without any
complex guess work: inject Hibernate when asked for it. Doing this
based on the META-INF/persistence.xml presence seems a reasonable
compromise but anything more complex is something that people will
have to understand to control it..

Thanks,
Sanne


On 28 March 2017 at 16:46, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 03/28/2017 11:30 AM, Scott Marlow wrote:
>> Hi,
>>
>> Would it be possible for a WildFly deployment unit processor to detect
>> Hibernate ORM native applications, by detecting the presence of a
>> particular configuration file that is always present?  I'm not sure if
>> this is possible, but if it is, perhaps WildFly could automatically
>> add the (supported) Hibernate orm module to the native application, if
>> the deployment is clearly marked as a Hibernate native application, as
>> well as also exporting Javassist to the deployment.
>
> A related question, is there a standard Hibernate annotation class that
> native Hibernate applications always use that we could scan for the same
> reasons, as an alternative to scanning for Hibernate configuration files?
>
>>
>> Thoughts?
>>
>> Scott
>>
>>
>>
>> On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>>>> Right, Hibernate ORM's module should be the one exposing it, not the
>>>>> application nor JipiJapa.
>>>> JipiJapa has zero to do with this, we will create a pr later today to
>>>> remove the unneeded dependencies, which has nothing to do with this
>>>> conversation.
>>> https://github.com/wildfly/wildfly/pull/9305 is for removing the
>>> unused Javassist dependency from JipiJapa.  Also removed a few other
>>> unused dependencies.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev