Chris Kilding
unread,Oct 2, 2020, 9:59:36 AM10/2/20Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to jenkin...@googlegroups.com
Hi,
Just today I was looking at adding a new option to a plugin's configuration, and thought that the javax.validation API would be really helpful to apply validation constraints to plugin configuration in a single place.
For example:
@Extension
@Symbol("yourPlugin")
public class PluginConfiguration extends GlobalConfiguration {
// jsr-380 numerical validations like...
@Positive @Max(100)
private int x;
// jsr-380 string validations like...
@Email
private String y;
// jsr-380 also provides @Null/@NotNull; I guess javax.validation is now the standardised API for these annotations, superseding FindBugs annotations etc.
@NotNull
private String z;
}
Without something like javax.validation / JSR-380 I don't think we can specify validation constraints in a single place; at minimum we would end up with duplicated validation logic. If you validate the value in a DataBoundSetter, any code path that bypasses the setter will also bypass validation. If you validate the value at usage time, you can't warn the user when they're on the /configure page (or when Jenkins is reading CasC.yaml). And so on.
I believe this has been talked about before in JEP-205 and JENKINS-11131, and a couple of PRs, but no conclusion was reached.
Could someone familiar with this (perhaps Nicolas) provide more details of how far it got, and what the next step would be? Or indeed what the workarounds are that people use today e.g. for constraining an integer config value to a certain range?
Chris