Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency Validation for Beans via JSR303 Validation Specification [SPR-6565] #11231

Closed
spring-projects-issues opened this issue Dec 15, 2009 · 4 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Scott Battaglia opened SPR-6565 and commented

Since Spring Framework 3 includes support for the Bean Validation API it would seem a natural extension to add support for using these annotations for more than just domain validation. The @Required annotation is too coarse grained to provide much support for validating APIs. Using a combination of Assert.notNull (or other asserts) in an afterPropertiesSet is rather tedious. Being able to annotation the collaborators with annotations such as @NotNull, etc. and then having them automatically validated when the container starts would be really useful.

We've actually implemented this for CAS, but I'd like to see it available in Spring if possible, as I know we would find it useful for multiple projects (and copying it to each project is probably not a good idea).

Our implementation is here:
https://www.ja-sig.org/svn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/util/ValidatorBeanPostProcessor.java

Its relatively trivial. There might be improvements that could be made to it.

Thanks
Scott


Affects: 3.0 RC3

Referenced from: commits d6f4f4c

1 votes, 0 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Isn't BeanValidationPostProcessor in org.springframework.validation.beanvalidation pretty close to that? Admittedly it's not documented yet but basically serving the same purpose.

The only difference is that we used to perform validation in postProcessAfterInitialization up to now, whereas you are doing it in postProcessBeforeInitialization. I tend to agree that before initialization is appropriate since init methods may expect proper instance variable state already... We can change that for 3.0 GA still, even if GA is imminent already. What do you think?

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Scott Battaglia commented

I'll take a quick look right now at the class you're talking about. I didn't even know it existed!

I put it in Before for exactly the reason that you're stating :-)

I'll reply back about that particular class in a few minutes as soon as I look at the source as the Javadoc doesn't tell me much.

Cheers,
Scott

@spring-projects-issues
Copy link
Collaborator Author

Scott Battaglia commented

That class looks pretty close. My vote would be to do the check before and not after but I don't think it makes a huge difference either way (at least to our classes).

Thanks
Scott

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

BeanValidationPostProcessor runs in the before-initialization phase by default now, i.e. before init methods. I've added an "afterInitialization" flag to switch over to the after-initialization phase in order to validate constraints after init methods completed their job.

And I finally added some javadoc :-)

This will be available in snapshot build 509 in about three hours. Feel free to give it an early try!

Juergen

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0 GA milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants