* remove http signature from test yaml when not supported
* do not use HttpBearerAuth for signature auth or other unsupported http auth method
ignore unsupported http auth method unless generated code would not compile (in which case, an exception is thrown)
* [Java] fix use of isBasic condition
* [kotlin] fix use of isBasic condition
* [go-server] Support min/max/defaults for values
Enforce, for the go-server, to check the minimum and maximum values
specified in the openapi description. Also apply the default if the
parameter is not passed.
Fix#14013
* Fix merge conflict
Co-authored-by: Ween Jiann <16207788+lwj5@users.noreply.github.com>
* Improve UnmarshalJSON implementation
Co-authored-by: Ween Jiann <16207788+lwj5@users.noreply.github.com>
* Improve default value handling for string
Co-authored-by: Ween Jiann <16207788+lwj5@users.noreply.github.com>
* Fix suggested changes
* rework option pattern
* add imports based on types/min max values
---------
Co-authored-by: Ween Jiann <16207788+lwj5@users.noreply.github.com>
* Add apiNameSuffix to AbstractGoCodegen
* Regenerate files
* Update tests
* Regenerate files
* Update test files
* Regenerate for CI test
* Regenerate for CI test
* Remove some docs
* Add files back
* fix circleci test failures
* trigger test
* update circleici pom.xml
* rearrange test
* comment out tests
* fix test
* comment out python-prior
* comment out test
* fix import
* comment out tests
* [C++][Pistache] Refactor setupSupportingFiles
Supporting files are set up in the CppPistacheServerCodegen()
constructor as well as in processOpts(). Refactor the code and extract a
method setupSupportingFiles().
* [C++][Pistache] Refactor: Simplify isQueryParam condition
Both branches of the if/else do the same steps. Refactor this out and
invert logic.
* [C++][Pistache] Refactor: Add injectImplInFilename
Both branches of the if/else if do the similar steps and are dependent
on the suffix. Make this obvious by introducing a new method
injectImplInFilename(String result, String suffix).
* [C++][Pistache] Refactor: injectImplInFilename: remove index search
We do not need the separatorChar index to inject the "Impl" string.
Simply truncate the whole string.
Also rename the parameter from 'result' to' filename'.
* CppPistacheServer: Refactor postProcessOperationsWithModels
Pull out the post-processing for a single operation, and also pull out
post-processing for parameters.
Introduce boolean expressions for supported parsing per parameter, and
consumption of JSON.
Reorder code to make locality more explicit i.e. how consumeJSON and
isParsingSupported is generated and used.
* CppPistacheServer: Refactor to use functional matching
Functional matching like anyMatch() directly state what boolean value is
searched.
However, the Predicates deserve to heave names themselves.
* CppPistacheServer: Add base class for Api
Looking at the generated main-api-server.cpp code it gets obvious that
the API classes are self similar with a similar interface.
Only the construction and teh initialization is called in the main()
function. Leverage this fact to create a generalization ApiBase.
Introduce ApiBase as a pure virtual base class to the concrete API
classes and declare init() as virtual.
Pull the route member into the base class.
With this change we could have a container hold all the ApiImpl
objects later and call init() on all of them using a for_each loop.
* CppPistacheServer: Use ApiBase for ApiImpl storage
Refactor the main-api-server template to use a vector for ApiImpl
storage instead of separate objects. This leverages the previously
added ApiBase generalization.
We push all concrete ApiImpl objects into a vector and call init() on
each of them.
* [C++][Pistache]: Update generated sample
Due to teh addition of ApiBase class update the generated sample.
* [C++][Pistache] Add comment for postProcessSingleParam
* [C++][Pistache] Rename and comment implFilenameFromApiFilename
While writing the comment, I realized that the method name could be more
precise. Thus rename injectImplInFilename to implFilenameFromApiFilename
and add comment.
* fix issue 15264
* If useResponseEntity true then keep @Controller if not @RestController
---------
Co-authored-by: Rodrigo Maciel de Almeida <rodrigo.almeida@wefin.com.br>
* if method return type is void then no return
* build the project
* fix build the project
* fix build the project
* fix return
* fix build the project
* fix build the project
* fix build the project
---------
Co-authored-by: Rodrigo Maciel de Almeida <rodrigo.almeida@wefin.com.br>
* 5705: Move JsonProperty annotation to the getters
* Regenerate samples
* Add jackson check
* Add test
* Minor fix
* Fix test
* Fix version
* [Java][Spring] update test & samples; add serialization/deserialization test
---------
Co-authored-by: Oleh Kurpiak <oleh.kurpiak@gmail.com>
* Added the useResponseEntity additional parameter for Spring generator
* Changed the mustache templates using the new useResponseEntity property
* Added the new property to the documentation
* Merging with remote master
* #11537 Added missing configuration for the delegate pattern case
* #11537 Added autogenerated @ResponseStatus on Spring methods
* #11537 Fixed borsch comments
* #11537 Added the default 200 HTTP Status for empty response HTTP code
* [Java][Spring] useResponseEntity sample + remove blank line
* [Java][Spring] useResponseEntity sample + remove blank line
* [Java][Spring] useResponseEntity sample + remove blank line
---------
Co-authored-by: Oleh Kurpiak <oleh.kurpiak@gmail.com>
* [PHP-Symfony] fixes validation of date-time parameter
This fixes parts of #14930.
Without this patch a parameter declared as date-time
is validated against Symfony's "DateTime" constraint,
which always fails. Because this constraint expects
a string with format "Y-m-d H:i:s".
It fails because the generated code performs the check
after the deserialization, so the variable checked is not
a string anymore.
Besides this, even if we performed that validation on the
string, that would not work well because OpenApi
specification expects date-time to conform to RFC 3339
and that "Y-m-d H:i:s" would reject RFC 3339 compliant dates.
With this change we ensure that the string provided by the
web user could be parsed by PHP to DateTime, which solves both issues.
(Note however that it means that it now accepts more formats than just
RFC 3339 compliant ones for those parameters (it would accept all formats
accepted by PHP DateTime). That being said it's compliant with the guideline
""be conservative in what you send, be liberal in what you accept")
* [PHP-Symfony] Fix handling of null date-time parameter
This fixes one of the issue described on #14930, namely that
the deserializeString method of the generated class JsmSerializer returns null
for other types of string, but not for date-time. Instead it returns a DateTime
which represents "now" (because that what `new DateTime(null)` does).
Consequently when an API declares a date-time parameter as non-required and
when that endpoint is called without that parameters, then the user code
would end up having "now" instead of "null" for this parameter.
