* 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
That file will avoid users to file PR with wrong newline encoding.
I've tried to declare what seemed to be the most common extensions. It's
not strictly required, since the first line and the Git integrated
heurisitics would work just fine in general. But we're just adding a bit
more info here to lower chances to screw up.
Kohsuke Kawaguchi