handling multiple multiple resources with single requestHandler

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

handling multiple multiple resources with single requestHandler

Aleksandar Bradic
Hi,

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">

Current logic in SolrDispatchFilter / RequestHandlers registers a  
single (context <-> handler) mapping and obviously doesn't allow  
wildcarding.

However, such feature could be quite useful in situations where we  
have single app/handler handling multiple contexts
(if there are few - the ugly way would be to just register multiple  
entries pointing to the single handler , but in some situations - like  
when having a numeric mid-argument , (example : "/app/3/query") - it's  
even impossible to do it)

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 :)

(actually there is a pathPrefix property, used in that part of the  
code - but it does the complete opposite of what is needed in this  
case :( )

Thanks,

.Alek


Reply | Threaded
Open this post in threaded view
|

Re: handling multiple multiple resources with single requestHandler

hossman

: 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

Reply | Threaded
Open this post in threaded view
|

Re: handling multiple multiple resources with single requestHandler

Aleksandar Bradic

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