: 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
yeah, that's the *example* solrconfig, which is why i'm on board with it ... it doesn't affect existing users in anyway unless they change their config. : /update and /update/ could go to two different places. I'm not sure : why web.xml has update mapped to /update/* why would /update and /update/ be treated differently? dispatch filter will take them both and give them to XmlUpdateRequestHandler because it does prefix matching right? : 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 i don't think we should do this: 1) it changes things under the covers for existing users; 2) people are probably going to use one URL structure or the other, the two don't really need to be perfectly consistent in their behavior. The only reason i think we should eventually change this will be down the road when we want to competely eliminte the old code paths because we are confident very few people are using them because the examplles have all had the new style. which brings up a key point: we should change all the example urls in the wiki/tutorial to use the new URL style. : 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 I personally don't think we need to wait on any new functionality -- this release will already be fairly significant given what's already been commited (and that it's post incubation so all of hte release steps need to be re-sanity checked). : 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 adding some package.html files clarifying what *should* be in each package definitely makes sense ... moving the existing request handlers is definitely a lower priority (especially since even if we move them, we'll need the placeholder subclasses for people currently subclassing them) -Hoss
