: This bothers me too. I find it really strange that Solr's entry-point : is a servlet filter instead of a servlet.
it traces back to the need for it to decide when to handle a request and when to let it pass through (to a later filter, a servlet or a JSP) this is the only way legacy support for the /select and /update urls work without forcing people to modify the web.xml; it's how a handler can be registered with the name /admin/foo even though /admin/ resolves to a JSP (and without forcing people to modify the web.xml); and it's what allows us to use the same core path prefixes for both handler requests and the Admin JSPs. : "It is unnecessary, and potentially problematic, to have the SolrDispatchFilter : configured to also filter on forwards. Do not configure : this dispatcher as <dispatcher>FORWARD</dispatcher>." : : The problem is that if filters do not have this FORWARD thing, then : cross context forwarding doesn't work. : : Is there a workaround to this problem ? You can try adding the FORWARD option, but the risk is that SolrRequestFilter could wind up forwarding to itself infinitely on some requests (depending on your configuration)... http://www.nabble.com/Re%3A-svn-commit%3A-r640449----lucene-solr-trunk-src-webapp-src-org-apache-solr-servlet-SolrDispatchFilter.java-p16262766.html -Hoss
