Spring initialization is used for more than just controllers, and the same simplifications we made for controllers can be made for our form validators, too. And, now that #1044 is merged, we are already telling Spring to scan these class files; all we need to do is add the @Component annotation to let Spring find them and configure them.
This is the last of the Spring annotation experiments I have; I looked briefly into similarly streamlining the JNDI components, but those are a bridge out of Spring and into Java EE, which behaves a bit differently. It might be worthwhile to reconsider that decision someday, but that's much bigger than these annotation changes, and is not worthwhile at the moment.
I tested this by:
self registering with an already-existing username
going through the forgot password flow without filling in the email address
logging in as p1 and updating my password with a mismatched confirmation password
ignoring the disabled external provider account linking form
updating an existing user as system to remove the email address
Spring initialization is used for more than just controllers, and the same simplifications we made for controllers can be made for our form validators, too. And, now that #1044 is merged, we are already telling Spring to scan these class files; all we need to do is add the
@Componentannotation to let Spring find them and configure them.This is the last of the Spring annotation experiments I have; I looked briefly into similarly streamlining the JNDI components, but those are a bridge out of Spring and into Java EE, which behaves a bit differently. It might be worthwhile to reconsider that decision someday, but that's much bigger than these annotation changes, and is not worthwhile at the moment.
I tested this by:
p1and updating my password with a mismatched confirmation passwordsystemto remove the email addressand I saw the expected error on each form.