I'm certainly on board with adding a requestHandler mapping for "/update",
but i'm not sure how i feel about changing it under the covers ...
I'm suggesting we keep /update mapped to SolrUpdateServlet in web.xml, but map:
<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" >
in solrconfig.xml. The only serious problem i see with that is that
/update and /update/ could go to two different places. I'm not sure
why web.xml has update mapped to /update/*
I am not sure what we should do with the DispatchFilter handle-select parameter:
<init-param>
<param-name>handle-select</param-name>
<param-value>true</param-value>
</init-param>
This would have the same error handling (and response codes) for
/select?qt=xxx as it does for /path/mapped/in/config
BUT if someone wanted to opt-out of that change, they would need to
edit web.xml. I think consistent error handling is worth it, but I'm
not sure if this would hurt anyone.
also gives options for people should bugs be encountered in either code
path)
yes
really need many more new features -- the real question is are there any
large concepts currently "in progress" that should be finished off?
The major 'in progress' work still needs attention, so i don't think
they are suitable for a near term release.
That said, the things I would like to see included are:
SOLR-162, SOLR-184, and SOLR-179
All of these are useful to people getting started with solr and
helpful debugging tools. I've convinced a bunch of people to use solr
and these additions make it much easier for someone to help debug
without access to the machine. It is much nicer to have people
running official releases then a patched up war I build.
And of course: are there any new "API" type things (config syntax, param
names, etc...) since the 1.1 release that we want to tweak?
The one thing i can think of is that it would be nice to solidify the
"handler" package as the place that request handlers go. How do you
feel about deprecating o.a.s.request.StandardRequestHandler and moving
it to o.a.s.handler.StandardRequestHandler -- same for
DisMaxRequestHandler
we can leave an deprecated extended class in o.a.s.request untill the
next release or two. something like:
http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/request/ContentStream.java
This way anyone extending Standard or Dismax don't need to refactor immediately.
ryan
