The current implementation of XmlFile.java emits an XML 1.0 header, which breaks things like Move/Copy/Promote if the user has included any characters that are illegal in XML 1.0 (such as Control-XX, etc) in their jobs.
XStream, which is used for serialization/deserialization, deals with XML fragments, and doesn't have an issue reading/writing this non well-formed XML. Changing XmlFile.java so that it creates xml 1.1 here will allow jenkins config files to support these special characters. This also requires updating the underlying XML Pull Parser being used by XStream to something that support XML v1.1
- relates to
-
JENKINS-54146 Job History Plugin 2.18.2 - XML view not working
-
- Resolved
-
-
JENKINS-50358 While downgrading Jenkins version 2.112 to 2.101 getting eror
-
- Resolved
-
-
JENKINS-71139 XStream2 unable to round-trip ASCII NUL in stdout/stderr in junitResult.xml
-
- Closed
-
- links to
mikecirioli, yeah. That's the "workaround" mentioned most places. I was trying to set a good example to some junior employees. But, it seems that XML1.1 is just not widely supported and has even been declared "dead".
I had a look at the code for this change in Jenkins and they are just hard-coding in the version number. So, we are probably pretty safe to just remedy this "hard-coded quirk" with a "hard-coded undo" in our code.
Thanks for attempting to help.
P.S. For people who are not attempting to do what we are doing (backing up configs), there is a JSON API that can be used in place of the XML.