: I think the confusion is that (in my view) the RequestParser is the : *only* object able to touch the stream. I don't think anything should : happen between preProcess() and process(); A RequestParser converts a : HttpServletRequest to a SolrRequest. Nothing else will touch the : servlet request.
that makes it the RequestParsers responsibility to dictate the URL format (if it's the only one that can touch the HttpServletRequest) i was proposing a method by which the Servlet could determine the URL format -- there could in fact be multiple servlets supporting different URL formats if we had some need for it -- and the RequestParser could generate streams based on the raw POST data and/or any streams it wants to find based on the SolrParams generated from the URL (ie: local files, remote resources, etc) I'm confused by your sentence "A RequestParser converts a HttpServletRequest to a SolrRequest." .. i thought you were advocating that the servlet parse the URL to pick a RequestHandler, and then the RequestHandler dicates the RequestParser? : /path/registered/in/solr/config:requestparser?params : : If no ':' is in the URL, use 'standard' parser : : 1. The URL path determins the RequestHandler : 2. The URL path determins the RequestParser : 3. SolrRequest = RequestParser.parse( HttpServletRequest ) : 4. handler.handleRequest( req, res ); : 5. write the response do you mean the path before hte colon determins the RequestHandler and the path after the colon determines the RequestParser? ... that would work fine too ... i was specificly trying to avoid making any design decissions that required a particular URL structure, in what you propose we are dictating more then just the "/handler/path:parser" piece of the URL, we are also dicating that the Parser decides how the rest of the path and all URL query string data will be interpreted -- which means if we have a PostBodyRequestParser and a LocalFileRequestParser and a RemoteUrlRequestParser and which all use the query stirng params to get the SolrParams for the request (and in the case of the last two: to know what file/url to parse) and then we decide that we want to support a URL structure that is more REST like and uses the path for including information, now we have to write a new version of all of those RequestParsers ( subclass of each probably) that knows what our new URL structure looks like ... even if that never comes up, every RequestParser (even custom ones written by users to use some crazy proprietery binary protocols we've never heard of to fetch stream of data has to worry about extracting the SOlrParams out of the URL. what i'm proposing is that the Servlet decide how to get the SolrParams out of an HttpServletRequest, using whatever URL that servlet wants; the RequestParser decides how to get the ContentStreams needed for that request -- in a way that can work regardless of wether the stream is acctually part of the HttpServletRequest, or just refrenced by a param in the the request; the RequestHandler decides what to do with those params and streams; and the the ResponseWriter decides how to format the results produced by the RequestHandler back to the client. : > : If anyone needs to customize this chain of events, they could easily : > : write their own Servlet/Filter : I don't *think* this would happen often, and the people would only do : it if they are unhappy with the default URL structure -> behavior : mapping. I am not suggesting this would be the normal way to : configure solr. I think i'm getting confused ... i thought you were advocating that RequestParsers be implimented as ServletFilters (or Servlets) ... but if that were the case it wouldn't just be able changing hte URL structure, it would be able picking new ways to get streams .. but that doesn't seem to be what you are suggesting, so i'm not sure what i was missunderstanding. -Hoss
