This changes prevents the improper usage of method without the preliminary supportsMakeDisabled() check.
As an example, Subversion plugin behaves in such way (JENKINS-24341)
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
For example, the following should not cause Run.onLoad itself to fail:
java.lang.NullPointerException
at org.jenkinsci.plugins.workflow.steps.input.InputAction.onLoad(InputAction.java:29)
at hudson.model.Run.onLoad(Run.java:342)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.onLoad(WorkflowRun.java:332)
java.lang.RuntimeException: Unable to copy /…/jobs/…/config.xml
at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewHistoryEntryAndCopyConfig(FileHistoryDao.java:252)
at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewItem(FileHistoryDao.java:238)
at hudson.plugins.jobConfigHistory.JobConfigHistoryJobListener.onCreated(JobConfigHistoryJobListener.java:31)
at hudson.model.listeners.ItemListener.fireOnCreated(ItemListener.java:161)
at jenkins.model.Jenkins.putItem(Jenkins.java:2483)
at …
Caused by: java.io.FileNotFoundException: /…/jobs/…/config.xml (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at hudson.plugins.jobConfigHistory.FileHistoryDao.copyConfigFile(FileHistoryDao.java:178)
at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewHistoryEntryAndCopyConfig(FileHistoryDao.java:250)
... 108 more
java.lang.NullPointerException
at hudson.model.User.idStrategy(User.java:140)
at hudson.model.User.getOrCreate(User.java:373)
at hudson.model.User.get(User.java:366)
at hudson.model.User.get(User.java:331)
at hudson.model.User.get(User.java:441)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.getAuthentication(CpsFlowExecution.java:614)
at org.jenkinsci.plugins.workflow.cps.CpsVmThread.run(CpsVmThread.java:20)
By converting several optionalBlock entries to use inline="true", we convert the submitted JSON from:
"hasPropertyFoo": {
"propertyFoo": "value"
},
which is a somewhat unnatural naming scheme, to:
"hasPropertyFoo": true,
"propertyFoo": "value",
This enables us to use the pattern:
if(json.optBoolean("hasPropertyFoo", json.has("propertyFoo"))) {
...
}
To permit either of the following as JSON blobs, for specifying a value for "propertyFoo":
1) "hasPropertyFoo": true, # What comes through from jelly
"propertyFoo": "value",
2) "propertyFoo": "value",
It also allows any of the following as JSON blobs, for NOT specifying a value for "propertyFoo":
3) "hasPropertyFoo": false, # What comes through from jelly
"propertyFoo": "value",
4) "hasPropertyFoo": false,
5) (nothing specified)
NOTE: The main interest in flexibility in what JSON comes through is in support of: https://wiki.jenkins-ci.org/display/JENKINS/YAML+Project+Plugin, this is also the purpose of the couple renames that are mixed in with this.
NOTE: The discrepancy between inline-optionalBlock and f:entry/f:checkbox is the text alignment, which optionalBlock keeps consistent with other elements (and what is done for these today).
This change shifts the way a number of form elements are accessed when handling AbstractProject's doConfigSubmit from using "req.getParameter(...)" style access to using JSON-style (structured form submission) access through "reg.getSubmittedForm()".
Also sending the exception to the log, which is where plugin developers expect to see it.
(This is also necessary for the exception to be visible say from configRoundtrip in a functional test.
Otherwise you just see a FailingHttpStatusCodeException due to the 400 error code, with no details.)
Might actually suffice to just throw a ServletException wrapping the exception up the chain,
letting Stapler or the container handle it, but this change is more conservative.
Assertions are only for cases where you believe the failure of the condition is impossible.
For cases where external code might mistakenly make an incorrect call, throw an exception.
Kohsuke Kawaguchi