I have a web application wrote in Spring. There is a HTML form with one Integer field. I added a custom message for typeMismatch.java.lang.Integer and it is correctly handled but there is one issue. Spring does not distinguish between a string value and "overflowed" integer. In other words - there is no difference whether user enter this is a string or 1000000000000000000000000000. Both are handled by Spring as typeMismatch. I would like to have two separate messages for both cases.
I thought about two solutions:
replace the java.lang.Integer by java.math.BigInteger in the
form object - then the typeMismatch error will apply only to this
is a string and I will handle 1000000000000000000000000000 in a
validator
register my own property editor for Integer, but I'm not sure if I
could handle two different errors with one property editor
Do you have any better concepts for this issue?
Could you integrate the hibernate validation framework / Java EE6 bean validation into your Spring project?
You could then limit the acceptable range allowed for your integer field with an annotation such as :
#Min(1)
#Max(10000)
private Integer myInteger;
Here is an easy to follow article :
http://www.c-sharpcorner.com/UploadFile/5fd9bd/javax-annotation-and-hibernate-validator-a-pragmatic-appro/
Related
I have a dto object which keeps an IP Range using first and last fields. Simple CRUD operations are made with this class using dropwizard (jersey-jackson-hibernate validator)
public class IpRangeDto {
#JsonCreator
public static IpRangeDto fromCidr(#JsonProperty("cidr") String cidr) {
//Resolve CIDR and assign first and last fields
}
#NotNull
#IpAddress // My custom validator
private String first;
#NotNull
#IpAddress
private String last;
}
For the sake of user-friendliness I had decided to add an alternative way to create this object, which is by using CIDR. So the client could send either first and last fields in JSON or only the cidr field. So the way to do it is as above, using #JsonCreator. And it works just fine.
"ipRange":{
"first": "15.0.0.1",
"last": "15.0.0.255",
}
"ipRange":{
"cidr": "15.0.0.0/24"
}
I want to validate this CIDR value that it's the right format so I can return 422 with proper error message. If I throw exception in the constructor/factory method then jersey-jackson returns 400 directly (even if I throw ConstraintViolationException, it's encapsulated by JsonProcessingException).
I could simply ignore the exceptions, and leave the fields empty which will return 422 because of #NotNull constraints but then the error message will not be as clear as it should be.
I tried adding my #Cidr validator next to the #JsonProperty parameter but that doesn't seem to be effective. My understanding is that validation occurs after Jackson is finished with creating Dtos, so with my #JsonCreator approach there might not be any solution to this problem. So I'm open to refactoring suggestions as well.
I am not an expert on the exact integration of Bean Validation into jackson, but I think it is just doing actual property validation. This means as you already pointed out, the entities are created first and then the properties are validated.
Bean Validation (as of version 1.1) also offers so called method validation, in which case you could place your Cidr constraint onto the string parameter of the method, but as said, I don't think that there is an integration in jackson for that.
And one more thing ;-) - static methods and properties are generally excluded from validation in Bean Validation (see also http://beanvalidation.org/1.1/spec/#d0e2815).
Regarding a workaround, one thing comes to mind (even though it feels a bit complicated). Write a custom class level IpRange constraint. In a class constraint you would get passed a IpRangeDto instance and it is up to you to validate the whole object and select the right error message for any violations. Provided you would add a cidr property to the dto which gets set when fromCidr is called, you would have then all information you need for the validation and selection of a proper error message.
We all know, that Spring MVC integrate well with Hibernate Validator and JSR-303 in general. But Hibernate Validator, as someone said, is something for Bean Validation only, which means that more complex validations should be pushed to the data layer. Examples of such validations: business key uniqueness, intra-records dependence (which is usually something pointing at DB design problems, but we all live in an imperfect world). Even simple validations like string field length may be driven by some DB value, which makes Hibernate Validator unusable.
So my question is, is there something Spring or Hibernate or JSR offers to perform such complex validations? Is there some established pattern or technology piece to perform such a validation in a standard Controller-Service-Repository setup based on Spring and Hibernate?
UPDATE: Let me be more specific. For example, there's a form which sends an AJAX save request to the controller's save method. If some validation error occurs -- either simple or "complex" -- we should get back to the browser with some json indicating a problematic field and associated error. For simple errors I can extract the field (if any) and error message from BindingResult. What infrastructure (maybe specific, not ad-hoc exceptions?) would you propose for "complex" errors? Using exception handler doesn't seem like a good idea to me, because separating single process of validation between save method and #ExceptionHandler makes things intricate. Currently I use some ad-hoc exception (like, ValidationException):
public #ResponseBody Result save(#Valid Entity entity, BindingResult errors) {
Result r = new Result();
if (errors.hasErrors()) {
r.setStatus(Result.VALIDATION_ERROR);
// ...
} else {
try {
dao.save(entity);
r.setStatus(Result.SUCCESS);
} except (ValidationException e) {
r.setStatus(Result.VALIDATION_ERROR);
r.setText(e.getMessage());
}
}
return r;
}
Can you offer some more optimal approach?
Yes, there is the good old established Java pattern of Exception throwing.
Spring MVC integrates it pretty well (for code examples, you can directly skip to the second part of my answer).
What you call "complex validations" are in fact exceptions : business key unicity error, low layer or DB errors, etc.
Reminder : what is validation in Spring MVC ?
Validation should happen on the presentation layer. It is basically about validating submitted form fields.
We could classify them into two kinds :
1) Light validation (with JSR-303/Hibernate validation) : checking that a submitted field has a given #Size/#Length, that it is #NotNull or #NotEmpty/#NotBlank, checking that it has an #Email format, etc.
2) Heavy validation, or complex validation are more about particular cases of field validations, such as cross-field validation :
Example 1 : The form has fieldA, fieldB and fieldC. Individually, each field can be empty, but at least one of them must not be empty.
Example 2 : if userAge field has a value under 18, responsibleUser field must not be null and responsibleUser's age must be over 21.
These validations can be implemented with Spring Validator implementations, or custom annotations/constraints.
Now I understand that with all these validation facilites, plus the fact that Spring is not intrusive at all and lets you do anything you want (for better or for worse), one can be tempted to use the "validation hammer" for anything vaguely related to error handling.
And it would work : with validation only, you check every possible problem in your validators/annotations (and hardly throw any exception in lower layers). It is bad, because you pray that you thought about all the cases. You don't leverage Java exceptions that would allow you to simplify your logic and reduce the chance of making a mistake by forgetting to check that something had an error.
So in the Spring MVC world, one should not mistake validation (that is to say, UI validation) for lower layer exceptions, such has Service exceptions or DB exceptions (key unicity, etc.).
How to handle exceptions in Spring MVC in a handy way ?
Some people think "Oh god, so in my controller I would have to check all possible checked exceptions one by one, and think about a message error for each of them ? NO WAY !". I am one of those people. :-)
For most of the cases, just use some generic checked exception class that all your exceptions would extend. Then simply handle it in your Spring MVC controller with #ExceptionHandler and a generic error message.
Code example :
public class MyAppTechnicalException extends Exception { ... }
and
#Controller
public class MyController {
...
#RequestMapping(...)
public void createMyObject(...) throws MyAppTechnicalException {
...
someServiceThanCanThrowMyAppTechnicalException.create(...);
...
}
...
#ExceptionHandler(MyAppTechnicalException.class)
public String handleMyAppTechnicalException(MyAppTechnicalException e, Model model) {
// Compute your generic error message/code with e.
// Or just use a generic error/code, in which case you can remove e from the parameters
String genericErrorMessage = "Some technical exception has occured blah blah blah" ;
// There are many other ways to pass an error to the view, but you get the idea
model.addAttribute("myErrors", genericErrorMessage);
return "myView";
}
}
Simple, quick, easy and clean !
For those times when you need to display error messages for some specific exceptions, or when you cannot have a generic top-level exception because of a poorly designed legacy system you cannot modify, just add other #ExceptionHandlers.
Another trick : for less cluttered code, you can process multiple exceptions with
#ExceptionHandler({MyException1.class, MyException2.class, ...})
public String yourMethod(Exception e, Model model) {
...
}
Bottom line : when to use validation ? when to use exceptions ?
Errors from the UI = validation = validation facilities (JSR-303 annotations, custom annotations, Spring validator)
Errors from lower layers = exceptions
When I say "Errors from the UI", I mean "the user entered something wrong in his form".
References :
Passing errors back to the view from the service layer
Very informative blog post about bean validation
I am getting an error message in my JSF pages... Conversion error setting value 'delovenier' for 'null converter', where delovenier is the name of the chosen project.
I'm not sure why this is happening. Could someone please assist me.
This is my JSF code...
<h:selectOneListbox id="proj" value ="#{studentEController.gekozenProject}">
<f:selectItems value="#{studentEController.projecten}"></f:selectItems>
</h:selectOneListbox>
And this is my code in the managedBean StudentEController.
private List<ProjectE> projecten;
private ProjectE gekozenProject;
As you can see, they have the same type of ProjectE.
Data transferred between the server and the client will be in string form.
The Expression Language can coerce a set of standard types (ints, etc.), but for complex types you are going to have to add a Converter to your component. Your converter will serialize ProjectE types to strings at render time and deserialize them to new ProjectE instances when forms are submitted.
You can create converters for specific types or add them explicitly to components.
See Creating a Custom Converter in the Java EE 6 tutorial and the <f:converter> tag.
I have a spring bound form (modelAttribute) which displays the user information.
The user's telephone number is displayed in a formatted manner but a requirement is that the number is saved to the database without any signs.
So in the getter method of my user object I format the telephone number according to the rules and in the setter I put the code to remove the special signs.
The formatting part works fine, but setter part where I remove the signs does not seem to occur.
In my constructor I also did:
setTelephoneNumber(TelephoneNumber);
So the constructor also invokes the setter.
I'm using Spring 3.0.4 and Spring-mvc.
Any input on this issue and how to resolve it would be appreciated.
edit:
controller section:
model.addAttribute("user", user);
JSP (shortened it a bit but this is the gist. submitUrl is due to a portal environment:
<form:form action="${submitUrl}" modelAttribute="user">
<form:input path="telephoneNumber"/>
</form>
Model telephoneNumber setter:
if(!StringUtils.isBlank(telephoneNumber)){
this.telephoneNumber = telephoneNumber.replaceAll("[^0-9]", "");
} else{
this.telephoneNumber= "";
}
And I think so because the value lands in the database with the formatting I used. (spacing)
Even if it is not the correct answer to your question:
I strongly recommend to do the formating in an other way then by setter getter
Spring 3.0 provideds something they called "type conversion"
spring blog with example
spring reference "Validation, Data Binding, and Type Conversion"
Using this would be much more cleaner.
Back to your question:
Spring path binding: is it bound directly to the variable or does it invoke the constructor/setters?
As fare I understand the Java Doc and some code snippets, Spring uses BeanWrapper (BeanWrapperImpl) to set the values of Beans (#see Reference: 5.4 Bean manipulation and the BeanWrapper). And BeanWrapperImpl behaves like the reference said:
uses setter and getter to access "simple" values.
It is exactly like the reference said in section "5.4.1 Setting and getting basic and nested properties": For an expression "name":
Indicates the property name
corresponding to the methods getName()
or isName() and setName(..)
So at least this answer your question, so I assume that the cause for your problem is some thing else.
When experimenting with Spring MVC, I noticed the values passed to controller arguments annotated with #PathVariable will have all the characters from the last '.' on stripped, unless the last character is a '/'.
For example, given the following code:
#RequestMapping("/host/${address})"
public String getHost(#PathVariable String address, Model model) {
model.addAttribute("host", hostRepository.getHost(address));
return "host";
}
If the URL is "/host/127.0.0.1", the value of address will be "127.0.0". If the URL is "/host/127.0.0.1/", the value of address will be "127.0.0.1".
Is there away to prevent this stripping?
There are plenty of such reports in their issue tracker already (for example, SPR-5778). But they don't fix it, so it seems to be a legitimate behaviour.
The official workaround is to set useDefaultSuffixPattern = false on DefaultAnnotationHandlerMapping, but it has several drawbacks:
It is applied to all controllers
It completely disables extension handling (for example, for ContentNegotiationViewResolver)
It breaks "trailing slash doesn't matter" rule
More sophisticated workarounds use a customized PathMatcher, as described here.
It's apparently been handled as a file extension and stripped. Not sure if it's a bug. I would fill an issue at their issuetracker.
Update: please check this topic, it's actually not a bug and it can be solved programmatically: Trying to create REST-ful URLs with mulitple dots in the “filename” part - Spring 3.0 MVC