>
> // get all the registered handlers by class
> Collection<SolrRequestHandler> getRequestHandlers( Class<? extends,
> SolrRequestHandler> clazz );
By class? What's that for?
It was useful to check what else is configured. The alternative is to have a
Collection<SolrRequestHandler> getRequestHandlers() and have let the
client sort out what is what. In the case I am looking at, I want to
check if a handler of given type is already registered - if not, i
register one.
getRequestHandlers() would be equivolent to:
getRequestHandlers( SolrRequestHandler.class )
We will need some way to ask what is registered without knowing the
path it is registered to.
Everything else seems to make sense... it would mean an extra
synchronization per Solr request, but that shouldn't be measurable
given everything else we are doing.
would access to getRequestHandler( name ) need to be synchronized?
Are there any real problems if not? I don't imagine much would change
after startup.
One thing we lost going from individual servlets to a filter was the
potential for load-on-demand handlers. If/when CSV and SQL update
handlers get put in the core, it might be nice if they weren't loaded
at startup.
perhaps we could add:
<requestHandler name="..." class=".." statup="lazy" />
Then we could have a LazyRequestHandlerWrapper that only hangs on to
configuration parameters, but done not initialize the delegate handler
until its first request. This would be transparent to the
Filter/Servlet framework
But I'll save that for another day :)
