: I'm not sure i underestand preProcess( ) and what it gets us. it gets us the abiliity for a RequestParser to be able to pull out the raw InputStream from the HTTP POST body, and make it available to the RequestHandler as a ContentStream and/or it can wait untill the servlet has parsed the URL to get the params and *then* it can generate ContentStreams based on those param values.
- preProcess is neccessary to write a RequestParser that can handle the current POST raw XML model, - process is neccessary to write RequestParsers that can get file names or URLs out of escaped query params and fetch them as streams : 1. The URL path selectes the RequestHandler : 2. RequestParser = RequestHandler.getRequestParser() (typically from : its default params) : 3. SolrRequest = RequestParser.parse( HttpServletRequest ) : 4. handler.handleRequest( req, res ); : 5. write the response the problem i see with that, is that the RequestHandler shouldn't have any say in what RequestParser is used -- the client is hte only one that knows what type of data they are sending to Solr, they should put information in the URL that directly picks the RequestParser. If you think about it in terms of the current POSTing XML model, an XmlUpdateRequestHandler that reads in our "<add><doc>..." style info shouldn't know anywhere in it's confiuration where that stream of XML bytes came from -- when it gets asked to handle the request, all it should know is that it has some optional params, and an InputStream to work with ... the RequestParsers job is to decide where that input stream came from. : If anyone needs to customize this chain of events, they could easily : write their own Servlet/Filter this is why i was confused about your Filter comment earlier: if the only way a user can customize behavior is by writting a Servlet, they can't specify that servlet in a solr config file -- they'd have to unpack the war and manually eidt the web.xml ... which makes upgrading a pain. -Hoss
