I don't know that it's a reason not to do it, but it's definitely been more
of a pain for me.
I have a servlet that pre-processes the request, and then forwards the
request to solr.
I found I had to add
Index: web.xml
===================================================================
--- web.xml (revision 19137)
+++ web.xml (working copy)
@@ -44,6 +44,8 @@
<filter-mapping>
<filter-name>SolrRequestFilter</filter-name>
<url-pattern>/*</url-pattern>
+ <dispatcher>REQUEST</dispatcher>
+ <dispatcher>FORWARD</dispatcher>
</filter-mapping>
to make things work with the filter. Took me a while to figure it out, so I
thought I'd mention it, in case it bites anyone else.
Tom
On 9/11/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>
> Peuss, Thomas wrote:
> > Hello!
> >
> > You might have seen my patch to SOLR-127.
> >
> > I have a question there: why is Solr using a filter instead of a servlet
> > to answer search requests? I have seen that it used a servlet before.
> > Why was that changed to a filter? The speed gains are minimal from my
> > point of view (at least in Tomcat).
> >
>
> We switched to a filter for flexibility not speed. The
> SolrDispatchFilter is applied to /*, so it can _choose_ to handle a
> request on any path or pass the request on down the chain.
>
> As a filter, we can configure what paths map to what RequestHandlers in
> solrconfig.xml rather then in web.xml
>
> Any reason not to use a filter?
>
