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: In Review (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
    • 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
            oleg_nenashev Oleg Nenashev added a comment -

            All these fields are not related to "long". They come from XCode Plugin 2.0.0 AFAICT.
            So we will need to add more diagnostics for XStream layers in order to triage the failing job, I'd guess.

            Show
            oleg_nenashev Oleg Nenashev added a comment - All these fields are not related to "long". They come from XCode Plugin 2.0.0 AFAICT. So we will need to add more diagnostics for XStream layers in order to triage the failing job, I'd guess.
            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

              People

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

                Dates

                • Created:
                  Updated: