> 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.

Ok, ok - I see the wisdom in this :-) Not sure about "creating a pseudo API", but anyways.

> 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.

Now, that is convincing

> For the GlassFish use case, what do they need, just a method getRootBeanType()? I can create that if required.

That's what they need yes. I guess we can think whether we want to offer more. So yes, we should create an interface here.

The questions arises whether we should change _ValidatorImpl#unwrap_?