• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core, remoting
    • jenkins 2.28 / remoting 3, centos 6, java 1.8, tomcat 8.6

      1. Enable JNLP4 in the agent settings
      2. Restart jenkins
      -> JNLP4 turns itself off

      I'd like to try out jnlp4 but it keeps turning itself off which is frustrating.

          [JENKINS-39465] JNLP4 Agent preference is not saved

          Ben Hines added a comment -

          Ben Hines added a comment - oleg_nenashev

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - Created https://github.com/jenkinsci/jenkins/pull/2621

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/jenkins/model/Jenkins.java
          test/src/test/java/jenkins/model/JenkinsTest.java
          http://jenkins-ci.org/commit/jenkins/3e2e01717976a1f1221874bfd576429c5c48b8a6
          Log:
          JENKINS-39465 - Fix the AgentProtocol settings persistency handling (#2621)

          • JENKINS-39465 - Tweak processing of enabled and disabled protocols in Jenkins instance

          Due to whatever reason, without a definition of an array recipient field the data goes to the disk in the following way:

          ```
          <enabledAgentProtocol>JNLP3-connect</enabledAgentProtocol>
          <enabledAgentProtocol>JNLP4-connect</enabledAgentProtocol>
          ```

          It is supposed to processed by Implicit array correctly, but it does not actually happen.
          With a fix the data is being stored in another format:

          ```
          <enabledAgentProtocols>
          <string>JNLP3-connect</string>
          <string>JNLP4-connect</string>
          </enabledAgentProtocols>
          ```

          This data now works correctly and gets deserialized correctly. readResolve() just adds a fallback for the case when Implicit array handling starts behaving correctly .

          • JENKINS-39465 - Jenkins#agentProtocols cache must be invalidated when we reload the configuration

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/jenkins/model/Jenkins.java test/src/test/java/jenkins/model/JenkinsTest.java http://jenkins-ci.org/commit/jenkins/3e2e01717976a1f1221874bfd576429c5c48b8a6 Log: JENKINS-39465 - Fix the AgentProtocol settings persistency handling (#2621) JENKINS-39465 - Tweak processing of enabled and disabled protocols in Jenkins instance Due to whatever reason, without a definition of an array recipient field the data goes to the disk in the following way: ``` <enabledAgentProtocol>JNLP3-connect</enabledAgentProtocol> <enabledAgentProtocol>JNLP4-connect</enabledAgentProtocol> ``` It is supposed to processed by Implicit array correctly, but it does not actually happen. With a fix the data is being stored in another format: ``` <enabledAgentProtocols> <string>JNLP3-connect</string> <string>JNLP4-connect</string> </enabledAgentProtocols> ``` This data now works correctly and gets deserialized correctly. readResolve() just adds a fallback for the case when Implicit array handling starts behaving correctly . JENKINS-39465 - Add configuration roundtrip tests JENKINS-39465 - Jenkins#agentProtocols cache must be invalidated when we reload the configuration JENKINS-39465 - Remove obsolete comment from Tests

          Oleg Nenashev added a comment -

          The fix has been integrated towards 2.30

          Oleg Nenashev added a comment - The fix has been integrated towards 2.30

          Oleg Nenashev added a comment -

          The issue has been introduced in 2.16, so I've marked it as a backporting candidate for 2.19.3.
          Maybe too late, CC olivergondza

          Oleg Nenashev added a comment - The issue has been introduced in 2.16, so I've marked it as a backporting candidate for 2.19.3. Maybe too late, CC olivergondza

          It seem reasonably safe and as I understand it prevent users to upgrade to JNLP4. Let's to it.

          Oliver Gondža added a comment - It seem reasonably safe and as I understand it prevent users to upgrade to JNLP4. Let's to it.

          Oleg Nenashev added a comment - - edited

          JNLP4 is not available in 2.19.x LTS, but there are other use-case:

          • Disable CLI-connect-1 (security-paranoid)
          • Enable JNLP3 on the instance (though I would not recommend it)
          • Enabling/disabling custom protocol implementations

          Oleg Nenashev added a comment - - edited JNLP4 is not available in 2.19.x LTS, but there are other use-case: Disable CLI-connect-1 (security-paranoid) Enable JNLP3 on the instance (though I would not recommend it) Enabling/disabling custom protocol implementations

            oleg_nenashev Oleg Nenashev
            benh57 Ben Hines
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: