Ok, now i think I get what you are suggesting. The differences are that:
1) I think it should be a ServletFilter applied to all requests that will only process requests with a registered handler. 2) I think the RequestParser should take care off parsing ContentStreams *and* SolrParams - not just the streams. The dispatch servlet/filter should never call req.getParameter(). 3) I think the dispatcher picks the Handler and either calls it directly or passes it to SolrCore. It does not put "qt" in the SolrParams and have SolrCore extract it (again) == Arguments for a ServletFilter: == If we implement the dispatcher as a Filter: * the URL is totally customizable from solrconfig.xml * we have a single Filter to handle all standard requests * with this single Filter, we can easily handle the existing URL structures * configured URLs can sit at the 'Top level' next to 'top level' servlets If we implement the dispatcher as a Servlet * we have to define a 'base' path for each servlet - this would make the names longer then then need to be and add potential confusion in the configuration. Consider the servlet 'update' and another servlet 'select' When our proposed changes, these could both be the same servlet class configured to distinct paths. Now lets say you want to call: http://localhost/solr/update/xml?params Would that be configured in solrconfig.xml as <handler name="xml"? name="update/xml"? If it is "update/xml" would it only really work if the 'update' servlet were configured properly? == Why RequestParser should handle SolrParams AND Streams == * It is a MUCH easier interface to understand then pre/process * The dispatch filter does not need to touch req.getParameter() * It alows for plugable behavior to extract parameters - not just streams. Consider the current discussion on "POST for Queries" (http://www.nabble.com/Using-HTTP-Post-for-Queries-tf3039973.html) It seems like we may need a few ways to parse params out of the request. The way one handles the parameters directly affects the streams. This logic should be contained in a single place. == The Dispatcher should pick the handler == In the proposed url scheme: /path/to/handler:parser, the dispatcher has to decide what handler it is. If we use a filter, it will look for a registered handler - if it can't find one, it will not process the request. There is no reason it would need to inject 'qt' into the solr params just so it can be pulled out by SolrCore (using the @depricated function: solrReq.getQueryType()!) If the dispatcher is required to put a parameter in SolrParams, we could not make the RequestParser in charge of filling the SolrParams. This would require something like your pre/process system. == Pseudo-Java == The real version will do error handling and will need some special logic to make '/select' behave exactly as it does now. class SolrFilter implements Filter { void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { String path = req.getServletPath(); SolrRequestHandler handler = getHandlerFromPath( path ); if( handler != null ) { SolrRequestParser parser = getParserFormPath( path ); SolrQueryResponse solrRes = new SolrQueryResponse(); SolrQueryRequest solrReq = parser.parse( request ); core.execute( handler, solrReq, solrRes ); return; } chain.doFilter(request, response); } } Modify core to directly accept the 'handler': class SolrCore { public void execute(SolrRequestHandler handler, SolrQueryRequest req, SolrQueryResponse rsp) { // setup response header and handle request final NamedList responseHeader = new NamedList(); rsp.add("responseHeader", responseHeader); handler.handleRequest(req,rsp); setResponseHeaderValues(responseHeader,req,rsp); log.info(req.getParamString()+ " 0 "+ (int)(rsp.getEndTime() - req.getStartTime())); } @Depricated public void execute(SolrQueryRequest req, SolrQueryResponse rsp) { SolrRequestHandler handler = getRequestHandler(req.getQueryType()); if (handler==null) { log.warning("Unknown Request Handler ... } this.execute( handler, req, rsp ); } } ryan
