The generated Jersey 2 ApiClient for codegen v3 currently stores the most recent status code and response headers as fields, which are made available to the caller via accessor methods. This means that the client is not thread-safe if the caller needs to access the status code and/or response headers because it is possible for another caller to complete an invoke call prior to the status code and/or response headers being queried.
It appears that this is solved for other generators by returning status code and response headers via an HTTP info object, and in fact, it appears that this was done for Jersey 2 in codegen v2 - see swagger-api/swagger-codegen#7605 for details.
I'd like to propose that these changes be brought into codegen v3.
FWIW, I'm able to repro this issue using v3.0.23 by setting the following fields in my config.json using the java generator:
{
// other options such as groupId, artifactId, etc
// ...
"dateLibrary": "java8",
"library": "jersey2"
}
The generated Jersey 2 ApiClient for codegen v3 currently stores the most recent status code and response headers as fields, which are made available to the caller via accessor methods. This means that the client is not thread-safe if the caller needs to access the status code and/or response headers because it is possible for another caller to complete an invoke call prior to the status code and/or response headers being queried.
It appears that this is solved for other generators by returning status code and response headers via an HTTP info object, and in fact, it appears that this was done for Jersey 2 in codegen v2 - see swagger-api/swagger-codegen#7605 for details.
I'd like to propose that these changes be brought into codegen v3.
FWIW, I'm able to repro this issue using v3.0.23 by setting the following fields in my config.json using the
javagenerator: