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

[JavaSpring] Wrong generation of @JacksonXmlElementWrapper annotation #9845

Closed
MariaPushkin opened this issue Nov 12, 2019 · 7 comments · Fixed by #10333
Closed

[JavaSpring] Wrong generation of @JacksonXmlElementWrapper annotation #9845

MariaPushkin opened this issue Nov 12, 2019 · 7 comments · Fixed by #10333
Assignees

Comments

@MariaPushkin
Copy link

Description

I generated spring boot server stub for the swaggerfile below with using <withXml> config option. Swagger editor generates the following example of respone:

<segments>
	<segment>
		<branches>
			<branch>string</branch>
		</branches>
		<symbols>
			<symbol>string</symbol>
		</symbols>
	</segment>
</segments>

and thats what I really want. But my stub return something like that:

<segments>
   <segments>
      <segments>
        <branches>
            <branch>b1</branch>
            <branch>b2</branch>
        </branches>
        <symbols>
            <symbol>s1</symbol>
           <symbol>s2</symbol>
        </symbols>
      </segments>
   </segments>
</segments>

Adding @JacksonXmlElementWrapper(useWrapping = false) on List<Segment> segments; field in corresponding model helps to remove first <segments> tag, but adding wrapped: false to the swagger file change nothing (think because isXmlWrapped property checked only for true values - pojo.mustache.

One other problem here is that codegen cant get xml name attribute for subobjects, definded separately. Thats why I have double <segments><segments> instead of <segments><segment>. Adding xml property after $ref helps, but it is incorrect swagger, so I don`t whant to do that:

items:
   $ref: '#/definitions/segment'
   xml:
      name: segment

It seems that problem also can be seen in pojo.mustache, because #items.xmlName search only inside items swagger-property and not in subobjects.

Swagger-codegen version

version 2.4.9

Swagger declaration file content or url
swagger: '2.0'
info:
  title: API segments
  version: 1.0.0
  description: Test segments
schemes:
  - https
basePath: /base/v1
produces:
  - application/xml
consumes:
  - application/xml
paths:
  /segments:
    get:
      summary: Segments
      produces:
        - application/xml
      parameters:
        - name: symbols
          in: query
          required: false
          type: array
          items:
            type: string
        - name: branches
          in: query
          required: false
          type: array
          items:
            type: string
      responses:
        '200':
          description: OK
          schema:
            $ref: '#/definitions/segments'
definitions:
  segment:
    type: object
    description: Segment
    xml:
      name: segment
    properties:
      branches:
        type: array
        xml:
          wrapped: true
        items:
          type: string
          xml:
            name: branch
      symbols:
        type: array
        xml:
          wrapped: true
        items:
          type: string
          xml:
            name: symbol
    required:
      - branches
      - symbols
  segments:
    type: object
    description: Segments
    xml:
      name: segments
    properties:
      segments:
        type: array
        xml:
          name: segments
          wrapped: false
        items:
          $ref: '#/definitions/segment'
Command line used for generation
<plugin>
               <groupId>io.swagger</groupId>
                <artifactId>swagger-codegen-maven-plugin</artifactId>
                <version>2.4.9</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                        <configuration>
                            <inputSpec>${project.basedir}/src/main/resources/swagger.yaml</inputSpec>
                            <language>spring</language>
                            <output>../spring-server</output>
                            <configOptions>
                                <withXml>true</withXml>
                            </configOptions>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
Steps to reproduce
  1. Generate spring server stub from the swagger with using swagger-codegen-maven-plugin cofiguration.
  2. Write returning of something like this in controller:
List<Segment> segments = new ArrayList<>();
            segments.add(new Segment().symbols(Arrays.asList(new String("s1"), new String("s2")))
                    .branches(Arrays.asList(new String("b1"), new String("b2"))));
            return new ResponseEntity<>(new Segments().segments(segments), HttpStatus.OK);
  1. Compile and run stub.
  2. Make api call.
@thiko
Copy link

thiko commented Feb 6, 2020

Same here - @JacksonXmlElementWrapper annotation is missing using maven code gen plugin version 3.0.14.
@MariaPushkin did you find a workaround? We still has this problem and it makes our generation process more or less useless.

Thanks!

@volvicoasis
Copy link

Same here - @JacksonXmlElementWrapper annotation is missing using maven code gen plugin version 3.0.19.

@thiko
Copy link

thiko commented Apr 17, 2020

Workaround: We created custom mustache templates in order to override this strange behavior.
Swagger use this template files for its code gen. You can override them all or just partially.

@volvicoasis
Copy link

Hello, @thiko, can you provide in order to test your mustache template ?

@sanjeevgiri
Copy link
Contributor

Is there any open PR for this. I have an updated version of pojo.moustache to fix this.

@sanjeevgiri
Copy link
Contributor

@thiko @volvicoasis @MariaPushkin I have a PR for this now. Would you guys be able to help me push this to master? Would be nice if we could get this in place for folks in need (myself included :) )

@sanjeevgiri
Copy link
Contributor

Suggestions, and discussions are welcome. I am willing to run and post the patched generator against a swagger spec to verify the fix. I used our internal api spec that is probably not suitable for illustrating the intent of the code since that is quiet big in size.

@HugoMario HugoMario self-assigned this Aug 14, 2020
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.

5 participants