Skip to content

Some issues when upgrade to SpringDoc 2.7 #2984

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

Open
cd4ever opened this issue May 8, 2025 · 5 comments
Open

Some issues when upgrade to SpringDoc 2.7 #2984

cd4ever opened this issue May 8, 2025 · 5 comments

Comments

@cd4ever
Copy link

cd4ever commented May 8, 2025

Recently I ran into some issues when upgrade to SpringBoot 3.4.5 and SpringDoc 2.7.

Here is maven dependencies of my project,

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>3.4.5</version>
		<relativePath/> <!-- lookup parent from repository -->
	</parent>

		<dependency>
			<groupId>org.springdoc</groupId>
			<artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
			<version>2.7.0</version>
		</dependency>
I have one controller method like this, 
    @Operation(summary = "get user list")
    @GetMapping(value = "")
    public CommonResult<CommonPage<UmsUser>> list(UmsUserQueryParam queryParam,
                                                  @RequestParam(value = "pageNo", defaultValue = "1") Integer pageNo,
                                                  @RequestParam(value = "pageSize", defaultValue = "5") Integer pageSize) {
    ...
   }

And here is the definition of UmsUserQueryParam,

@Data
@Accessors(chain = true)
public class UmsUserQueryParam {
    @JsonSerialize(using = ToStringSerializer.class)
    @Schema(name = "userId")
    private Long userId;

    @Schema(name = "username")
    private String username;

    @Schema(name = "email")
    private String email;

    @Schema(name = "mobile")
    private String mobile;

}

When I go to the swagger page,

Image

You see the queryParam is rendered as "object", not split UmsUserQueryParam object into individual properties like what I see in previous version of swagger page.

In that project, there is also a similar controller method and one query class,

@Data
@Accessors(chain = true)
public class UserQueryParam {
    @ApiModelProperty(value = "user id")
    private Long userId;

    @ApiModelProperty(value = "user name")
    private String username;

    @ApiModelProperty(value = "email")
    private String email;

    @ApiModelProperty(value = "mobile")
    private String mobile;

    @ApiModelProperty(value = "enable status")
    private Integer enableStatus;

    @ApiModelProperty(value = "department id")
    private Long deptId;

    @ApiModelProperty(value = "domain id")
    private Long domainId;

    @ApiModelProperty(value = "role id")
    private Long roleId;
}

It look like below, every property is rendered individually,
Image

What's more, there is another Long type precision loss issue. When I input the value of userId like below,

Image

It actually invoke backend API with some precision loss like below. I input 1917147886395588608, but it passes 1917147886395588600
Image

So can anyone give me some prompt on above two issues?

@Mattias-Sehlstedt
Copy link

Hi,

Could you please state the previous version used so that it is possible to compare the differences introduced when going from X to 2.7?

@Mattias-Sehlstedt
Copy link

The later issue with the large number does not look to be tied to springdoc, please see swagger-api/swagger-ui#2030

@cd4ever
Copy link
Author

cd4ever commented May 9, 2025

Hi,

Could you please state the previous version used so that it is possible to compare the differences introduced when going from X to 2.7?

The mentioned previous project actually uses springfox. Below is some version info,

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.10.RELEASE</version>
    </parent>

        <swagger2.version>2.9.2</swagger2.version>
        <swagger-models.version>1.6.0</swagger-models.version>
        <swagger-annotations.version>1.6.0</swagger-annotations.version>

            <dependency>
                <groupId>io.springfox</groupId>
                <artifactId>springfox-swagger2</artifactId>
                <version>${swagger2.version}</version>
            </dependency>
            <dependency>
                <groupId>io.springfox</groupId>
                <artifactId>springfox-swagger-ui</artifactId>
                <version>${swagger2.version}</version>
            </dependency>
            <dependency>
                <groupId>io.swagger</groupId>
                <artifactId>swagger-models</artifactId>
                <version>${swagger-models.version}</version>
            </dependency>
            <dependency>
                <groupId>io.swagger</groupId>
                <artifactId>swagger-annotations</artifactId>
                <version>${swagger-annotations.version}</version>
            </dependency>

@cd4ever
Copy link
Author

cd4ever commented May 9, 2025

The later issue with the large number does not look to be tied to springdoc, please see swagger-api/swagger-ui#2030

Yes, it is more like relate with the JSON data type limitations. So as I understand, if the queryParam object can be split into individual fields like what previous version does, the field with Long type should be processed correctly.

@Mattias-Sehlstedt
Copy link

Could we compare the difference in the generated specification for the query parameter? I have no idea how or if springfox-swagger-ui and swagger-ui differ in how they render a certain query schema, and that could technically be the cause for it.

But if it is the case that they render schemas in the same way, then comparing the schemas is most likely the easiest approach for finding a solution, since they you will know that you want to springdoc-openapi introspection to generate the exact same schema structure that springfox generated.

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

No branches or pull requests

2 participants