: > This would give people a relativly easy way to implement 'restful'
: > URLs if they need to. (but they would have to edit web.xml)
:
: A handler could alternately get the rest of the path (absent params), right?
only if the RequestParser adds it to the SolrRequest as a SolrParam.
: > Unit tests should be handled by execute( handler, req, res )
:
: How does the unit test get the handler?
i think ryans point is that when testing a handler, you should know which
handler you are testing, so construct it and execute it directly.
: > I am proposing we have a single interface to do this:
: > SolrRequest r = RequestParser.parse( HttpServletRequest )
:
: That's currently what new SolrServletRequest(HttpServletRequest) does.
: We just need to figure out how to get InputStreams, Readers, etc.
we start by adding "Iterable<ContentStream> getStreams()" to the
SolrRequest interface, with a setter on all of the Impls that's not part
of the interface. then i suspect what we'll see is two classes that look
like this..
public class NoStreamRequestParser implements RequestParser {
public SolrRequest parse(HttpServletRequest req) {
return new SolrServletRequest(HttpServletRequest);
}
}
public class RawPostStreamRequestParser extends NoStreamRequestParser {
public SolrRequest parse(HttpServletRequest req) {
ContentStream c = makeContentStream(req.getInputStream())
SolrServletRequest s = super.parse(req);
s.setStreams(new SinglItemCollection(c))
return s;
}
}
: So, the hander needs to be able to get an InputStream, and HTTP headers.
: Other plugins (CSV) will ask for a Reader and expect the details to be
: ironed out for it.
:
: Method1: come up with ways to expose all this info through an
: interface... a "headers" object could be added to the SolrRequest
: context (see getContext())
this is why Ryan and i have been talking in terms of a "ContentStream"
interface instead of just "InputStream" .. at some point we talked about
the ContentStream having getters for mime type, and charset that might be
null if unknown.
-Hoss
