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.
Related
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.
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
Spring MVC offers form validation through both annotations on the forms (for example #NotNull) to do a simple check of the value of a field, and custom Validators, which help you do cross-field validations (verifying two password fields contain the same value, etc).
I am looking for the recommended way to do validations that go a bit further, however. For example verify if a username is not used already, which requires a call to the database. I assume I can simply inject my PersonRepository into the custom validator (which is an #Component) after all, but I doubt it'll be transactionally safe..or very clean.
What is the recommended way to do this, that requires the least amount of duplicated code? Or should I simply write my own validation layer, that throws some ValidationException with a list of validationmessages, which I have to map to the bindingresult?
To just clearify: Spring MVC don't offers form validation by itself. It integrates with Java Bean validation vendors (like Hibernate Validator).
You're right: If you configure LocalValidatorFactoryBean as a bean in your application context, you benefit from dependency management in your custom validators. In my opinion there is no need to implement a custom validation layer within your setup, since you already have a powerful and generic abstraction of validation which even conforms to Java standards.
If you worry about whether calling your repository in validator is transaction safe or not see http://docs.spring.io/spring-data/jpa/docs/1.8.2.RELEASE/reference/html/#transactions for details. CRUD operations are transactional by default. If you need a more sophisticated validation logic with needs a transaction context, you could either make your isValid(...) method transactional by annotating it, or you could autowire a business service with likely is transactional by itself. This perfectly integrate with the concepts of Spring.
Use the same business transaction
If you need to handle validation and business logic (check whether a user name is already used and insert a new if not) in the same transaction you could think about restricting those validations in Controller layer to the basic ones (#NotNull for example). This will ensure, that only syntactic correct requests make their way to your service layer.
In the service you will use an autowired validator and trigger the entire validation constraints manually. If you have a combination Hibernate as JPA vendor and Hibernate as Validation vendor you could even make use of the integration of both (pre persit and pre update events) which will cause the validation to occur automatically before the changes are written to the database.
However you decide, you will likely use validation groups to split the constraints into two groups 'syntactic' and 'semantic' for example. If you call the validator manually you can pass the groups you want to take into account. If you use integrated validation with Hibernate you can control the groups for the different events by specifying the following properties:
javax.persistence.validation.group.pre-persist
javax.persistence.validation.group.pre-update
If you decide for this way you will simply call your transactional business service method from your controller. Business logic and validation will participate in the same transaction this way.
It seems that JSF 2.0 does not call "class level constraints". Quoting from an SO answer
JSF 2.0 doesn't call class level validation constraints. From JSF validation: JSF 2 provides built-in integration with JSR-303 constraints. When you are using bean validation in your application, JSF automatically uses the constraints for beans that are referenced by UIInput values.
The answer furthermore suggests using SeamFaces to validate the class-level constraints anyways.
Unfortunately this is a non-option, since it introduces a somewhat massive dependency for just validating what should be validated anyways.
My question thus is:
How can I get JSF to validate class-level constraints?
Manual validation in the controller is tedious and a lot of repeated code, and thus an option I would like to avoid.
I have attempted to do this by annotating the Controller-Field to be validated with #Valid, which didn't help.
I guess it should be possible to either make the "Process Validations" phase do that for me or hook in something akin to a Filter after the "Update Model Values" phase, that would centrally run the model values through a Validation.
Until the upcoming JSF 2.3, JSF doesn't support class level validation using a.o. #Valid. This is an eternal issue, given that the very first JSF spec issue ever addresses this.
Your resort is either using a 3rd party library which has already taken care of it, or homebrewing it based on sources of the open source library in question (taking licensing into account).
Apart from SeamFaces <s:validateForm> which you already found, there's also OmniFaces <o:validateBean>. The major difference as compared to <s:validateForm> is that it doesn't use a JSF Validator, but a JSR303 ConstraintValidator (and that you've the whole entity immediately at hands without the need to declare and annotate a bunch of fields, repeating the entity's properties.
JSF 2.3 support will come in flavor of <f:validateWholeBean> which is largely based on OmniFaces <o:validateBean>.
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.