Currently, the signature for LocalValidatorFactoryBean's setProviderClass method is as follows:
public void setProviderClass(Class providerClass)
This is unsafe, as it would be easy for someone to inadvertently set the incorrect class as the argument to this method. Ultimately the argument passed to this method call is then passed to Validation#byProvider(Class), so the signature should really be this:
public <T extends Configuration<T>, U extends ValidationProvider<T>> void setProviderClass(Class<U> providerClass)
This will make it impossible for users of Spring's @Configuration to compile a configuration class that sets this value to an incorrect class.
Affects: 4.0 M1
#13613 spring-context missing optional Import-Package directive for javax.validation.spi
The text was updated successfully, but these errors were encountered:
Note: I just discovered that the fix I suggest actually used to be the case (for the most part; my suggestion is slightly more safe). In Spring 3.0 it was correct, but in Spring 3.1 it was made unsafe.
A change was made in changeset 9a61f36d3d281cdb255e2e22c95dee9bf2f58386 and then merged in changeset ee36c80ca961a5b2af233cd26a5483d57939c0af to make this unsafe. This seems like a backwards move to me. The change was "removed optional javax.validation.spi dependency (#13613)" (an OSGi thing). However, this makes no sense to me. The class javax.validation.spi.ValidationProvider is in the same artifact as javax.validation.ValidatorFactory, which LocalValidatorFactoryBean implements directly, so there's simply no advantage to removing the dependency on ValidationProvider.
So, I stand by my original suggestion and say that the change made in Spring 3.1 needs to be undone.
Since this is just about guidance for which classes to pass in, I'm inclined not to change this back. The spi subpackage isn't necessarily exposed in an OSGi environment with its whitelisting of published packages, and even if the OSGi part isn't as much of a problem anymore these days, it's hard to see why somebody would get this rather specific configuration property wrong.
I don't understand any of that (admittedly, I don't do OSGi). How does that relate to this being a compiler warning, and the fact that it USED to be safe and someone (IMO, inappropriately) changed it from safe to unsafe?