Hmmm, I'm no fan of establishing use cases where internal classes are publicly used.

IMO, whenever if we offer public functionality on top of what BV provides, it should be through interfaces of the HV API. By encouraging the use if internal classes, IMO we establish some sort of pseudo-API which users also rely on and thus can't easily be changed. We still can change the HV API if required e.g. through deprecations, as currently the case with e.g. `MethodValidator`. But for the internal parts we should be free to change whatever we want.

Also, when considering the OSGi scenario, when dedicating internal classes for external usage, we'd have to export packages from `org.hibernate.validator.internal` which seems not like a good idea to me.

For the GlassFish use case, what do they need, just a method `getRootBeanType()`? I can create that if required.