What I'm doing in my plug-ins is to add a readResolve block that handles files written with old versions of a plugin. However, sometimes I just forget that I need to write that part of the code... And if you don't have unit tests that test the serialization then boom ;-)
So it would be really a enhancement if we could spot such problems earlier. But I'm not sure if that is possible at all. At least we can add a check for final fields and the absence of the corresponding tag in the serialized XML during XStream processing and issue a warning. But sometimes this is a problem for non-final fields, too. Ulli On 07/16/2012 08:59 PM, Jesse Glick wrote: > I noticed that if you have the Subversion plugin installed and a > jobs/*/builds/*/build.xml contains > > <hudson.scm.SubversionTagAction> > <build class="build" reference="../../.."/> > </hudson.scm.SubversionTagAction> > > then whenever you visit the job page you get > > <time...> hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: it.isTagged(). Reason: > java.lang.NullPointerException > java.lang.NullPointerException > at > hudson.scm.SubversionTagAction.isTagged(SubversionTagAction.java:158) > ... > > and this is thrown on every reload of the page, which can quickly fill > up the log. (Thrown from SubversionTagAction/tagForm.jelly.) > > Now clearly the build data is invalid - SubversionTagAction includes a > 'tags' field which is missing in the serialized XML. How this invalid > XML got written to begin with is another question, but for now I am > wondering how Jenkins is supposed to recover. When build.xml contains > unrecognized sections, the loading of the build is skipped, the > console shows the problem once during Jenkins startup, and the /manage > page shows a link to try to save corrected configuration by deleting > unrecognized sections - all reasonably friendly. > > But apparently a missing field in an Action does not trigger the > "something broken" logic. Is SubversionTagAction supposed to override > readResolve to ensure that 'tags' is defined to something non-null? > (or throw an exception if it is not?) Or is XStream supposed to notice > that there is no stored value for this final field and throw an > exception eagerly while loading build.xml? In other words, what is the > general policy for detecting and addressing problems caused by > incomplete or malformed stored XML?
