JSR 303 vs Spring validation - spring

I am new to Spring validation. Recently I have been exploring different approaches of validation utilities available in Spring. I found there are basically two approaches: 1. with JSR-303 and 2. by implementing Validator interface in Spring.
What I understood, with first approach one can achieve model level validation whereas the latter is more appropriate to validate String, Integer types of inputs. Is there something more, that I am missing here?

Here is an open source alternative to JSR-303.
This solution can perform all validation of the request message, but no hassle coding is required.
https://github.com/ckpoint/CheckPoint
With Check-Point, all validation is possible without further code, just by changing the annotation of the Controller method.
After that, all validation settings can be easily made in Admin Page.
I think this video can help your understand. https://youtu.be/I1aEIztXlhE
Check-Point Admin-Page Setting Screen

Related

Is is recommended to use JSON Schema Validation in the place of Bean Validation JSR303 for Spring Boot Rest APIs?

Can we use JSON Schema Validation in the place of Java Bean Validation JSR303 for Spring Boot Rest APIs for Enterprise Applications? Which one is more efficient to validate request Payload to Spring Boot Rest APIs?
(i.e. performance wise, cross-validation wise and RegEx pattern based validation)
It is a good question and there are no definitive answers for it as, perhaps, it is dependent on the application domain and remains subjective to that. At the base level (which usually covers 90%) of all use cases of validating user input to the REST service, both have the equivalent facility to validate data adequately. Both support constraints which can be used to achieve the same result.
However, on one front Bean Validation stands out is its ability to define custom validators, which can be used to validate very specific domain/application dependent constraints. For example, if there is case where a class which has 3 attributes (say, A,B and C) and a constraint is required that is either A occurs or B & C occurs but not both, then it is not really possible to put a constraint in JSON schema directly, it has to be handled through design of the schema (similarly in XML, actually it is more complicated with XML).
On the other hand in Bean Validation a custom validator can be written to handle this situation quite easily.
However, these kind of cases are few and far between.
Another point to consider is the integration of the Bean Validation in the underlying framework e.g. Spring, Jersey, RESTEasy etc., JSON schema validation is not yet integrated in the frameworks.
Therefore, given the support for the tech, it is perhaps better to stick with Bean Validation 2.0 and leverage the underlying frameworks capability to validation (this is, however, purely my view).
From an application development prospect, Java bean validator is sufficient for the business needs. From a system integration point, JSON schema externalizes the business rules and provides a platform independent interface control. So if your system involves many subsystems, JSON schema gives a better way to verify message payload.
I prefer OpenAPI Specification, which can be regarded roughly as a JSON Schema dialect, to bean validation 2.0 (JSR380).
OpenAPI is the de-facto (correct me) standard to describe RESTful API today. There are tools for validation accroding to OpenAPI spec is available, an incomplete collection can be found at here. And of course it works well with Java/Spring.
OpenAPI validates JSON string rather than a POJO, thus it can handle the following case naturally while bean validation in Java cannot: say i want to validate the object in the request body of a PATCH request, and the object must have a property named A, while the value of A is can be null;
And there are more than validation you can do with an OpenAPI spec in your hand. Because an OpenAPI schema does not only define what the data model of RESTful API looks like, it also describes other aspects (endponts, parameters and status code etc.) of the API in the same file. Out there are a bunch of code generators to auto-generate server-side or client-side code to serve requests or retrive response in whatever language.

Spring client validation on a non DB field

I have a spring flow project. On the form I want to add a check box, like "I confirm that I have provided correct details" and want to stop the flow if this check box is not checked. I don't want to add this as a DB field (validation through that is pretty simple). I cant find a way to validate the check box at client side. Any examples/options are appreciated.
jsr-303 or jsr-349 are the standards for bean validation, and is the reference yoou're looking for, from a high point of view. Youcan start reading from Wikipedia: https://en.wikipedia.org/wiki/Bean_Validation
When it comes to implement this in Spring, you have to annotate the parameter passed to the MVC handler method as #Valid and implement a Validator. The best example you could look at, initially, is the Spring official documentation:http://docs.spring.io/spring/docs/current/spring-framework-reference/html/validation.html

How can I replace Hibernate Validator with something else?

I'm not the fan of Hibernate Validator. I would like to use something else (like oval) or implement my custom validation logic. What's the best way to replace Hibernate Validator with my custom validation logic?
As Hibernate Validator (>= 4.x) is one implementation of the Bean Validation specification (javax.validation.* API) you can use other compliant implementations easily (of course depending on to which degree you're using HV specific APIs and functionality such as the provided custom constraints).
Bean Validation provides the concept of custom constraints to implement custom validation logic.
That said (I'm one of the HV committers), what is it that makes you wish to use another implementation? If you found any bugs or have feature requests, you can open a ticket in our issue tracker. If you have an idea for improvement you'd like to discuss, you can either post to our forum or the mailing list. Any feedback matters, so be sure to speak up.

Adding "Logic" and throwing error in Spring Roo Fields

I have a project created with Spring roo and I have a number field in one of my entities. I need to add some logic that this field can only take numbers that are powers of two and if it isn't then an error should be thrown to the user when trying to submit i.e. "Invalid input: not a power of two". I know what formula to use I'm just having trouble executing it on a spring/roo project. i.e. Where/what file does this piece of code go into? How do I make sure an error is thrown so the user sees it.
I asked around and got a couple answers, namely this
1) client side way: In the entity create.jspx using javascript. 2)
server side way. In entity controller loading the message error in the
returning model object.
But I don't really understand how to do this.
Thanks.
You can use a custom validator for Spring with Spring Roo.
Take a look at the change password validator in the following article by Sujit Pal.
http://sujitpal.blogspot.com/2010/07/ktm-customizing-roo-security.html
All the best with Roo.

Validation App Block validating NetTiers entities

Here is my question: does anyone know how to set up custom validation for NetTiers entities?
I have a NetTiers web solution that was generated with the EntLib 4.1 validation app block. The actual entities' properties are decorated with the validation attributes to ensure that the dataase integrity is maintained. What I need to do is add custom validation to the entities.
I know how to write the custom validators. I'm just not sure how to wire them up to the each entities so that I can perform custom validation. What I am looking for is an overview on how to do this.
Any help would be appreciated.
Thanks,
Joe
Are you using the latest release of .netTiers? Support for data annotations was added in this patch and committed to core.
I would take a look at the following documentation. I'm thinking that this is something that you would need to wire up programmatically. Well make sure that this scenario works in v3.

Resources