Solr
  1. Solr
  2. SOLR-2445

unknown handler: standard when using form.jsp

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4.1, 3.1, 3.2, 4.0-ALPHA
    • Fix Version/s: 3.1.1, 3.2, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      To reproduce the problem using example config, go form.jsp, use standard for qt (it is default) then click Search.

      1. DefaultQTypeTest.java
        0.8 kB
        Gabriele Kahlout
      2. SOLR-2445_tests.patch
        1 kB
        Gabriele Kahlout
      3. qt-form-jsp.patch
        0.4 kB
        Gabriele Kahlout
      4. SOLR-2445.patch
        2 kB
        Koji Sekiguchi

        Issue Links

          Activity

          Hide
          Koji Sekiguchi added a comment -

          Will commit soon.

          Show
          Koji Sekiguchi added a comment - Will commit soon.
          Hide
          Koji Sekiguchi added a comment -

          trunk: Committed revision 1086276.
          3x: Committed revision 1086289.

          Show
          Koji Sekiguchi added a comment - trunk: Committed revision 1086276. 3x: Committed revision 1086289.
          Hide
          Hoss Man added a comment -

          wait a minute ... there's no requirement that a handler named "standard" exist, nor is there any reason why solr should create a handler with that name automagically for you. (we already create one anonymous handler instance)

          All the docs have ever said is that if you declare a handler named "standard" then it will be used if no qt is specified, and no handler is marked default="true"

          http://wiki.apache.org/solr/SolrRequestHandler

          I deliberately removed the example usage of name="standard" from the example solrconfig.xml to simplify the confusion that people have about the way name="standard" and default=true" interact.

          If the problem here is that form.jsp defaults to listing "standard" for the "qt" param, then the fix is to change form.jsp and leave that box blank.

          Show
          Hoss Man added a comment - wait a minute ... there's no requirement that a handler named "standard" exist, nor is there any reason why solr should create a handler with that name automagically for you. (we already create one anonymous handler instance) All the docs have ever said is that if you declare a handler named "standard" then it will be used if no qt is specified, and no handler is marked default="true" http://wiki.apache.org/solr/SolrRequestHandler I deliberately removed the example usage of name="standard" from the example solrconfig.xml to simplify the confusion that people have about the way name="standard" and default=true" interact. If the problem here is that form.jsp defaults to listing "standard" for the "qt" param, then the fix is to change form.jsp and leave that box blank.
          Hide
          Koji Sekiguchi added a comment -

          If the problem here is that form.jsp defaults to listing "standard" for the "qt" param, then the fix is to change form.jsp and leave that box blank.

          No problem for me to fix form.jsp.

          Show
          Koji Sekiguchi added a comment - If the problem here is that form.jsp defaults to listing "standard" for the "qt" param, then the fix is to change form.jsp and leave that box blank. No problem for me to fix form.jsp.
          Hide
          Koji Sekiguchi added a comment -

          there's no requirement that a handler named "standard" exist, nor is there any reason why solr should create a handler with that name automagically for you.

          I didn't think so, because I saw the "standard" name that is defined public static final:

          RequestHandlers.java
          public static final String DEFAULT_HANDLER_NAME="standard";
          
          Show
          Koji Sekiguchi added a comment - there's no requirement that a handler named "standard" exist, nor is there any reason why solr should create a handler with that name automagically for you. I didn't think so, because I saw the "standard" name that is defined public static final: RequestHandlers.java public static final String DEFAULT_HANDLER_NAME= "standard" ;
          Hide
          Hoss Man added a comment -

          that's a fairly old static, probably from before we even supported default="true"

          the important thing is that it's just the name of the what solr will look for when trying to find a default, it doesn't garuntee that one will exist with that name if the user doesn't define it.

          as the wiki says: if there is no default, and none are declared with the name "standard" it uses an anonymous object instance.

          but with the code you commited, the user has no choice – they have to have one named "standard" (even if they deliberately don't want one, and already have a different one with the default="true" option)

          Show
          Hoss Man added a comment - that's a fairly old static, probably from before we even supported default="true" the important thing is that it's just the name of the what solr will look for when trying to find a default, it doesn't garuntee that one will exist with that name if the user doesn't define it. as the wiki says: if there is no default, and none are declared with the name "standard" it uses an anonymous object instance. but with the code you commited, the user has no choice – they have to have one named "standard" (even if they deliberately don't want one, and already have a different one with the default="true" option)
          Hide
          Koji Sekiguchi added a comment -

          I missed Wiki, but I only looked how initHandlersFromConfig() was implemented when I commit:

          if(get("") == null) register("", get(DEFAULT_HANDLER_NAME));
          

          I thought Solr should have the handler named DEFAULT_HANDLER_NAME.

          But if "Handler Resolution" of wiki is correct, and I definitely think it sounds reasonable for me now, and I think Solr should be able to start without any handlers, I'll revert my commit but make qt blank in form.jsp.

          Show
          Koji Sekiguchi added a comment - I missed Wiki, but I only looked how initHandlersFromConfig() was implemented when I commit: if (get( "") == null ) register(" ", get(DEFAULT_HANDLER_NAME)); I thought Solr should have the handler named DEFAULT_HANDLER_NAME. But if "Handler Resolution" of wiki is correct, and I definitely think it sounds reasonable for me now, and I think Solr should be able to start without any handlers, I'll revert my commit but make qt blank in form.jsp.
          Hide
          Koji Sekiguchi added a comment -

          trunk: Committed revision 1086821.
          3x: Committed revision 1086822.

          Show
          Koji Sekiguchi added a comment - trunk: Committed revision 1086821. 3x: Committed revision 1086822.
          Hide
          Gabriele Kahlout added a comment - - edited

          trivial patch to form.jsp that leaves qt empty (useful for setup scripts and those that need to stick to a 3.1.0 revision).

          Show
          Gabriele Kahlout added a comment - - edited trivial patch to form.jsp that leaves qt empty (useful for setup scripts and those that need to stick to a 3.1.0 revision).
          Hide
          Koji Sekiguchi added a comment -

          Any objections about applying this trivial patch to 3.1.1?

          Show
          Koji Sekiguchi added a comment - Any objections about applying this trivial patch to 3.1.1?
          Hide
          Koji Sekiguchi added a comment -

          Seems that no one objects about applying the patch to 3.1.1. Reopening.

          Show
          Koji Sekiguchi added a comment - Seems that no one objects about applying the patch to 3.1.1. Reopening.
          Hide
          Koji Sekiguchi added a comment -

          Committed revision 1104270 for 3.1.1.
          Thanks Gabriele for your patience!

          Show
          Koji Sekiguchi added a comment - Committed revision 1104270 for 3.1.1. Thanks Gabriele for your patience!
          Hide
          Gabriele Kahlout added a comment - - edited

          I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4.

          I've attached a minimal test that works from my own client app (at least it works for someone =)). Feel free to adapt it for test-framework tests.

          Show
          Gabriele Kahlout added a comment - - edited I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4. I've attached a minimal test that works from my own client app (at least it works for someone =)). Feel free to adapt it for test-framework tests.
          Hide
          Hoss Man added a comment -

          Gabriele...

          I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4.

          All of the existing tests either use configs in which a requestHandler named "standard" is configured, or they use the TestHarness in such a way that overrides the one specified in TestHarness.

          I agree that we should probably remove the use of "standard" in the harness as well – and ideally update all of the test configs to start using default="true" – but that is really a very independent improvement from this bug and should be tracked separately – would you please open a new Jira issue?

          Show
          Hoss Man added a comment - Gabriele... I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4. All of the existing tests either use configs in which a requestHandler named "standard" is configured, or they use the TestHarness in such a way that overrides the one specified in TestHarness. I agree that we should probably remove the use of "standard" in the harness as well – and ideally update all of the test configs to start using default="true" – but that is really a very independent improvement from this bug and should be tracked separately – would you please open a new Jira issue?
          Hide
          Gabriele Kahlout added a comment -

          but that is really a very independent improvement from this bug

          I'd not separate the tests from the issue.

          {quoute}

          would you please open a new Jira issue?


          I'm sure there's a $XB market opportunity for a solution to this common forwarding problem. Has it been been better defined and named?

          Show
          Gabriele Kahlout added a comment - but that is really a very independent improvement from this bug I'd not separate the tests from the issue. {quoute} would you please open a new Jira issue? I'm sure there's a $XB market opportunity for a solution to this common forwarding problem. Has it been been better defined and named?
          Hide
          Robert Muir added a comment -

          Bulk close for 3.2

          Show
          Robert Muir added a comment - Bulk close for 3.2

            People

            • Assignee:
              Koji Sekiguchi
              Reporter:
              Koji Sekiguchi
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development