: I was... then you talked me out of it! You are correct, the client
: should determine the RequestParser independent of the RequestHandler.
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?
Here's a more fleshed out version of the psuedo-java i posted earlier,
with all of my adendums inlined and a few simple metho calls changed to
try and make the purpose more clear...
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.
What do you imagine happens in:
String p = pickRequestParser(req);
This looks like you would have to have a standard way (per servlet) of
gettting the RequestParser. How do you invision that? What would be
the standard way to choose your request parser?
If the RequestHandler is defined by the RequestParser, I would
suggest something like:
interface SolrRequest
{
RequestHandler getHandler();
Iterable<ContentStream> getContentStreams();
SolrParams getParams();
}
interface RequestParser
{
SolrRequest getRequest( HttpServletRequest req );
// perhaps remove getHandler() from SolrRequest and add:
RequestHandler getHandler();
}
And then configure a servlet or filter with the RequestParser
<filter>
<filter-name>SolrRequestFilter</filter-name>
<filter-class>...</filter-class>
<init-param>
<param-name>RequestParser</param-name>
<param-value>org.apache.solr.parser.StandardRequestParser</param-value>
</init-param>
</filter>
Given that the number of RequestParsers is realistically small (as
Yonik mentioned), I think this could be a good solution.
To update my current proposal:
1. Servlet/Filter defines the RequestParser
2. requestParser parses handler & request from HttpServletRequest
3. handled essentially as before
To update the example URLs, defined by the "StandardRequestParser"
/path/to/handler/?param
where /path/to/handler is the "name" defined in solrconfig.xml
To use a different RequestParser, it would need to be configured in web.xml
/customparser/whatever/path/i/like
- - - - - - - - - - - - - -
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 );
assuming the SolrRequest interface includes
Iterable<ContentStream> getContentStreams();
the parser can use use req.getInputStream() however it likes - either
to make params and/or to build ContentStreams
- - - - - - - -
good good
ryan
