Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-51326

JEP-200 long data type rejected after upgrade to 2.107.3

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Environment:
    • Similar Issues:

      Description

      Trying to install Jenkins 2.107.3 and when i apply config and jobs from backup (Jenkins 2.89.3). All plugins are up to date. 

      Because of below warning we cannot proceed with higher environments since may affect multiple jobs:

      May 14, 2018 11:59:15 AM jenkins.security.ClassFilterImpl lambda$isBlacklisted$1
      WARNING: long in JRE might be dangerous, so rejecting; see https://jenkins.io/redirect/class-filter/

       

       

        Attachments

        1. config.xml
          1 kB
        2. config.xml
          5 kB
        3. jenkins.log
          6 kB

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            tom_gl Thomas de Grenier de Latour added a comment - - edited

            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/
            
            Show
            tom_gl Thomas de Grenier de Latour added a comment - - edited 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/
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            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?).

            Show
            oleg_nenashev Oleg Nenashev added a comment - 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?).
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

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

            Show
            oleg_nenashev Oleg Nenashev added a comment - https://github.com/jenkinsci/jenkins/pull/3446  is generally stuck, I do not plan to work on anything else around this ticket
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            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.

             

            Show
            oleg_nenashev Oleg Nenashev added a comment - 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.  

              People

              • Assignee:
                Unassigned
                Reporter:
                sorests Orest Smoleac
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: