Page for general findings around the investigation of the current clamp common parameter handling and validation and its possible implementation with the Spring boot framework. This investigation also addresses the possible benefits to using Spring boot validation and also the java x Bean validation API.
Current Clamp Common.
At present the common parameter handling and validation comprises of multiple classes and interfaces and perform cross field validation. The current implementation of bean validation is quite flexible as it has its own annotation interface declarations that allow for custom constraints logic as illustrated in the image below.
Although Spring validation and java x validation offer their own annotations and error handling, it is believed that the validation checking that these constraint annotations enforce does not at times provide the same level of validation that the current common provides which, may have a work around that will involve utilizing self-defined annotation and validation classes like the one shown in the figure above along with the API defined annotations.
Validation design.
- Custom defined annotations that can be used across all packages to provide common constraints.
- Custom validation rules through multiple validation classes and result storing with result implementations based on the validation results.
- Logic implemented in the validation classes is custom changeable to requirements and easy to implement for cross field validation.
- Shares similar structure and implementation to spring MVC validation of custom constraints which, could be considered a positive when formulating a work through for the policy common to be constructed using the Spring boot framework.
- Multiple validation classes allow for cross field validation providing a real common parameter library.
Spring boot validator or Java x validation.
When converting to spring boot there are options available when validating but, at times the differentials between these validation API’s can be difficult to make. The question of whether there is a difference between these API’s is not made evident as the Spring boot validation API and Java x validation API have the potential to be used at any given time .If one did not wish to perform bean validation and simply validate objects or data types at the class level then that can be achieved by standard Spring validation. An example can be seen in the image below.
Spring validation allows for annotation constraint validation and creation for data types and objects at class level. To use validation the spring boot starter validation dependency must be specified but this also gives access to the java x validation API which from what can be gathered from documentation online can be added as a dependency on its own using the java x dependency or the hibernate validator which will be further explained.
Java x validation (Bean Validation API) .
Incorporating the javax bean validation API aka JSR-380 or JSR-303 into the current common in my opinion can be achieved for the most part. Spring boot validation along with custom annotations would be required in order to ensure that the correct level of constraint has been achieved, if replicating current validation is necessary. Specific constraints and validation rules can be crafted for handling common parameters using the java validation API if required or one can do class level two step authentication as seen below.
This level of validation uses the validated annotation from the spring validation library and provides pre validation on parameters being sent to the class or application. The second level of validation is provided by the java x valid annotation. This will ensure that the object on which it is called satisfy the constraint, whether that be its data type, content, length and so on. Utilization of the libraries like this is suitable for restructuring at class level for components like participants or runtime parameter handling but do not provide a common parameter handling solution. To achieve this I believe that, depending on the needs of the project or design decisions it can be achieved using the following methods.
- Decide on what library is best suited for the job, in my opinion the spring boot starter validator or hibernate validator will work but I do not know the memory implications that come with each at initial run.
