Path parameters

[Tijs-2]

Hi Rob,

I am looking at the generated openapi.json file and I am not sure it is correct.
I think this because a client that I generate from the openapi.json file cannot use the Path Parameters.

If I am correct I need to specify a path parameter like this:
@Get("/animal/:id") public Animal getOne(Long id)

But then it generates a openapi.json file like this:
"paths" : { "/animal/one/:id" : { "get" : { "parameters" : [ { "name" : "id", "in" : "path", "required" : true, "schema" : { "type" : "integer", "format" : "int64" } } ], },
It looks correct but I think that the generated path should look like this: "/animal/one/{id}" when I follow the documentation:
https://swagger.io/docs/specification/describing-parameters/
Also when I look at the client I generated with the dart generator it needs the {} around the parameters.

An example from the generated client is like this:
String path = "/animal/one/:id".replaceAll("{format}","json").replaceAll("{" + "id" + "}", id.toString());

Kind regards,
Tijs

[rbygrave]

the generated path should look like this: "/animal/one/{id}"

Yes, quite right. Note that I think Javalin 4 is probably going to change to the standard form like {id} but we can and should fix this in our openapi generator.

As an FYI note that our master branch has got a big structural change with the push to additionally support Helidon SE. This is not expected to be an issue wrt fixing and releasing but just to note that.

[Tijs-2]

Hi Rob,

I was checking if I could use the new version but I think I broke something in my code.

Not sure yet but I get the following issue: "javax.annotation.processing.FilerException: Attempt to recreate a file for type"

Also and maybe it is related maybe not but if you use the kotlin tile for querybean generation you can set something like
<querybean-generator.version>12.3.7</querybean-generator.version>
But for dinject/javalin generation I dont think you can set something like this?

[rbygrave]

*> I was checking if I could use the new version * What version? There hasn't been a new version of javalin-generator released?

…

On Thu, 23 Jul 2020 at 07:31, Tijs-2 ***@***.***> wrote: Hi Rob, I was checking if I could use the new version but I think I broke something in my code. Not sure yet but I get the following issue: "javax.annotation.processing.FilerException: Attempt to recreate a file for type" Also and maybe it is related maybe not but if you use the kotlin tile for querybean generation you can set something like <querybean-generator.version>12.3.7</querybean-generator.version> But for dinject/javalin generation I dont think you can set something like this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTATLI6AJIGG5KN7AQHELR4447NANCNFSM4PBOAO5Q> .

[Tijs-2]

Ah yes but I tried the master branch, or is that not a working one?

[Tijs-2]

I have it back up and running with the released version, but I am wondering if I can help for a fix for the path issue.
Because I think it must be made in the master version?

[rbygrave]

Master branch should be working but I haven't fully checked the testing coverage which I'm looking to improve. Master should have no functional change (but under the hood is pretty different).

…

On Thu, 23 Jul 2020 at 09:28, Tijs-2 ***@***.***> wrote: I have it back up and running with the released version, but I am wondering if I can help for a fix for the path issue. Because I think it must be made in the master version? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTATOL36MJAWBNZZ6ZKULR45KYTANCNFSM4PBOAO5Q> .

[Tijs-2]

Oeps I should not work when it is better to go to bed :)
Today I easily run it and tried to create a fix with this pull request:
#30

[Tijs-2]

Also maybe an idea for the javalin repo which I am using for my own project since 2 days because I forget to update the versions on other modules a lot of times so they where out of sync etc. This will keep them in sync and create less maintenance on all poms.
But maybe you don't like this method :) and also because I am using it only for a few days now not sure what the downsides are.

I found out that you can use ${revision} to keep the version on all modules the same and share settings that are the same in all the pom files. I added the explanation as a textfile because I could not get the layout readable with all the code.

But if it is not helpfull please ignore me :)

code.txt

[rbygrave]

Thanks. Merged the PR #30. WRT the project/pom setup yes it isn't ideal and thanks for the thoughts. I'll look to try a few things and see if it can be better/simpler and look to try the code.txt revision option - thanks.