* Load i18n resource bundles from plugins if not found in jenkins core
Signed-off-by: Thorsten Scherler <scherler@gmail.com>
* Issue 404 response for missing i18n resource bundles
Currently issues a 200 with an "error" response payload. This change still issues the error response payload, but also sets the HTTP response.
Signed-off-by: Thorsten Scherler <scherler@gmail.com>
* [JENKINS-35845] Fix test since we return now a 404
* [JENKINS-35845] add test for getting locale from plugin. fix comments from oleg.
* [JENKINS-35845] Fix description
* [JENKINS-35845] Update PR with comments from Oleg
* [JENKINS-35845] Add feedback from tom
* eslint - formating changes and fix offences
* eslint - formating changes and fix offences
* [JENKINS-35845] remove code concerning 404 response. Fix resourceBundle test by prevent NPE to happen
* [JENKINS-35845] Link to issue on which we introduced the test
* [JENKINS-36871] Switch to the new JnlpProtocolHandler based implementation
Todo
- [ ] Restore the cookie behaviour (but done right this time)
- [ ] Perhaps investigate issuing clients with TLS certificates (but would require a UI for managing them)
* [JENKINS-36871] License headers and javadocs
* [JENKINS-36871] Restore cookie handling
* [JENKINS-36871] Integrating Agent discovery components
* [JENKINS-36871] Pick up remoting 3.0-SNAPSHOT
* [JENKINS-36871] Pick up newer snapshot
* [JENKINS-36871] Oleg wants to log an exception that cannot happen
* [FIXED JENKINS-38650] - Cleanup spelling in CLi commands.
Also adds some javadoc and since definitions.
* [JENKINS-38650] - Move common warning message to the constant
* [JENKINS-38650] - DeleteViewCommand should also use the constant string
* [JENKINS-38650] - Rename the constant in order to make the name more explicit
* [JENKINS-38678] Remove properly administrative monitor
previous impl didn't work because ExtensionList#iterator() returns a
readonly iterator.
* Use foreach loop
* Update XStream drive to improve performance in xml serilization/deserialization
According XStream FAQ (http://x-stream.github.io/faq.html#Scalability):
XStream is a generalizing library, it inspects and handles your types on
the fly. Therefore it will normally be slower than a piece of optimized
Java code generated out of a schema. However, it is possible to increase
the performance anyway:
* Write custom converters for those of your types that occur very often in
your XML.
* Keep a configured XStream instance for multiple usage. Creation and
initialization is quite expensive compared to the overhead of XStream
when calling marshall or unmarshal.
* Use Xpp3 or StAX parsers.
So, I decided to move from old Xpp to new Xpp3.
* Change other occurance of XppDriver to Xpp3Driver as well
* [FIXED JENKINS-38473] Set a short timeout on the socket when using it to wake the acceptor thread.
* [JENKINS-38473] Remove leftover typing in wrong window
Kohsuke Kawaguchi