: >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 ... 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 :) In general i'm not too worried about what the URL structure looks like ... i agree it makes the most sense for the RequestParser to be determinede using the path, but beyond that i don't think it matters much -- the existing servlet could stay arround as is with a hardcoded use of a "DefaultRequestParser" that doesn't provide any streams and gets the params from HttpServletRequest while a new Servlet could get the qt and wt from the path info as well. -Hoss
