Sure - overriding the SolrDispatchFilter seems like a right way to go
(especially maintenance-wise :) ).
Thanks :)
ps. - as far as the ":" - situation is concerned - that was useful -
but i guess it didn't look nice ;)
(anyway - i guess that the ":"-trim filter must have persisted there
in the in order to support legacy apps using the ":"-notation)
.Alek
On Sep 7, 2008, at 7:44 AM, Chris Hostetter wrote:
: 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
