You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to use swagger-inflector without individual controllers and individual methods. We want to have a single method that accepts incoming requests from multiple operations (somewhat similarly to what one can do with vertx's swagger-router). Obviously, this can be done manually by using swagger-codegen l:java-inflector and then hooking all methods into some shared code, but we'd rather not have to do it at all (manually or using our own code-gen; in fact, we wouldn't be using java-inflector in our project). Not sure if this is a direction the project is willing to accept; if not, I'll fork this project and possibly only support sinks (which is what I need for my project).
I was thinking of 1) exposing an operation-level vendor extension that describe if this operation is handled by a sink and if so, what controller and method. 2) exposing a swagger-level global that applies to all operations (maybe with an operation-level exception). 3) A sink method will accept the request and return a response, but will also accept the operation/operationId (to know which operation was invoked) and an Object[] with the arguments (instead of spreading them).
FYI - a follow up to this will be to add some swagger definition to use AsyncResponse instead of Response, to allow non-blocking handling of requests. This will further change the params.
The text was updated successfully, but these errors were encountered:
We want to use swagger-inflector without individual controllers and individual methods. We want to have a single method that accepts incoming requests from multiple operations (somewhat similarly to what one can do with vertx's swagger-router). Obviously, this can be done manually by using swagger-codegen l:java-inflector and then hooking all methods into some shared code, but we'd rather not have to do it at all (manually or using our own code-gen; in fact, we wouldn't be using java-inflector in our project). Not sure if this is a direction the project is willing to accept; if not, I'll fork this project and possibly only support sinks (which is what I need for my project).
I was thinking of 1) exposing an operation-level vendor extension that describe if this operation is handled by a sink and if so, what controller and method. 2) exposing a swagger-level global that applies to all operations (maybe with an operation-level exception). 3) A sink method will accept the request and return a response, but will also accept the operation/operationId (to know which operation was invoked) and an Object[] with the arguments (instead of spreading them).
FYI - a follow up to this will be to add some swagger definition to use AsyncResponse instead of Response, to allow non-blocking handling of requests. This will further change the params.
The text was updated successfully, but these errors were encountered: