Skip to content

[JavaSpring] Bug generating @Pattern regex #9509

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

Closed
elier opened this issue Jun 20, 2019 · 10 comments · Fixed by #12038
Closed

[JavaSpring] Bug generating @Pattern regex #9509

elier opened this issue Jun 20, 2019 · 10 comments · Fixed by #12038
Assignees

Comments

@elier
Copy link

elier commented Jun 20, 2019

Description

When generating from this yaml file:
https://raw.githubusercontent.com/OpenBankingUK/account-info-api-spec/master/dist/v2.0.0/account-info-swagger.yaml

Regex pattern like this '^\d{1,13}.\d{1,5}$' are not escape property and the generated java code does not compile.

To discuss: Should the code generation be responsible for escaping the regex properly for every language? or Should I modify the YAML to provide the appropriated escape?

Swagger-codegen version

3.0.8

Swagger declaration file content or url
definitions:
  Amount:
    type: string
    pattern: '^\d{1,13}\.\d{1,5}$'
Command line used for generation

swagger-codegen generate -i https://raw.githubusercontent.com/OpenBankingUK/account-info-api-spec/master/dist/v2.0.0/account-info-swagger.yaml -l spring -o api-server

Steps to reproduce

swagger-codegen generate -i https://raw.githubusercontent.com/OpenBankingUK/account-info-api-spec/master/dist/v2.0.0/account-info-swagger.yaml -l spring -o api-account
mvn install

Related issues/PRs
Suggest a fix/enhancement

Wrong java code generated:

@Pattern(regexp="^\d{1,13}\.\d{1,5}$")   

Right code generated should be: \

@Pattern(regexp="^\\d{1,13}\\.\\d{1,5}$")   
@erreobi
Copy link

erreobi commented Jun 27, 2019

I'm having the same problem now ... we have just updated to the version from 2.3.1 to 2.4.5

@shameerkc
Copy link

shameerkc commented Jul 8, 2019

Facing the same issue, while working with https://github.com/jdegre/5GC_APIs/raw/master/TS29571_CommonData.yaml

    Mnc:
      type: string
      pattern: '^\d{2,3}$'
`

Generated output includes below error: java: **illegal escape character**


```java
@Pattern(regexp="^\d{2,3}$")   public String getMnc() {
    return mnc;
  }

`

@markwoon
Copy link

Still a problem with 3.0.21

@volkerrichert
Copy link

and also in 3.0.23. This is open since nearly 2 years. Does anyone have a workaround?

@HugoMario
Copy link
Contributor

Hi @volkerrichert ,

Yes, we're working on this, and any PR is always welcome

@msm416
Copy link

msm416 commented Apr 1, 2021

Hello @HugoMario,

I've run into the same problem (single forward slash instead of double, for my regex) while invoking the 3.0.24 jar on my own spec, but for jaxrs-jersey

What is the progress on this issue for both spring and jaxrs-jersey?

Thank you!

@cdprete
Copy link

cdprete commented Apr 26, 2021

I can confirm the same issue for version 2.4.19

@cdprete
Copy link

cdprete commented Apr 26, 2021

Weird enough, if you provide an example in the definition then the pattern is correctly generated, unless you reference a scalar type with $ref. In such a case, the pattern is copied over without the example and it's then broken again...

@ambition-consulting
Copy link

still applies in 4.3.1 when converting @digits(integer = Integer.MAX_VALUE, fraction = 3) to @pattern(regexp="^\d{1,2147483647}([.]\d{1,3})?$")

@dlhermit
Copy link

dlhermit commented Jan 12, 2023

Is there any progress on this issue?
We are currently using the last version, and the bug is still there

<groupId>io.swagger.codegen.v3</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId>
<version>3.0.36</version>

As a workaround we are using

<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<version>6.2.1</version>

This one gegerates the correct code

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.

10 participants