2.9.0 change the order of parameters in operations

[fgoulet]

After upgrading to 2.9.0 from 2.8.0, the parameters of my operations are now sorted alphabeticaly instead of following the order of declaration in the java method. This is a problem because I generate a client with Swagger codegen and the parameters are no longer in the order my app expect them to be.

[dilipkrish]

@fgoulet the order has never been guaranteed. It just happened to be consistent and stable. What we discovered when moving to java 8 compiler was that the order changed. When we realized that was the case, the parameters were changed to being alphabetically sorted; to maintain stability of the order, atleast going forward.

Sadly, it has affected your application. Going forward, the ordering will be more stable.

[fgoulet]

Thanks for the explanation. I think a way to enforce a particular order for parameters would be much needed, especialy in client code generation scenario. Is it something that could be eventualy done via the @ApiParam or @RequestParam annotations ?

[dilipkrish]

@fgoulet, perhaps a custom annotation even. The underlying model for the specification doesnt guarantee an order regardless.

[dtrucken]

Gosh, this is a bummer. One of the things that made SpringFox so great is that it generated easy-to-use screens, good enough for developers, and even Business folks to use for things like Admin screens and other "not so important to get the UI team involved" endpoints. Being able to keep the parameters in order was nice, since logically, "startDate" comes before "endDate", even though the alphabet doesn't think so. Is there any way to preserve the order, or even specify the order?
(I hate it when specs get in the way of doing the "right" thing)

[livarb]

Another reason to have default sorting match the order of declaration in the code; grouping of required and optional parameters. In my case the first parameters declared are required parameters (because they are path parameters), while the rest are query-parameters and optional. Since the parameters are now sorted alphabetically, the required and optional parameters are mixed and it's not. Clearing this up would require adding extra annotations to ensure the desired sorting. Manually adding annotations to get the right sorting in Swagger would be a lot of extra work and another thing to maintain, so I'll be sticking to 2.8.0 for now.

[dilipkrish]

@livarb the data structure doesn't guarantee order, it is a Map so the order which some parameters appear cannot guarantee order unless its a List. I understand your concern however. We can add a feature to respect specified order, but that would require a request swagger-core to add a sort order for parameters in teh annotation. It is also feedback that should go back to the OpenApiSec.

[mdwn]

Just to provide some feedback, this change may have made springfox unusable for us, unfortunately. We're trying to see what we can do to restore the order within the confines of springfox, but it looks like it isn't easily doable, so we may have to explore other options.

[mreiterer]

I fully agree with @meowfaceman and @livarb.

@dilipkrish I dont get your argument. It worked before - did you change the underlying data structure? And even if it is a map now you can easily swith to a SortedMap for example.

[Manish794]

Provide some option to choose whether to sort the parameter alphabetically or preserve the operation parameter order.
If it uses Map then LinkedHashMap preserve the insertion order. Or choose some Map that preserve the order as it is depending on user choice

[Manish794]

I was using Java Configuration to create the client and was using the generated client in other application.
When I updated the springfox version 2.9.2 then in the new client the parameter order is changes. It is in sorted order now. It is breaking my integration as in older version, the parameter was in the order as listed in API.

[LilSebastian5000]

@dilipkrish Can't the UiConfiguration just have a sorter based on the order of the getters/setters of the java beans for POST requests? Doesn't "OperationsSorter.METHOD" effectively do the same to sort the endpoints' display on the UI?

Alternatively for GET requests, I'd think the ordering of params can be based on the order they appear in the controller method's params.

[fathzer]

Just to provide some feedback, this change may have made springfox unusable for us, unfortunately. We're trying to see what we can do to restore the order within the confines of springfox, but it looks like it isn't easily doable, so we may have to explore other options.

Does anyone find an alternative? This problem also makes springfox not suitable for my needs.

[mdwn]

We moved to swagger-maven-plugin in the meanwhile. The documentation is a bit lacking, but it preserves the order of methods.

[livarb]

@dilipkrish : From what I understand, this change is related to external dependencies (swagger-core). Is that correct? If that's the case, I'd like to create an issue in the repository for the external dependency.

[fathzer]

I had a look at the source code. It's not a problem with Map limitation, it's a deliberate choice to sort parameters in an arbitrary order (from the user point of view).
Here is the commit: 4ab3fc6 (line 86 of springfox-core/src/main/java/springfox/documentation/service/Operation.java)

I posted here an ugly workaround: #2705

[shartte]

So I've put up PR #2721, which allows the following Plugin (Kotlin, adapt as needed if the PR gets merged) to restore the previous parameter order:

@Order(SwaggerPluginSupport.SWAGGER_PLUGIN_ORDER + 1000)
class OriginalParamOrderPlugin : ParameterBuilderPlugin {

  override fun apply(parameterContext: ParameterContext) {

    val order = parameterContext.resolvedMethodParameter().parameterIndex
    parameterContext.parameterBuilder().order(order)

  }

  override fun supports(delimiter: DocumentationType) = true

}

p.s.: My PR will maintain alphabetical order for any parameters that have the same value for "order", which parameters currently all seem to have.

[janekbettinger]

@shartte, have you tested your plugin? I've written a similar plugin implementing ExpandedParameterBuilderPlugin that sets the parameter order by context.getParameterBuilder().order(orderValue), however, the desired order is not respected by Swagger.

Digging into the code, I've found out that Springfox finally orders the parameters by name:
https://github.com/springfox/springfox/blob/master/springfox-core/src/main/java/springfox/documentation/service/Operation.java#L84 (as @fathzer has mentioned above):

parameters.stream().sorted(byParameterName()).collect(toList());

The order field is not taken into account.

[LilSebastian5000]

Why was this ever closed? @dilipkrish

[shartte]

@kroka as mentioned, my plugin depends on the linked PR being merged

…

On Thu, Oct 11, 2018, 16:31 kroka ***@***.***> wrote: @shartte <https://github.com/shartte>, have you tested your plugin? I've written a similar plugin implementing ExpandedParameterBuilderPlugin that sets the parameter order by context.getParameterBuilder().order(orderValue), however, the desired order is not respected by Swagger. Digging into the code, I've found out that Springfox finally orders the parameters by name: https://github.com/springfox/springfox/blob/master/springfox-core/src/main/java/springfox/documentation/service/Operation.java#L84 (as @fathzer <https://github.com/fathzer> has mentioned above): parameters.stream().sorted(byParameterName()).collect(toList()); The order field is not taken into account. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2418 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABM_V31Nb7t0AH7wrXnGMsZNZ2_O1Okjks5uj1Y5gaJpZM4T9u73> .

[okohub]

This strange breaking change also crashes our code-generation flow. Now we stucked at version 2.8.0, sadly.

You should provide an option to override this behaviour.

[dilipkrish]

@fathzer @shartte thanks for the issue #2705 and PR #2721. Will try and prioritize making this configurable, yet predictable by default

[mikecollard]

@dilipkrish any update on this, swagger ui is not usable any more for my users (i have many apis with a lot of optional parameters and start/limit paging parameters, they used to be at the bottom of the list and easy to find - last in declaration - now they are scattered about seemingly randomly to user)

[dkirrane]

Hi, was there a solution or fix merged for this?

[Glamdring]

This behaviour is still counter-intuitive, please reopen.

[gsbtech]

I had the same problem using
@JsonPropertyOrder
with springfox 2.9.2The interesting thing is that it applies the ordering to some POJOS, not to all.
I have a class that extends another.
E.g.
@JsonPropertyOrder(value = {"id"})
public class UserProofVerificationResource extends ProofVerificationResource
...
@JsonPropertyOrder(value = {"purpose", "method", "status"})
public class ProofVerificationResource {

---

The parent class @JsonPropertyOrder is ignored, not added to the subclass field ordering.

So, what I did, was to add the parent class fields to the subclass and now the ordering is fine.
@JsonPropertyOrder(value = {"id", "purpose", "method", "status"})

[Hervian]

I don't think sorting parameters alphabetically is a good idea, neither for automatic swagger doc generation logic or for automated codegeneration based on swagger doc.

Otherwise adding a new parameter may cause a complete reordering of the Parameters array (depending on the name chosen for the parameter).

If the client code generation logic makes use of overloading they may not even get a compile time error since a new method with the same types may have been generated, and only the parameter names will be different since the query params in the signature are actually different due to the reordering.

If the generated client code does not make use of overloading tricky errors may still happen: It may appear as if they get the compilation error due to the addition of a new optional variable in the API from which the client code is generated, so the developer simply solve this by adding null to the call to the autogenerated client method. Now the code compiles. But since a reordering may have occured they may be setting the new optional parameter to someOldValue and the someOldValue parameter to null.

No overloading scenario:

Generated code before adding 'Boolean aParam':
public void myOperation(Boolean bParam ) { }

Generated code after adding 'Boolean aParam':
public void myOperation(Boolean aParam, Boolean bParam ) { }

Overloading scenario (let's assume that the parameters are optional):

Generated code before adding 'Boolean aParam':
public void myOperation() { }
public void myOperation(Boolean bParam ) { }

Generated code after adding 'Boolean aParam':
public void myOperation() { }
public void myOperation(Boolean aParam ) { }
public void myOperation(Boolean aParam, Boolean bParam ) { }

[svetozar02]

I had the same problem using
@JsonPropertyOrder
with springfox 2.9.2The interesting thing is that it applies the ordering to some POJOS, not to all.
I have a class that extends another.
E.g.
@JsonPropertyOrder(value = {"id"})
public class UserProofVerificationResource extends ProofVerificationResource
...
@JsonPropertyOrder(value = {"purpose", "method", "status"})
public class ProofVerificationResource {

The parent class @JsonPropertyOrder is ignored, not added to the subclass field ordering.

So, what I did, was to add the parent class fields to the subclass and now the ordering is fine.
@JsonPropertyOrder(value = {"id", "purpose", "method", "status"})

@gsbtech I tried using@JsonPropertyOrder and it's getting ignored... Any idea why?

[svetozar02]

Since I couldn't figure out how to get JsonPropertyOrder to get picked up by springfox I've added io.swagger.annotations.ApiModelProperty annotation to each field and explicitly specified the position... It works but obviously it adds duplicate logic...

[javaHelper]

How to fixed this issue ?

[fzyzcjy]

How can we fix the issue? (After more than a year...) This is a critical feature!

[bvn13]

position attribute at `@ApiModelParameter' does not bring any effect

[arman-bd]

So, I just updated my project from 2.7.0 to 2.9.0.. or I should say, I was trying to...
I never faced such a terrible up-gradation. So many changes and so little documentation..
It was very very exhausting and tiring..

This issue was the last straw that forced me to pull out all the messy springfox codes and annotations from my project.

I really appreciate the hard work done by springfox peoples.

P.S: I've moved to springdoc, Life was never been so easier..

[joeykay9]

Any update to this issue?

[kuixiang]

Any update to this issue?

[karaelf33]

Seems, no update. Still the order changes. In my case, it is grouping by required and non-required parameters