Passing request to another handler

[Andrzej Bialecki <ab...@getopt.org>]

Hi,

What's the canonical way to pass an update request to another handler? 
I'm implementing a handler that has to dispatch its result to different 
update handlers based on its internal processing.

Getting a handler from SolrCore.getRequestHandler(handlerName) makes the 
implementation dependent on deployment paths defined in solrconfig.xml. 
Using SolrCore.getRequestHandlers(handler.class) often returns the 
LazyRequestHandlerWrapper, from which it's not possible to retrieve the 
wrapped instance of the handler ..

-- 
Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com

Re: Passing request to another handler

[Andrzej Bialecki <ab...@getopt.org>]

Shalin Shekhar Mangar wrote:
> On Fri, Oct 9, 2009 at 10:53 PM, Andrzej Bialecki <ab...@getopt.org> wrote:
> 
>> Hi,
>>
>> What's the canonical way to pass an update request to another handler? I'm
>> implementing a handler that has to dispatch its result to different update
>> handlers based on its internal processing.
>>
>>
> An update request? There's always only one UpdateHandler registered in Solr.

Hm, yes - to be more specific, what I meant is that I need to 
pre-process an update request and then pass it on either to my own 
handler (which performs an update) or to the ExtractingRequestHandler 
(which also performs an update).

> 
> 
>> Getting a handler from SolrCore.getRequestHandler(handlerName) makes the
>> implementation dependent on deployment paths defined in solrconfig.xml.
>> Using SolrCore.getRequestHandlers(handler.class) often returns the
>> LazyRequestHandlerWrapper, from which it's not possible to retrieve the
>> wrapped instance of the handler ..
>>
>>
> You must know the name of the handler you are going to invoke. Or if you are
> sure that there is only one instance, knowing the class name will let you
> know the handler name. Then the easiest way to invoke it would be to use a

I do know the class name - ExtractingRequestHandler. But when I invoke 
SolrCore.getRequestHandler(Class) I get an empty map, because this 
handler is registered as lazy, and this means that it's represented as 
LazyRequestHandlerWrapper.

-- 
Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com

Re: Passing request to another handler

[Shalin Shekhar Mangar <sh...@gmail.com>]

On Fri, Oct 9, 2009 at 10:53 PM, Andrzej Bialecki <ab...@getopt.org> wrote:

> Hi,
>
> What's the canonical way to pass an update request to another handler? I'm
> implementing a handler that has to dispatch its result to different update
> handlers based on its internal processing.
>
>
An update request? There's always only one UpdateHandler registered in Solr.


> Getting a handler from SolrCore.getRequestHandler(handlerName) makes the
> implementation dependent on deployment paths defined in solrconfig.xml.
> Using SolrCore.getRequestHandlers(handler.class) often returns the
> LazyRequestHandlerWrapper, from which it's not possible to retrieve the
> wrapped instance of the handler ..
>
>
You must know the name of the handler you are going to invoke. Or if you are
sure that there is only one instance, knowing the class name will let you
know the handler name. Then the easiest way to invoke it would be to use a
LocalSolrQueryRequest with qt as the handler name. See QuerySenderListener
for an example.

-- 
Regards,
Shalin Shekhar Mangar.

Re: Passing request to another handler

[Andrzej Bialecki <ab...@getopt.org>]

Chris Hostetter wrote:
> : What's the canonical way to pass an update request to another handler? I'm
> : implementing a handler that has to dispatch its result to different update
> : handlers based on its internal processing.
> 
> I've always written my delegating RequestHandlers so that they take in the 
> names (or paths) of the handlers they are going to delegate to as init 
> params.

Yeah, this is where I started ...

> 
> the other approach i've seen is to make the delegating handler instantiate 
> the sub-handlers directly so that it can have the exact instnaces it wants 
> configured the way it wants them.

... and this is where I ended now :)

> 
> It really comes down to what your goal is: if you wnat your code to be 
> totlaly in conrol instantiate new instances.  if you wnat the person 
> creatining the solrconfig.xml to be in control let them tell you the name 
> of a handler (with it's defaults/invariants configured i na way you can't 
> control) to delegate to.

Indeed - thanks.

-- 
Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com

Re: Passing request to another handler

[Chris Hostetter <ho...@fucit.org>]

: What's the canonical way to pass an update request to another handler? I'm
: implementing a handler that has to dispatch its result to different update
: handlers based on its internal processing.

I've always written my delegating RequestHandlers so that they take in the 
names (or paths) of the handlers they are going to delegate to as init 
params.

the other approach i've seen is to make the delegating handler instantiate 
the sub-handlers directly so that it can have the exact instnaces it wants 
configured the way it wants them.

It really comes down to what your goal is: if you wnat your code to be 
totlaly in conrol instantiate new instances.  if you wnat the person 
creatining the solrconfig.xml to be in control let them tell you the name 
of a handler (with it's defaults/invariants configured i na way you can't 
control) to delegate to.


-Hoss