Validation errors default behavior about errors-spring-boot-starter HOT 11 CLOSED

Hi @alimate

I'll try to provide a PR next week.

from errors-spring-boot-starter.

@clemstoquart have you started on this PR? I'm actually having the same problem where I specially would like to have the invalid parameter names in the response and thought to do a PR.

If you have started and not yet completed maybe I can help around if you don't have enough time on your hand.

Thanks! And @alimate, great library, cheers mate! 😀

from errors-spring-boot-starter.

Thanks @alimate!

Silly me! Halfway through implementation of including arguments to have property parameter in the error response I saw that there is already support for exposing arguments that can be achieved using the property errors.expose-arguments=ALWAYS.

As for the the messages, I liked your idea of thinking where we actually get the property name right in the error message in the format of propertyPath.ConstraintName, really nice idea!!!

I will check your code in detail, from the first sight, it looks much more than just "prototypical PoC" 😀.

Thanks! Appreciate the support and your time on this open source project.

from errors-spring-boot-starter.

@clemstoquart @ErfanY I have a prototypical PoC here that may come useful.

Suppose, you have a to-be-validated DTO as following:

class SomeDto {

        @NotBlank
        private String text;

        @URL
        private String callback;

        @Min(message = "", value = 5)
        private int num;

        @NotBlank(message = "  ")
        private String another;

        @Valid
        private Default nested;

        // getters and setters
}

Then if we pass a blank value to the text field, then the error code would be text.NotBlank instead of javax.validation.blah.
Basically, the error code would follow the propertyPath.ConstraintName format.

from errors-spring-boot-starter.

@ErfanY @clemstoquart Thank you guys for reporting this issue 🙏

from errors-spring-boot-starter.

Hey @clemstoquart. Thanks for reporting this issue. I was able to reproduce the issue and yeah, you're right. Your suggestion seems valid to me 🙏

from errors-spring-boot-starter.

@clemstoquart That'd very much appreciated 🙏

from errors-spring-boot-starter.

@ErfanY Glad you liked it ☺️😉

from errors-spring-boot-starter.

@ErfanY I've somehow started working on the subject but it was more complicated than expected. I don't have any working implementation right now.

from errors-spring-boot-starter.

Make sense! All of those constraints are in either of javax.validation or org.hibernate.

The only complexity comes to constraints like Size with min and max. Where the message would not really give a better information on the valid intervals.

This implementation fits perfect for those annotation constraints where the annotation itself is self explanatory and does not have any internal parameters that's needed to provide information?

from errors-spring-boot-starter.

@ErfanY We can abstract away the error code generation mechanism with something like:

interface ErrorCodeGenerator<T> {
    String generate(T context);
}

Then we can provide simple Bean Validation implementations to handle different types of ConstraintViolation<T>s. But probably this would be a bit overkill for now. What do you think?
With the current approach, it would hard to handle all possible cases of constraint violations

from errors-spring-boot-starter.