: > Ah ... this is the one problem with high volume on an involved thread ... : > i'm sending replies to messages you write after you've already read other : > replies to other messages you sent and changed your mind :)
: Should we start a new thread? I don't think it would make a differnece ... we just need to slow down :) : Ok, now (I think) I see the difference between our ideas. : : >From your code, it looks like you want the RequestParser to extract : 'qt' that defines the RequestHandler. In my proposal, the : RequestHandler is selected independent of the RequestParser. no, no, no ... i'm sorry if i gave that impression ... the RequestParser *only* worries about getting a streams, it shouldn't have any way of even *guessing* what RequestHandler is going to be used. for refrence: http://www.nabble.com/Re%3A-p8438292.html note that i never mention "qt" .. instead i refer to "core.execute(solrReq, solrRsp);" doing exactly what it does today ... core.execute will call getRequestHandler(solrReq.getQueryType()) to pick the RequestHandler to use. the Servlet is what creates the SolrRequest object, and puts whatever SolrParams it wants (including "qt") in that SolrRequest before asking the SolrCore to take care of it. : What do you imagine happens in: : > : > String p = pickRequestParser(req); let's use the URL syntax you've been talking about that people seem to have agreed looks good (assuming i understand correctly) ... /servlet/${requesthandler}:${requestparser}?param1=val1¶m2=val2 what i was suggesting was that then the servlet which uses that URL structure might have a utility method called pickRequestParser that would look like... private String pickRequestParser(HttpServletRequest req) { String[] pathParts = req.getPathInfo().split("\:"); if (pathParts.length < 2 || "".equal(pathParts[1])) return "default"; // or "standard", or null -- whatever return pathParts[1]; } : If the RequestHandler is defined by the RequestParser, I would : suggest something like: again, i can't emphasis enough that that's not what i was proposing ... i am in no way shape or form trying to talk you out of the idea that it should be possible to specify the RequestParser, the RequestHandler, and the OutputWriter all as part of the URL, and completley independent of eachother. the RequestHandler and the OutputWriter could be specified as regular SolrParams that come from any part of the HTTP request, but the RequestParser needs to come from some part of the URL thta can be inspected with out any risk of affecting the raw post stream (ie: no HttpServletRequest.getParameter() calls) : I still don't see why: : : > : > // let the parser preprocess the streams if it wants... : > Iterable<ContentStreams> s = solrParser.preprocess : > (getStreamIno(req), new Pointer<InputStream>() { : > InputStream get() { : > return req.getInputStream(); : > }); : > : > Solrparams params = makeSolrRequest(req); : > : > // let the parser decide what to do with the existing streams, : > // or provide new ones : > Iterable<ContentStreams> solrParser.process(solrReq, s); : > : > // ServletSolrRequest is a basic impl of SolrRequest : > SolrRequest solrReq = new ServletSolrRequest(params, s); : > : : can not be contained entirely in: : : SolrRequest solrReq = parser.parse( req ); because then the RequestParser would be defining how the URL is getting parsed -- the makeSolrRequest utility placeholder i described had the wrong name, i should have called it makeSolrParams ... it would look something like this in the URL syntax i described above... private SolrParams makeSolrParams(HttpServletRequest req) { // this class already in our code base, used as is SolrParams p = new ServletSolrParams(req); String[] pathParts = req.getPathInfo().split("\:"); if ("".equal(pathParts[0])) return p; Map tmp = new HashMap(); tmp.put("qt", pathPaths[0]); return new DefaultSolrParams(new MapSolrParams(tmp), p); } the nutshell version of everything i'm trying to say is... SolrRequest - models all info about a request to solr to do something: - the key=val params assocaited with that request - any streams of data associated with that request RequestParser(s) - different instances for different sources of streams - is given two chances to generate ContentStreams: - once using the raw stream from the HTTP request - once using the params for the SolrRequest SolrSerlvet - the only thing with direct access to the HttpServletRequest, shields the other interface APIs from from the mechanincs of HTTP - dictates the URL structure - determines the name of the RequestParser to use - lets parser have the raw input stream - determines where SolrParams for request come from - lets parser have params to make more streams if it wants to. SolrCore - does all of hte name lookups for processing a SolrRequest: - picks a RequestHandler to use based on params, and runs it - determines what RequestParser to use when asked for one by name - determines what OutputWriter to use when asked for one by name RequestHandler(s) - different instances for different logic to be execute - has access to full SOlrRequest (params and streams) - may run whatever code it wants, and put results in a SolrResponse SolrResponse - container for deep structures of data, with optional error info OutputWriter(s) - different instances for different output formats - has access to full SolrRequest - is expected to render all data in SolrResponse -Hoss
