On 1/16/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: >I left out "micro-plugins" because i don't quite have a good answer
: >yet :) This may a place where a custom dispatcher servlet/filter
: >defined in web.xml is the most appropriate solution.
:
: If the issue is munging HTTPServletRequest information, then a proper
: separation of concerns suggests responsibility should lie with a Servlet
: Filter, as Ryan suggests.
I'm not making sense of this ... i don't see how the micro-plugins (aka:
RequestParsers) could be implimented as Filters and still be plugins that
users could provide ... don't Filters have to be specified in the web.xml
Yes. I'm suggesting we map a filter to intercept ALL requests, then
see which ones it should handle.
Consider:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
if(request instanceof HttpServletRequest) {
HttpServletRequest req = (HttpServletRequest) request;
String path = req.getServletPath();
SolrRequestHandler handler = core.getRequestHandler( path );
if( handler != null ) {
HANDLE THE REQUEST
return;
}
}
// Otherwise let the webapp handle the request
chain.doFilter(request, response);
}
... is there some progromatic way a Servlet or Filter can register other
Servlets/Filters dynamicly when the application is initalized? ... if
users have to extract the solr.war and modify the web.xml to add a
RequestParser they've written, that doesn't seem like much of a plugin :)
You would not need to extract the war, just change the registered handler name.
ryan
