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

Some Plugin configuration panels shows an Error Hyperlink

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      SunOS10
      Hudson 1.395
      Downstream Ext 1.6
      Join Plugin 1.9
      Parameterized Build 2.4
      Copy From Artifact 1.12
      xUnit 1.13
    • Similar Issues:

      Description

      When selecteing Build Other Projects (Extended) checkbox, the related configuration fields appear. But an "Error" hyperlink is also displayed.
      When clicking on the hyperlink, the following HTTP Error is schown :
      HTTP Status 500 -

      type Exception report

      message

      description The server encountered an internal error () that prevented it from fulfilling this request.

      exception

      javax.servlet.ServletException: The descriptor registry with the called getId() method is not used. The descriptor redefines its own getInputMetric() method.
      org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:597)
      ...etc...

        Attachments

          Activity

          Hide
          kutzi kutzi added a comment -

          The stacktrace points to the xunit plugin as a possible culprit. Maybe you should ask its maintainers if they can see something in it.
          BTW: the stacktrace could be much easier handled, if you could attach it as plain text instead as an image.

          Show
          kutzi kutzi added a comment - The stacktrace points to the xunit plugin as a possible culprit. Maybe you should ask its maintainers if they can see something in it. BTW: the stacktrace could be much easier handled, if you could attach it as plain text instead as an image.
          Hide
          jlpinardon jlpinardon added a comment -

          I have installed the xUnit 1.13 (as in our test instance) on a another instance where the last 1.6version of the Downstream Ext plugin is also installed. There is no Error link at all
          Also, the xUnit 1.13 was installed on the instance on the Linux RedHat virtual machine (see comment above).
          So, I guess that this could clear xUnit culpability.
          Among other possibilities, could there be the java version ?

          Show
          jlpinardon jlpinardon added a comment - I have installed the xUnit 1.13 (as in our test instance) on a another instance where the last 1.6version of the Downstream Ext plugin is also installed. There is no Error link at all Also, the xUnit 1.13 was installed on the instance on the Linux RedHat virtual machine (see comment above). So, I guess that this could clear xUnit culpability. Among other possibilities, could there be the java version ?
          Hide
          kutzi kutzi added a comment -

          >So, I guess that this could clear xUnit culpability.

          No I don't agree. The only hint I currently have, is the xunit line in the stacktrace, so I would continue to research in that direction.

          PS: I don't think that the Java version could be the problem.

          Show
          kutzi kutzi added a comment - >So, I guess that this could clear xUnit culpability. No I don't agree. The only hint I currently have, is the xunit line in the stacktrace, so I would continue to research in that direction. PS: I don't think that the Java version could be the problem.
          Hide
          jlpinardon jlpinardon added a comment -

          As suggested in the comments... should it be a xUnit plugin related problem ?
          Note that I also have this behaviour within the Copy from Artifact configuration panel.
          The corresponding trace is attached as a txt file

          Show
          jlpinardon jlpinardon added a comment - As suggested in the comments... should it be a xUnit plugin related problem ? Note that I also have this behaviour within the Copy from Artifact configuration panel. The corresponding trace is attached as a txt file
          Hide
          gbois Gregory Boissinot added a comment -

          I am the author of the xUnit plugin.
          The issue is relative to the xUnit plugin.
          xUnit 1.13 and previous versions were built for Hudson 1.355.
          xUnit 1.13 is not compatible with Hudson 1.395.
          I suggest you should upgrade to xUnit 1.14 or 1.15, compatible with Hudson 1.395 and built respectively
          for Jenkins 1.396 and Jenkins 1.397.

          Technical reason:
          The error is due to an API changement.
          In my xUnit plugin and its DTkit infrastructure, I use the getId() method except for CustomTypeDescriptor (used for CustomType
          field) where I throw a runtime exception

          Nevertheless, the getId() method is used now in the private method getConfigFile() of the Descriptor class.
          This method is loaded at startup.

          The signature has not changed but the implementation is deeply different

          Previous content
          private XmlFile getConfigFile()

          { return new XmlFile(new File(Hudson.getInstance().getRootDir(),clazz.getName()+".xml")); }

          New content (in 1.395+)
          private XmlFile getConfigFile()

          { return new XmlFile(new File(Hudson.getInstance().getRootDir(),getId()+".xml")); }

          The issue was fixed over xUnit 1.14+

          Show
          gbois Gregory Boissinot added a comment - I am the author of the xUnit plugin. The issue is relative to the xUnit plugin. xUnit 1.13 and previous versions were built for Hudson 1.355. xUnit 1.13 is not compatible with Hudson 1.395. I suggest you should upgrade to xUnit 1.14 or 1.15, compatible with Hudson 1.395 and built respectively for Jenkins 1.396 and Jenkins 1.397. Technical reason: The error is due to an API changement. In my xUnit plugin and its DTkit infrastructure, I use the getId() method except for CustomTypeDescriptor (used for CustomType field) where I throw a runtime exception Nevertheless, the getId() method is used now in the private method getConfigFile() of the Descriptor class. This method is loaded at startup. The signature has not changed but the implementation is deeply different Previous content private XmlFile getConfigFile() { return new XmlFile(new File(Hudson.getInstance().getRootDir(),clazz.getName()+".xml")); } New content (in 1.395+) private XmlFile getConfigFile() { return new XmlFile(new File(Hudson.getInstance().getRootDir(),getId()+".xml")); } The issue was fixed over xUnit 1.14+

            People

            • Assignee:
              gbois Gregory Boissinot
              Reporter:
              jlpinardon jlpinardon
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: