Carlo de Wolf:

https://github.com/hibernate/hibernate-validator/blob/5.2.2.Final/engine/src/main/java/org/hibernate/validator/internal/util/privilegedactions/LoadClass.java#L75 eats away the original exception

To be fair, the stack trace points to line 84 and the original cause is passed along in this case:

catch ( ClassNotFoundException e ) {
	throw log.getUnableToLoadClassException( className, e );
}

The problem might be that the exception is then caught and re-wrapped ConfigurationImpl line 138, but even there the original cause is preserved.

Whether we should keep the original cause for line 75 of LoadClass as well and whether we should try to produce a better exception in ConfigurationImpl is a different question, but hardly related to the actual test failure.

It can only be reproduced (/introduced) by explicitly putting Hibernate Validator in a broken state.

What do you mean with putting Hibernate Validator in a broken state?

It is simply (very) bad practice to eat away exceptions

True, except it actually always keeps the original exception cause. It might be a problem how the overall exception is then reported and that is partly related to JBoss Logging and what it does with exceptions passed along using @Cause.