0

I am trying out the java-vertx-web yaml to code generator. The generation process works fine and i get the code in target/generated-sources/openapi/src/gen/java/main/org/openapitools/vertxweb/server/api.

There are files called:

TestApiHandler.java
TestApiImpl.java
TestApi.java

Where in TestApiImpl there is for every route a stub method "NOT IMPLEMENTED", which is expected.

Now I thought the normal process would be to create in my own project files that extend these TestApiImpl files and write my own business logic in there so that they are in source control.

But when I do this there is no way for me to inject those new implemented classes back into the generated server, so that when routes are called not the stub methods are called, but my real implementations.

Overwriting the logic in these generated Impl classes makes no sense to me since this target folder is not in source control and every time I would regenerate my API these files would be overwritten.

What am I missing?

Jonathan R
  • 3,652
  • 3
  • 22
  • 40
  • DISCLAIMER: I'm member of vert.x project team. I'm not familiar to how this generator works, but i suppose one of those classes should be subclassed? Like `TestApiImpl`? Usually what is in `target/generated-sources` should not be touched at all. You can try our official module that supports openapi validation (even though there is yet no code generation) https://github.com/vert-x3/vertx-web/tree/master/vertx-web-openapi – Francesco Guardiani Jun 29 '20 at 08:22
  • Hello thanks for your reply, indeed that is what I though too so I subclassed from TestApiImpl but from that point I did not know how to bring my subclassed-file back into the generated server as business logic. I would think that it is done via dependency injection or something like that, but I did not find a way to achieve that. Thanks for your other sources – Jonathan R Jun 29 '20 at 14:54

1 Answers1

0

Add --ignore-file-override .openapi-generator-ignore flag after you generate the code for the first time.

.openapi-generator-ignore should have something like this

**/*Impl.java

This should prevent the generated code from overriding your business logic.