Looking for class="long" is probably a red herring. Judging by the stack trace, I suspect that there is some object with an enum-valued field, which is reading a config.xml with crazy content that would not have worked (perhaps some plugin incompatibly refactored the type of a persistent field) but would normally just be sending something to OldDataMonitor. Still not really sure how this becomes a long specifically.

Is the error reproducible? Then forget about custom core patches and just bisect $JENKINS_HOME until you identify the jobs/**/config.xml responsible, and attach it here.

I've seen a similar warning yesterday after a 2.89.x to 2.107.3 upgrade, on one single Jenkins server (whereas I was upgrading many other similar servers).  On this specific server, there was one "unusual" plugin (compared to the other servers): hockeyapp

Orest Smoleac do you have this plugin installed too?

I will attach an edited config.xml for a job which lead to this warning.  Note the schemaVersion="X" attributes, that's some long numbers in the plugin code:

  <publishers>
    <hockeyapp.HockeyappRecorder schemaVersion="2">
      <applications>
        <hockeyapp.HockeyappApplication plugin="hockeyapp@1.2.1" schemaVersion="1">
[...]

Note that this did not generate old data warnings in the Jenkins GUI, only a warning in jenkins.log.

Also note that this config was generated by plugin version 1.2.1. Version 1.2.2 (latest) claims to include some JEP-200 compliance fixes. From what I've seen, upgrading to 1.2.2 is not, by itself, enough to make this warning disappear (the config.xml is not auto-converted on Jenkins startup). But as soon as I save the job configuration again (from Jenkins GUI), the schemaVersion attributes are removed, or converted to regular child node (with a different value...):

  <publishers>
    <hockeyapp.HockeyappRecorder plugin="hockeyapp@1.2.2">
      <applications>
        <hockeyapp.HockeyappApplication>
          <schemaVersion>0</schemaVersion>
[...]

From there, I get no more warning if I restart the Jenkins server again.
 
Orest Smoleac maybe you could try to grep for similar numeric attributes on you jobs configs? Something like that:

grep -E -R --include=config.xml '^[[:space:]]*<.*="[0-9]+".*>$' ~jenkins/jobs/

Adding Jesse Glick's comment from https://github.com/jenkinsci/jenkins/pull/3446#pullrequestreview-125207559 to this thread:

>

Hold on, there is new information in JIRA. Apparently this code using @XStreamAsAttribute leads to

<hockeyapp.HockeyappApplication plugin="hockeyapp@1.2.1" schemaVersion="1">

> which is a format I have never seen before. If true, that means that we have a lead for writing an actual functional test reproducing the bug. I doubt the proposed fix is actually the right one—rather, BlacklistedTypesConverter.canConvert should be doing the isPrimitive check, or perhaps there is a bug even earlier in XStream somewhere, since the converter is not consulted for the regular child element format (is there a reason that would be autoboxed while attributes are not?).

https://github.com/jenkinsci/jenkins/pull/3446 is generally stuck, I do not plan to work on anything else around this ticket

https://github.com/jenkinsci/jenkins/pull/3446 is blocked by Jesse Glick due to the lack of reproducible scenario. I will close the pull request.

If anybody else hits this issue, please feel free to take over the PR and to get it over the line.