Naming of @Selector params for custom Actuator endpoints requires class file method parameter embedding

[shabino]

Edit: This is based on testing against 2.0.0.M6.

Names of Actuator endpoint @Selector parameters are set based on their associated method parameter names. For this to work properly, endpoint classes must be compiled with these parameter names embedded (-parameters javac param, <parameters>true</parameters> in Maven, etc.). This happens by default if one's Spring Boot Maven project is defined with spring-boot-starter-parent as its parent. But, if one isn't using this Maven configuration, @Selector params end-up with names like arg0, and the cause is non-obvious.

Please consider:

1. Noting in the documentation for custom Actuator endpoints that embedded parameter names are required for custom naming.

2. Adding a name parameter to @Selector that allows one to explicitly specify/override the parameter name.

Note that I haven't looked into whether a default Gradle, etc. Spring Boot set-up results in compilation with embedded parameter names.

Also, even if one has his POM configured to compile with embedded parameter names, separate IDE configuration likely is required to turn this on when allowing an IDE to compile instead:

https://stackoverflow.com/questions/39217830/how-to-use-parameters-javac-option-in-intellij

[snicoll]

@selector params end-up with names like arg0, and the cause is non-obvious.

That's not the case anymore. You'll get an exception instead now. We still need to finalize the documentation of that infrastructure so we'll take that into account.

That name offer is a bit more complicated than that: we want to ease the programming model and anything that's not a @Selector is a request parameter (for GET) or an attribute of the body. Relying on parameter names is quite handy in that situation.

[shabino]

An actionable error message ought to be good enough. And, having the ability to specify request params would be great. I ended up creating two top-level endpoints as a workaround. In my usecase, I have Foo objects that can be looked-up by two different kinds of keys.

[snicoll]

Duplicates #10001