Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0
    • Component/s: web gui
    • Labels:
      None

      Description

      Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, it should function well in most cases. I propose that, as soon as 5.3 has been released, we make the Angular UI default, ready for the 5.4 release. We can then fix any more bugs as they are found, but more importantly start working on the features that were the reason for doing this work in the first place.

      1. new ui link.png
        23 kB
        Upayavira
      2. original UI link.png
        23 kB
        Upayavira
      3. SOLR-7858.patch
        2 kB
        Upayavira
      4. SOLR-7858-2.patch
        2 kB
        Upayavira
      5. SOLR-7858-3.patch
        8 kB
        Upayavira
      6. SOLR-7858-4.patch
        0.5 kB
        Upayavira
      7. SOLR-7858-fix.patch
        1 kB
        Shalin Shekhar Mangar

        Issue Links

          Activity

          Hide
          Upayavira added a comment -

          patch that adds simple links to old/new UI.

          Show
          Upayavira added a comment - patch that adds simple links to old/new UI.
          Hide
          Upayavira added a comment -

          I'm pretty much ready to switch to the Angular UI for 5.4. With the attached patch, I'll add links between the old and new UIs in case people find issues in the new one. I've added an information link that will, I'm planning, link to a wiki page (not confluence) describing the change between them, asking for people to report issues in the new one.

          I am also planning that SOLR-4388 be completed for 5.4, at least a first pass.

          I'd appreciate a few votes for this ticket - to tell me that some people have actually played with the new UI rather than just liking the idea!!

          Show
          Upayavira added a comment - I'm pretty much ready to switch to the Angular UI for 5.4. With the attached patch, I'll add links between the old and new UIs in case people find issues in the new one. I've added an information link that will, I'm planning, link to a wiki page (not confluence) describing the change between them, asking for people to report issues in the new one. I am also planning that SOLR-4388 be completed for 5.4, at least a first pass. I'd appreciate a few votes for this ticket - to tell me that some people have actually played with the new UI rather than just liking the idea!!
          Hide
          ASF subversion and git services added a comment -

          Commit 1703801 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1703801 ]

          SOLR-7858 Add links between old and new UI

          Show
          ASF subversion and git services added a comment - Commit 1703801 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1703801 ] SOLR-7858 Add links between old and new UI
          Hide
          ASF subversion and git services added a comment -

          Commit 1703802 from Upayavira in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1703802 ]

          SOLR-7858 Add links between old and new UI

          Show
          ASF subversion and git services added a comment - Commit 1703802 from Upayavira in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1703802 ] SOLR-7858 Add links between old and new UI
          Hide
          ASF subversion and git services added a comment -

          Commit 1704193 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1704193 ]

          SOLR-7858 Fix info link to point to newly created wiki page

          Show
          ASF subversion and git services added a comment - Commit 1704193 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1704193 ] SOLR-7858 Fix info link to point to newly created wiki page
          Hide
          ASF subversion and git services added a comment -

          Commit 1704194 from Upayavira in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1704194 ]

          SOLR-7858 Fix info link to point to newly created wiki page

          Show
          ASF subversion and git services added a comment - Commit 1704194 from Upayavira in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1704194 ] SOLR-7858 Fix info link to point to newly created wiki page
          Hide
          Upayavira added a comment -

          Chris Hostetter (Unused) I recall you had suggestions as to how we go about releasing the new UI, but I haven't been able to track them down. Are you able to repeat them here? (in terms of which URLs are used, and for what).

          My proposal would be to leave the current UI as index.html, and have /solr/ point at it, and then move admin.html to original.html, such that /solr/original.html will point to the old UI.

          Show
          Upayavira added a comment - Chris Hostetter (Unused) I recall you had suggestions as to how we go about releasing the new UI, but I haven't been able to track them down. Are you able to repeat them here? (in terms of which URLs are used, and for what). My proposal would be to leave the current UI as index.html, and have /solr/ point at it, and then move admin.html to original.html, such that /solr/original.html will point to the old UI.
          Hide
          Shawn Heisey added a comment -

          I would like to have the URL seen in the browser include something to make it obvious that it's the admin UI, so users are not tempted to grab the URL in their browser (containing the # character) and use it as a base URL for a client program. The number of times that I've seen this on the mailing list and the IRC channel is an indication that the users are being easily confused.

          Having something like "admin#" or "admin/#/" (whatever makes sense for the code) in the URL would likely eliminate that confusion for most people. Even "index.html" in the URL (which the new UI has now) would be helpful, but using the word "admin" in some way would be better.

          Show
          Shawn Heisey added a comment - I would like to have the URL seen in the browser include something to make it obvious that it's the admin UI, so users are not tempted to grab the URL in their browser (containing the # character) and use it as a base URL for a client program. The number of times that I've seen this on the mailing list and the IRC channel is an indication that the users are being easily confused. Having something like "admin#" or "admin/#/" (whatever makes sense for the code) in the URL would likely eliminate that confusion for most people. Even "index.html" in the URL (which the new UI has now) would be helpful, but using the word "admin" in some way would be better.
          Hide
          Hoss Man added a comment -

          Chris Hostetter I recall you had suggestions as to how we go about releasing the new UI, but I haven't been able to track them down. ...

          http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301121010.19000@frisbee%3E

          My suggestion, along the lines of what we did with the previous UI
          change...

          1) ensure that the new UI is fully functional in 5x using an alt path
          (believe this is already true?)

          2) add an "Upgrading" note to CHANGES.txt for 5.2 directing people to
          the new "experimental" UI and the URL to access it, note that it
          will likely become the default in 5.3 and users are encouraged to try it
          out and file bugs if they notice any problems.

          3) update trunk so that it is the default UI, and make the old UI
          available at some alternate path (eg "/solr/old_ui"). Add an Upgrading
          note pointing out that the URLs may be slightly different, and how to
          access the old UI if they have problems

          • backport trunk changes (#3) to 5x for 5.3 (or later if problems/delays
            pop up)

          And: http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301414460.19000@frisbee%3E

          ...
          We might want to tweak those URLs slightly to be a little less confusing
          ... ie "old.html" and "new.html" (at least until after 5.3) ... i mean, i
          just the paragraph you rwote above, but w/o looking at it i've already
          forgoten if "index.html" is hte new one or hte old one.

          So imagine if a 5.2 user has in their browser...

          http://localhost:8983/solr/admin.html#/collection1

          ...and is trying to remember if this is the new one (that they should get
          use to / help test) or the fuly qualified name of the old one that is
          going away.

          Likewise imagine if a 5.42 user sees the same URL, and reads a note that
          the "old UI" is going to be removed in 6.0 and is trying to figure out if
          that affects him.

          A few followup comments...

          a) that "step 3" above (changing hte defualt on trunk first) is really important ... you want that change to sit on trunk for a good while, so that devs working on trunk and manually testing things are using the new UI anytime they run stuff on trunk, and helping to find problems – even if no users "try" the new UI in the released versions of Solr

          b) not sure why i didn't mention it before, but adding a generic header to all of the "old" UI pages warning people that they are using the old UI and here is a link to the new UI is something that should definitely be added once the default is changed (it could be added even before the default is changed with ome wording tweaks: "Please try the new UI.." vs "You are looking at the old deprecated UI, please switch to....") to help reduce the # of bug reports / feature requests we get about the old UI and to reduce user frustration (ie; they see in some future release notes that there is a new collection admin screen, but they can't find it when they load "the admin UI" bookmark they have.)


          Having something like "admin#" or "admin/#/" (whatever makes sense for the code) in the URL would likely eliminate that confusion for most people. Even "index.html" in the URL (which the new UI has now) would be helpful, but using the word "admin" in some way would be better.

          In the long term, I don't know if this is will actually help things or decrease novice user confusion (the URLs, when loaded in a browser, is already clearly a UI, will making the UI urls longer really help people notice "oh hey, maybe this UI based URL isn't a URL that programtic client code should talk to" ?) but if this approach is taken it should be very carefully considered in terms of how it impacts "reserved words" for things like collection names.

          It's annoying enough if we (in the short term) have reserved paths like "/old.ui.html" but if you try to use "/admin" as a prefix to indicate that it's for the UI, you'll probably break things like /admin/cores and /admin/collections – let alone the long term impacts of saying something like "You can't have a collection named 'ui' because of the '/ui'." etc...

          Show
          Hoss Man added a comment - Chris Hostetter I recall you had suggestions as to how we go about releasing the new UI, but I haven't been able to track them down. ... http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301121010.19000@frisbee%3E My suggestion, along the lines of what we did with the previous UI change... 1) ensure that the new UI is fully functional in 5x using an alt path (believe this is already true?) 2) add an "Upgrading" note to CHANGES.txt for 5.2 directing people to the new "experimental" UI and the URL to access it, note that it will likely become the default in 5.3 and users are encouraged to try it out and file bugs if they notice any problems. 3) update trunk so that it is the default UI, and make the old UI available at some alternate path (eg "/solr/old_ui"). Add an Upgrading note pointing out that the URLs may be slightly different, and how to access the old UI if they have problems backport trunk changes (#3) to 5x for 5.3 (or later if problems/delays pop up) And: http://mail-archives.apache.org/mod_mbox/lucene-dev/201504.mbox/%3Calpine.DEB.2.02.1504301414460.19000@frisbee%3E ... We might want to tweak those URLs slightly to be a little less confusing ... ie "old.html" and "new.html" (at least until after 5.3) ... i mean, i just the paragraph you rwote above, but w/o looking at it i've already forgoten if "index.html" is hte new one or hte old one. So imagine if a 5.2 user has in their browser... http://localhost:8983/solr/admin.html#/collection1 ...and is trying to remember if this is the new one (that they should get use to / help test) or the fuly qualified name of the old one that is going away. Likewise imagine if a 5.42 user sees the same URL, and reads a note that the "old UI" is going to be removed in 6.0 and is trying to figure out if that affects him. A few followup comments... a) that "step 3" above (changing hte defualt on trunk first) is really important ... you want that change to sit on trunk for a good while, so that devs working on trunk and manually testing things are using the new UI anytime they run stuff on trunk, and helping to find problems – even if no users "try" the new UI in the released versions of Solr b) not sure why i didn't mention it before, but adding a generic header to all of the "old" UI pages warning people that they are using the old UI and here is a link to the new UI is something that should definitely be added once the default is changed (it could be added even before the default is changed with ome wording tweaks: "Please try the new UI.." vs "You are looking at the old deprecated UI, please switch to....") to help reduce the # of bug reports / feature requests we get about the old UI and to reduce user frustration (ie; they see in some future release notes that there is a new collection admin screen, but they can't find it when they load "the admin UI" bookmark they have.) Having something like "admin#" or "admin/#/" (whatever makes sense for the code) in the URL would likely eliminate that confusion for most people. Even "index.html" in the URL (which the new UI has now) would be helpful, but using the word "admin" in some way would be better. In the long term, I don't know if this is will actually help things or decrease novice user confusion (the URLs, when loaded in a browser, is already clearly a UI, will making the UI urls longer really help people notice "oh hey, maybe this UI based URL isn't a URL that programtic client code should talk to" ?) but if this approach is taken it should be very carefully considered in terms of how it impacts "reserved words" for things like collection names. It's annoying enough if we (in the short term) have reserved paths like "/old.ui.html" but if you try to use "/admin" as a prefix to indicate that it's for the UI, you'll probably break things like /admin/cores and /admin/collections – let alone the long term impacts of saying something like "You can't have a collection named 'ui' because of the '/ui'." etc...
          Hide
          Upayavira added a comment -

          Thanks Chris Hostetter (Unused) for your rich perspective.

          Firstly, to answer your question: yes, the new UI has been in trunk/5x since 5.2. As to whether it has been functional, there are a lot less bugs than there were, although you are right to observe that it needs usage.

          = o =
          URLs:

          In your comments you were concerned about how a user would be able to find out which UI they are using and what the purpose of the change is. I've added links at the top right of the old, and new UIs to switch between them, and a link that points to a wiki page explaining further. I hope this does sufficient in terms of messaging - although your suggestion of a banner saying "this is the old UI, go try the new one-->" seems like a good idea.

          Personally, I'd support a redirect from http://localhost:8983/ and http://localhost:8983/solr/ to http://localhost:8983/solr/admin/ and host the entire UI there. You mention the risk of URL overlap, but we already have that issue, in more dangerous ways, with files in the UI using the URL space that end-users access. At least if we switched to /admin/, we would only be in conflict with ourselves, in which case it is infinitely more manageable. And, it is already pretty much a given that 'admin' wouldn't work as a collection name.

          I would, however, suggest we keep this for trunk/6.0. As a code change, it is small. As a usability one, it is much bigger.

          = o =

          Based upon your suggestions, my release proposal and schedule would be:

          • 5x already has links between old/new UIs so users of 5.4 will be able to get to the new one easily
          • There is also a ? link that points to a wiki page explaining the change and asking for bug reports
          • Add a banner saying "go try the new UI" on the old one, both in trunk and 5x
          • Change URLs in trunk straight away so that the new UI is the default (old one as /original-ui.html)
          • Add a note in CHANGES.txt for 5.4 stating clearly that it will become default in 5.5.
          • Assuming no major clangers, for 5.5, change the URLs to make the new default (old one is /original-ui.html)
          • For trunk, change the UI to serve from /admin/. Files remain in the same location.
          Show
          Upayavira added a comment - Thanks Chris Hostetter (Unused) for your rich perspective. Firstly, to answer your question: yes, the new UI has been in trunk/5x since 5.2. As to whether it has been functional, there are a lot less bugs than there were, although you are right to observe that it needs usage. = o = URLs: In your comments you were concerned about how a user would be able to find out which UI they are using and what the purpose of the change is. I've added links at the top right of the old, and new UIs to switch between them, and a link that points to a wiki page explaining further. I hope this does sufficient in terms of messaging - although your suggestion of a banner saying "this is the old UI, go try the new one-->" seems like a good idea. Personally, I'd support a redirect from http://localhost:8983/ and http://localhost:8983/solr/ to http://localhost:8983/solr/admin/ and host the entire UI there. You mention the risk of URL overlap, but we already have that issue, in more dangerous ways, with files in the UI using the URL space that end-users access. At least if we switched to /admin/, we would only be in conflict with ourselves, in which case it is infinitely more manageable. And, it is already pretty much a given that 'admin' wouldn't work as a collection name. I would, however, suggest we keep this for trunk/6.0. As a code change, it is small. As a usability one, it is much bigger. = o = Based upon your suggestions, my release proposal and schedule would be: 5x already has links between old/new UIs so users of 5.4 will be able to get to the new one easily There is also a ? link that points to a wiki page explaining the change and asking for bug reports Add a banner saying "go try the new UI" on the old one, both in trunk and 5x Change URLs in trunk straight away so that the new UI is the default (old one as /original-ui.html) Add a note in CHANGES.txt for 5.4 stating clearly that it will become default in 5.5. Assuming no major clangers, for 5.5, change the URLs to make the new default (old one is /original-ui.html) For trunk, change the UI to serve from /admin/. Files remain in the same location.
          Hide
          Noble Paul added a comment -

          As we plan to move to V2 API in 6.0 we plan to not restrict a collection name other that the well known ones (_cluster, _node etc ) . The UI is something that could live in a special dir such as /solr/_admin/index.html or /solr/_ui/index.html. All the other files also must move out of the top level . For instance, js , css and images also move under the path /solr/_admin/ or /solr/_ui/

          We should make these changes in 5x itself and keep redirect rules for old-> new. In 6.0 we should get rid of the rules as well

          Show
          Noble Paul added a comment - As we plan to move to V2 API in 6.0 we plan to not restrict a collection name other that the well known ones ( _cluster , _node etc ) . The UI is something that could live in a special dir such as /solr/_admin/index.html or /solr/_ui/index.html . All the other files also must move out of the top level . For instance, js , css and images also move under the path /solr/_admin/ or /solr/_ui/ We should make these changes in 5x itself and keep redirect rules for old-> new. In 6.0 we should get rid of the rules as well
          Hide
          Upayavira added a comment -

          @noble.paul I am unsure who the "we" is you are referring to. As I understand it, you and one other have had a private discussion and on the basis of that some public discussion has occurred, without a conclusion as yet. That doesn't, to me, constitute a community wide agreement that the URL structure will be changing according to your proposal, does it?

          Your suggestion is not that different to what I have already proposed - that everything (css/etc too) live under /admin, along with the admin APIs. The only URL we need to keep consistent is the /solr/ one, which must redirect somewhere sensible, which could be _admin/ or _ui/ or whatever.

          Show
          Upayavira added a comment - @noble.paul I am unsure who the "we" is you are referring to. As I understand it, you and one other have had a private discussion and on the basis of that some public discussion has occurred, without a conclusion as yet. That doesn't, to me, constitute a community wide agreement that the URL structure will be changing according to your proposal, does it? Your suggestion is not that different to what I have already proposed - that everything (css/etc too) live under /admin, along with the admin APIs. The only URL we need to keep consistent is the /solr/ one, which must redirect somewhere sensible, which could be _admin/ or _ui/ or whatever.
          Hide
          Noble Paul added a comment -

          I am unsure who the "we" is you are referring to.

          "we" means Solr project. If a feature is built and committed, it is a part of the project.

          As I understand it, you and one other have had a private discussion and on the basis of that some public discussion has occurred, without a conclusion as yet.

          Aren't all features built like that? . one developer coming up with a suggestion and then the interested developers would comment/vote on the idea.

          That doesn't, to me, constitute a community wide agreement that the URL structure will be changing according to your proposal, does it?

          The proposal was for v2 APIs . The idea is to have fewer top level names that could conflict with collection names.

          What do you mean when you say community wide agreement? I don't think any feature gets all people to vote for it.

          Your suggestion is not that different to what I have already proposed - that everything (css/etc too) live under /admin, along with the admin APIs.

          Yes, we are not suggesting very different things. The reason I prepended an underscore is to avoid conflicts with real collection names. In that aspect /_admin/ is better than admin .

          Show
          Noble Paul added a comment - I am unsure who the "we" is you are referring to. "we" means Solr project. If a feature is built and committed, it is a part of the project. As I understand it, you and one other have had a private discussion and on the basis of that some public discussion has occurred, without a conclusion as yet. Aren't all features built like that? . one developer coming up with a suggestion and then the interested developers would comment/vote on the idea. That doesn't, to me, constitute a community wide agreement that the URL structure will be changing according to your proposal, does it? The proposal was for v2 APIs . The idea is to have fewer top level names that could conflict with collection names. What do you mean when you say community wide agreement? I don't think any feature gets all people to vote for it. Your suggestion is not that different to what I have already proposed - that everything (css/etc too) live under /admin, along with the admin APIs. Yes, we are not suggesting very different things. The reason I prepended an underscore is to avoid conflicts with real collection names. In that aspect /_admin/ is better than admin .
          Hide
          ASF subversion and git services added a comment -

          Commit 1707269 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1707269 ]

          SOLR-4388 SOLR-7858 SOLR-7666 update CHANGES.txt

          Show
          ASF subversion and git services added a comment - Commit 1707269 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1707269 ] SOLR-4388 SOLR-7858 SOLR-7666 update CHANGES.txt
          Hide
          ASF subversion and git services added a comment -

          Commit 1707270 from Upayavira in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1707270 ]

          SOLR-4388 SOLR-7858 SOLR-7666 update CHANGES.txt

          Show
          ASF subversion and git services added a comment - Commit 1707270 from Upayavira in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1707270 ] SOLR-4388 SOLR-7858 SOLR-7666 update CHANGES.txt
          Hide
          Upayavira added a comment -

          Today, whilst giving a private demo of the UI, I spotted some major bugs - for example, the facet/spellcheck/highlighting options on the query pane didn't work.

          This is the sort of thing that needs to be tracked down and found before we switch the new UI to the default, as it will severely impact on user experience if we don't.

          Show
          Upayavira added a comment - Today, whilst giving a private demo of the UI, I spotted some major bugs - for example, the facet/spellcheck/highlighting options on the query pane didn't work. This is the sort of thing that needs to be tracked down and found before we switch the new UI to the default, as it will severely impact on user experience if we don't.
          Hide
          Mark Miller added a comment -

          Upayavira, is there a spot that talks about the param we discussed in these comments I'm missing?

          Any chance we can create a JIRA issue just for that task and I'll jump on it?

          Show
          Mark Miller added a comment - Upayavira , is there a spot that talks about the param we discussed in these comments I'm missing? Any chance we can create a JIRA issue just for that task and I'll jump on it?
          Hide
          Upayavira added a comment -

          Mark Miller the ticket is here: SOLR-8074

          Show
          Upayavira added a comment - Mark Miller the ticket is here: SOLR-8074
          Hide
          Upayavira added a comment -

          Patch that adds this "warning" message to the top of the new UI, so as to distinguish it more clearly from the original one:

          "This is an experimental UI. Report bugs here. For the old UI click here"

          Show
          Upayavira added a comment - Patch that adds this "warning" message to the top of the new UI, so as to distinguish it more clearly from the original one: "This is an experimental UI. Report bugs here . For the old UI click here "
          Hide
          Upayavira added a comment -

          correct "warning" patch

          Show
          Upayavira added a comment - correct "warning" patch
          Hide
          ASF subversion and git services added a comment -

          Commit 1710300 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1710300 ]

          SOLR-7858 Add a warning message to the angular UI

          Show
          ASF subversion and git services added a comment - Commit 1710300 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1710300 ] SOLR-7858 Add a warning message to the angular UI
          Hide
          ASF subversion and git services added a comment -

          Commit 1710301 from Upayavira in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1710301 ]

          SOLR-7858 Add a warning message to the angular UI

          Show
          ASF subversion and git services added a comment - Commit 1710301 from Upayavira in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1710301 ] SOLR-7858 Add a warning message to the angular UI
          Hide
          Upayavira added a comment -

          Patch that makes angular UI default in trunk.

          Before committing, another is needed that uses LoadAdminUIServlet to load index.html in 5.x, but doesn't (yet) make it the default.

          Show
          Upayavira added a comment - Patch that makes angular UI default in trunk. Before committing, another is needed that uses LoadAdminUIServlet to load index.html in 5.x, but doesn't (yet) make it the default.
          Hide
          Upayavira added a comment -

          Patch to make index.html use LoadAdminUIServlet. This gets it $

          {version}

          replacement and protection against click-jacking.

          Show
          Upayavira added a comment - Patch to make index.html use LoadAdminUIServlet. This gets it $ {version} replacement and protection against click-jacking.
          Hide
          ASF subversion and git services added a comment -

          Commit 1710303 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1710303 ]

          SOLR-7858 Make Angular UI default in trunk

          Show
          ASF subversion and git services added a comment - Commit 1710303 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1710303 ] SOLR-7858 Make Angular UI default in trunk
          Hide
          ASF subversion and git services added a comment -

          Commit 1710304 from Upayavira in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1710304 ]

          SOLR-7858 Switch index.html to use LoadAdminUIServlet on 5x branch

          Show
          ASF subversion and git services added a comment - Commit 1710304 from Upayavira in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1710304 ] SOLR-7858 Switch index.html to use LoadAdminUIServlet on 5x branch
          Hide
          Shalin Shekhar Mangar added a comment -

          The last commit has broken JettyWebappTest which fails 100% of the times with the following:

          Stack Trace:
          java.lang.NullPointerException
                  at __randomizedtesting.SeedInfo.seed([BF1D2DE333F380A3:87CFCEB054981B1C]:0)
                  at org.apache.solr.client.solrj.embedded.JettyWebappTest.testAdminUI(JettyWebappTest.java:115)
          

          I believe the attached patch should fix this but I don't know enough about this piece so a review is welcome.

          In future, please be more careful before committing stuff (and be around to watch jenkins for a while!)

          Show
          Shalin Shekhar Mangar added a comment - The last commit has broken JettyWebappTest which fails 100% of the times with the following: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([BF1D2DE333F380A3:87CFCEB054981B1C]:0) at org.apache.solr.client.solrj.embedded.JettyWebappTest.testAdminUI(JettyWebappTest.java:115) I believe the attached patch should fix this but I don't know enough about this piece so a review is welcome. In future, please be more careful before committing stuff (and be around to watch jenkins for a while!)
          Hide
          ASF subversion and git services added a comment -

          Commit 1710333 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1710333 ]

          SOLR-7858 Add web.xml changes

          Show
          ASF subversion and git services added a comment - Commit 1710333 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1710333 ] SOLR-7858 Add web.xml changes
          Hide
          Upayavira added a comment -

          More care needed from me.

          Firstly, I failed to commit changes to web.xml that were needed, which broke the build.

          Then, to fix it, I inadvertently committed changes that aren't ready, along with the web.xml change.

          At least the build is fixed. I will revert the remaining changes soon, and commit them against the correct ticket.

          Show
          Upayavira added a comment - More care needed from me. Firstly, I failed to commit changes to web.xml that were needed, which broke the build. Then, to fix it, I inadvertently committed changes that aren't ready, along with the web.xml change. At least the build is fixed. I will revert the remaining changes soon, and commit them against the correct ticket.
          Hide
          ASF subversion and git services added a comment -

          Commit 1710356 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1710356 ]

          SOLR-7858 revert premature commit

          Show
          ASF subversion and git services added a comment - Commit 1710356 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1710356 ] SOLR-7858 revert premature commit
          Hide
          ASF subversion and git services added a comment -

          Commit 1712260 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1712260 ]

          SOLR-7858 Make default URL=/

          Show
          ASF subversion and git services added a comment - Commit 1712260 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1712260 ] SOLR-7858 Make default URL=/
          Hide
          Upayavira added a comment -

          Notes for reference on tasks to make UI default in 5x:

          • move admin.html to old.html
          • fix links in index.html to point to old.html
          • remove "warning" message with a 'go to original UI' link
          • set the ROOT_URL="/" in app.js
          • update web.xml (ref to admin.html, and welcome-file)
          • probably more...
          Show
          Upayavira added a comment - Notes for reference on tasks to make UI default in 5x: move admin.html to old.html fix links in index.html to point to old.html remove "warning" message with a 'go to original UI' link set the ROOT_URL="/" in app.js update web.xml (ref to admin.html, and welcome-file) probably more...
          Hide
          ASF subversion and git services added a comment -

          Commit 937a41489f78aa32efb5e65dcc4e60e9bae19431 in lucene-solr's branch refs/heads/master from Upayavira
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=937a414 ]

          SOLR-7858 - update links between new/old UIs for 6.x release

          Show
          ASF subversion and git services added a comment - Commit 937a41489f78aa32efb5e65dcc4e60e9bae19431 in lucene-solr's branch refs/heads/master from Upayavira [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=937a414 ] SOLR-7858 - update links between new/old UIs for 6.x release
          Hide
          ASF subversion and git services added a comment -

          Commit c18d3521a47727f2c0a4a4455db3cbaf1c6570bd in lucene-solr's branch refs/heads/branch_6_0 from Upayavira
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c18d352 ]

          SOLR-7858 - update links between new/old UIs for 6.x release

          Show
          ASF subversion and git services added a comment - Commit c18d3521a47727f2c0a4a4455db3cbaf1c6570bd in lucene-solr's branch refs/heads/branch_6_0 from Upayavira [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c18d352 ] SOLR-7858 - update links between new/old UIs for 6.x release
          Hide
          ASF subversion and git services added a comment -

          Commit 77d233bc01894c33f02178898dd3368b51902a11 in lucene-solr's branch refs/heads/branch_6x from Upayavira
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=77d233b ]

          SOLR-7858 - update links between new/old UIs for 6.x release

          Show
          ASF subversion and git services added a comment - Commit 77d233bc01894c33f02178898dd3368b51902a11 in lucene-solr's branch refs/heads/branch_6x from Upayavira [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=77d233b ] SOLR-7858 - update links between new/old UIs for 6.x release

            People

            • Assignee:
              Upayavira
              Reporter:
              Upayavira
            • Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development