lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksandar Bradic <aleksan...@vast.com>
Subject Re: handling multiple multiple resources with single requestHandler
Date Mon, 08 Sep 2008 17:58:34 GMT

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message