On 1/17/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: 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
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.
: 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 -- ...
got it. Then i vote we use a syntax like: /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
: 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.
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. The main case where I imagine someone would need to write their own servlet/filter is if they insist the parameters need to be in the URL. For example: /delete/id/ The URL structure I am proposing could not support this (unless you had a handler mapped to each id :) ryan
