Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Java][Spring] Add support for custom validation messages in Beanvalidation annotations #5643

Closed
TomSoflow321 opened this issue May 15, 2017 · 15 comments · Fixed by #9121
Closed
Assignees

Comments

@TomSoflow321
Copy link

TomSoflow321 commented May 15, 2017

The PR #4600 added support for beanvalidation annotations, which work fine, but generated annotations also support a message property to specify a custom error message if the validation for that annotation fails.
This can look like this:

@ApiModelProperty(example = "VGVzdA==", value = "")
@Pattern(regexp="^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$", message = "The provided String is not Base64 encoded")
public String getFoo() {
    return foo;
}

Are there plans to add support for such a message? It might be possible to add it to the declaration file like:

foo:
    type: string
    pattern: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$"
        message: "The provided String is not Base64 encoded"
    example: "VGVzdA=="

I guess this feature must be added in the beanValidationCore.mustache template (in swagger-codegen/src/main/java/resources/), but I'm not proficient enough with that template language to do that myself.

(I've tested the release version of 2.2.0 and the current master version, but both don't support these message properties)

@cartick
Copy link

cartick commented Jun 26, 2017

+1

@shexbeer
Copy link

+2

@gmgk93
Copy link

gmgk93 commented Jan 18, 2018

+1

@unphon
Copy link

unphon commented Nov 5, 2018

+1 very important, our clients are getting a ton of regex instead of a readable error message

@HugoMario
Copy link
Contributor

Hello @TomSoflow321 @cartick @shexbeer @gmgk93 @unphon

i can implement this using vendor extensions.

foo:
    type: string
    pattern: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2} ..."
    x-message: "The provided String is not Base64 encoded"
    example: "VGVzdA=="

I would update templates to read the x-message field. Please let me know what you think about that.

@JeffGoderie
Copy link

@HugoMario,

While I do think that the use of vendor extensions might work for this, your suggestion might be problematic when multiple constraints are required (e.g. minLength + maxLength). It might also be hard to relate this to 'required' constraints, since these are separated from the field declaration.

One option that I see is to still use vendor extensions, but have one per constraint:

properties
foo:
    type: string
    pattern: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2} ..."
    x-pattern-message: "The provided String is not Base64 encoded"
    x-required-message: "The provided String cannot be null"
    example: "VGVzdA=="
required:
    - foo

What are your thoughts on this?

@HugoMario
Copy link
Contributor

i like that, i can do it that way. thanks

@jlau96
Copy link

jlau96 commented Dec 6, 2018

+1

@pratikrpatel
Copy link

You might want to support localisation and might want to consider message keys as well.

@HugoMario HugoMario self-assigned this Jan 13, 2019
@HugoMario HugoMario added this to the v3.0.4 milestone Jan 13, 2019
@HugoMario HugoMario modified the milestones: v3.0.4, v3.0.5 Jan 25, 2019
@HugoMario
Copy link
Contributor

hello guys, i'm really really sorry for delay. i just merged a PR making possible the custom message.
Here is an example about how it works:

swagger: '2.0'
info:
  version: '1.0.0'
  title: 'simple'
  description: 'it is simple'
paths:
  /foo:
    post:
      parameters:
        - in: body
          name: body
          schema:
            $ref: '#/definitions/BodyParam'
      responses:
        200:
          description: OK
          schema:
            $ref: '#/definitions/OKResponse'
        400:
          description: Error
          schema:
            $ref: '#/definitions/ErrorResponse'

definitions:
  BodyParam:
    type: object
    properties:
      foo:
        type: string
        pattern: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$"
        x-pattern-message: "extension pattern message."
        message: "The provided String is not Base64 encoded"
  OKResponse:
    type: object
    properties:
      bar:
        type: string
  ErrorResponse:
    type: object
    properties:
      error:
        type: integer
      message:
        type: string
    required:
      - error
      - message

The custom message for patter will have this output on BodyParam model:

@Validated
@javax.annotation.Generated(value = "io.swagger.codegen.languages.SpringCodegen", date = "2019-01-25T11:05:38.641-05:00")

public class BodyParam   {
  @JsonProperty("foo")
  private String foo = null;

  public BodyParam foo(String foo) {
    this.foo = foo;
    return this;
  }

  /**
   * Get foo
   * @return foo
  **/
  @ApiModelProperty(value = "")

@Pattern(regexp="^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$", message="extension pattern message.") 
  public String getFoo() {
    return foo;
  }

  public void setFoo(String foo) {
    this.foo = foo;
  }
...

@finnuser
Copy link

finnuser commented Jul 29, 2021

is openapi 3.0.0 has message option to give custom message for validation failure like swagger 2.0
properties:
foo:
type: string
pattern: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$"
x-pattern-message: "extension pattern message."
message: "The provided String is not Base64 encoded"

@vardhanjai123
Copy link

@finnuser Even I want that feature.

@AishwaryaParthasarathy
Copy link

Is there a way to have custom message in open spec ? is there any jira on this issue

@egridav
Copy link

egridav commented Apr 4, 2022

Hi,
Any news of any added custom message for validation failure like swagger 2.0?
Is there a way to workaround this?

@CathyWang53
Copy link

+1 want this feature in 3.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.