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

Subversion repository browsers listed incorrectly

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      The drop-down list for selecting a Subversion repository browser contains the
      following entries:

      (Auto)
      Repository browser
      FishEye
      Repository browser
      Sventon

      The two items labelled "Repository browser" ought to be "WebSVN" and "ViewVC".
      This change happened sometime in the last few weeks (it was OK in previous
      builds). I think the problem appeared around the time that Sventon support was
      added (though I have no evidence to suggest that it was this that caused it).

          [JENKINS-1052] Subversion repository browsers listed incorrectly

          This is nothing to do with adding Sventon support.

          I have checked the commits for Sventon support and the only non-introduced class
          modified is RepositoryBrowsers (which has a diff just adding the reference to
          Sventon

          Stephen Connolly added a comment - This is nothing to do with adding Sventon support. I have checked the commits for Sventon support and the only non-introduced class modified is RepositoryBrowsers (which has a diff just adding the reference to Sventon

          The label comes from the Descriptor.getDisplayName()

          The strange thing is that in each case getDisplayName() is in the source code
          returning the correct value and has not changed!!!

          http://fisheye5.cenqua.com/browse/hudson/hudson/main/core/src/main/java/hudson/scm/browsers/ViewSVN.java?r=1.12
          returns "ViewSVN"

          http://fisheye5.cenqua.com/browse/hudson/hudson/main/core/src/main/java/hudson/scm/browsers/WebSVN.java?r=1.2
          returns "WebSVN"

          Very strange!

          Stephen Connolly added a comment - The label comes from the Descriptor.getDisplayName() The strange thing is that in each case getDisplayName() is in the source code returning the correct value and has not changed!!! http://fisheye5.cenqua.com/browse/hudson/hudson/main/core/src/main/java/hudson/scm/browsers/ViewSVN.java?r=1.12 returns "ViewSVN" http://fisheye5.cenqua.com/browse/hudson/hudson/main/core/src/main/java/hudson/scm/browsers/WebSVN.java?r=1.2 returns "WebSVN" Very strange!

          dwdyer added a comment -

          I've looked through the code and I am absolutely stumped as to what is causing
          it. Other than comments, the string "Repository browser" only appears as the
          title for that section, so I'm not sure how it's getting into the drop-down.

          I didn't think it was anything to do with the Sventon support because I had
          looked at the changes you made and couldn't see anything wrong. But because I
          don't understand what is going on here, I mentioned it anyway because it seemed
          like a coincidence.

          dwdyer added a comment - I've looked through the code and I am absolutely stumped as to what is causing it. Other than comments, the string "Repository browser" only appears as the title for that section, so I'm not sure how it's getting into the drop-down. I didn't think it was anything to do with the Sventon support because I had looked at the changes you made and couldn't see anything wrong. But because I don't understand what is going on here, I mentioned it anyway because it seemed like a coincidence.

          dwdyer added a comment -

          A couple of seemingly related things I noticed:

          In Opera, I get all of the config fields for all of the repository browsers
          displayed (this does not happen in IE7).

          No WebSVN links are inserted into the changes page any more.

          dwdyer added a comment - A couple of seemingly related things I noticed: In Opera, I get all of the config fields for all of the repository browsers displayed (this does not happen in IE7). No WebSVN links are inserted into the changes page any more.

          I know what's going on. See my changes to ViewSVN which fixes this problem for it.

          JEXL doesn't access non-public stuff (presumably for security reasons, so that
          unexpected security holes won't leak critical information), but this is not
          correctly implemented in that it cannot access public methods of non-public
          classes . So as a result, if the Descriptor class is anonymous, it fails to
          access its method, causing the "..." in <dropdownListBlock title="..."/> to be null.

          And when the title is null, when dropdownListBlock.jelly refers to ${title} it
          binds to the nearest title available in scope, which happens to be "Repository
          browser".

          I guess we should probably fix JEXL, though.

          Kohsuke Kawaguchi added a comment - I know what's going on. See my changes to ViewSVN which fixes this problem for it. JEXL doesn't access non-public stuff (presumably for security reasons, so that unexpected security holes won't leak critical information), but this is not correctly implemented in that it cannot access public methods of non-public classes . So as a result, if the Descriptor class is anonymous, it fails to access its method, causing the "..." in <dropdownListBlock title="..."/> to be null. And when the title is null, when dropdownListBlock.jelly refers to ${title} it binds to the nearest title available in scope, which happens to be "Repository browser". I guess we should probably fix JEXL, though.

          Fixed in 1.160 by picking up new JEXL.

          Kohsuke Kawaguchi added a comment - Fixed in 1.160 by picking up new JEXL.

          dwdyer added a comment -

          I can confirm that the drop-down is displaying correctly now. However, the
          Opera issue that I mentioned is still there, so have raised this in a separate
          bug report (issue 1056):

          https://hudson.dev.java.net/issues/show_bug.cgi?id=1056

          dwdyer added a comment - I can confirm that the drop-down is displaying correctly now. However, the Opera issue that I mentioned is still there, so have raised this in a separate bug report (issue 1056): https://hudson.dev.java.net/issues/show_bug.cgi?id=1056

            Unassigned Unassigned
            dwdyer dwdyer
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: