Bulk close for 3.2

but that is really a very independent improvement from this bug

I'd not separate the tests from the issue.

would you please open a new Jira issue?

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?

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.

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

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

Any objections about applying this trivial patch to 3.1.1?

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).

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

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.

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)

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:

public static final String DEFAULT_HANDLER_NAME="standard";

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.

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.

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

Will commit soon.