lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: handling multiple multiple resources with single requestHandler
Date Sun, 07 Sep 2008 05:44:50 GMT

: Any ideas on how could we register single request handler for handling
: multiple (wildcarded) contexts/resource uri's ?
: (something like) :
: <requestHandler name="/app/*" class="solr.StandardRequestHandler" >
: <requestHandler name="/app/*/query" class="solr.StandardRequestHandler">

One of the reasons wildcards aren't supported is because it creates 
ambiguity when dealing with dynamicly created RequestHandlers.

Once upon a time we had the notion that a ":" (colon) could be used in the 
query path to denote that SolrDispatchFilter should stop there and treat 
everything up to the colon as the handler name, while everything after the 
colon should be put in the SolrQueryRequest for use by the RequestHandler, 
...would all get processed by the "/app/query" handler which would have 
access to the "", "yakko/foo/yak", and "dot/bar/hoss" parts for each 

That seems to have been removed from SOlrDispatchFilter at some point, I'm 
not clear why but there are clearly remnents of it so maybe it was a 

        // unused feature ?
        int idx = path.indexOf( ':' );
        if( idx > 0 ) {
          // save the portion after the ':' for a 'handler' path parameter
          path = path.substring( 0, idx );

...i'm kind of tired right now, but if i'm reading that correctly it's 
flat out ignoring anything after the colon. (which seems like the worst of 
both worlds ... you can't have a ":" in your request handler name, but you 
can't have access to what comes after it if you put it in the URL)

I'm Not sure what's going on there.  Maybe someone else understands.

: The only way I can do it right now is by modifying SolrDispatchFilter, and
: manually adding request context trimming there (reducing the requested context
: to "/app/"), and registering handler for that context (which would later
: resolve other parts of it) -> but if there is another way to do this -
: without changing the code, I would be more than happy to learn about it :)

if you're comfortable with ServletFilters enough to muck with 
SolrDispatchFilter, then wouldn't writing a new filter that you configure 
to sit in front of SolrDispatchFilter and take pieces out of the URL and 
add them as request params be just as easy to write (and a lot easier to 
maintain) ?


View raw message