springfox: operationId is not guaranteed to be unique
An example of the naive implementation failing is a definition for request mappings like the following
@RequestMapping(method=RequestMethod.GET, value={"/campaigns","/campaigns/{id}"})
public String getCampaignDetails(Model model,
@RequestParam(value="id", required=false) Long id,
@PathVariable("id") Long id2)
{
}
Another scenario:
@RequestMapping(method=RequestMethod.GET, value={"/campaigns","/campaignsAlias"})
This bug relates to #659
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 19 (17 by maintainers)
Commits related to this issue
- Deprecated methods that will most likely be removed in 2.1 from ResourceGroupingStrategy The new internal api will be the result of tackling #737, #771 and #682 — committed to springfox/springfox by dilipkrish 9 years ago
- Fixes to ensure that operation ids are unique in the swagger generated space. Also introduced the notion of caching and explicitly declared the caches to cache the models/model properties/model depen... — committed to springfox/springfox by dilipkrish 9 years ago
- Since this is part of a dot release, backporting it to use spring 4.0.9 where cacheables do not expose a keyGenerator annotation attribute related to #682 — committed to springfox/springfox by dilipkrish 9 years ago
- Reverted the changes so that the contracts are the same as pre-this change related to #682 — committed to springfox/springfox by dilipkrish 9 years ago
- Renamed handlerMappings requestHandlers related to #682, #825 — committed to springfox/springfox by dilipkrish 9 years ago
- Updated to use base class RequestMappingInfoHandlerMapping where possible related to #682, #825 — committed to springfox/springfox by dilipkrish 9 years ago
- Refactored the bootstrapper to take in a RequestHandlerProvider This is a step forward to support different request handler providers. It is also incidentally used to create a predictable ordering of... — committed to springfox/springfox by dilipkrish 9 years ago
- Fixed the issue with the cache key generator algorithm in addition to sorting the RequestHandlers to facilitate a predictable ordering of operations related to #682, #825 — committed to springfox/springfox by dilipkrish 9 years ago
- Made the swagger contract tests consistent with respect to method name generation Over different runs the ordering of the operations determined the names of the operations in the case of multiple ope... — committed to springfox/springfox by dilipkrish 9 years ago
Hi,
I am using the 2.1.0 Springfox release. I make sure to provide proper meaningful and unique nicknames across all our controllers. So, I really do not want Springfox to add the additional uniqueness strings something like “UsingGET” etc.
The generated operation ids or java code looks like this, If you look at each of the method names, they are already unique and convey meaningful information. I really do not want the Using part to be appended. I agree that in some scenarios it might be helpful when the developers who do not provide nicknames. But if a nickname is provided then, we should definitely leave the responsibility to the users/developers and not override their settings. Or provide any other mechanism to get the name as what I want to.
Rack Controller.
getRacksUsingGET() getRackUsingGET(String) getAlertsUsingGET1(String, String) getSetupConfigUsingGET(String) updateSetupConfigUsingPUT(String, RackConfig) getEventsUsingGET1(String, String) getHostsUsingGET2(String) getIpReAllocationUsingGET(String) rerunIpReAllocationUsingPUT(String) performIpReAllocationUsingPOST(String) cancelIpReAllocationUsingDELETE(String) getSwitchesUsingGET(String)