: 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,
ie...
/app/query?q=solr
/app/query:yakko/foo/yak?q=solr
/app/query:dot/bar/hoss?q=solr
...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
request.
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
mistake...
// 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) ?
-Hoss
