On 11/13/22 23:33, gnandre wrote:
e.g. /solr/admin/cores request works without specifying specific core in
the request.
I took a look at the code of such request handlers (e.g. LoggingHandler)
but they simply extend to RequestHandlerBase just like any other core-level
request handler. What makes them special so that they do not require core
context?
The /solr/admin/cores handler, as well as any other handler starting
with /solr/admin and possibly a few others as well are *global*
handlers. If you want to create your own global handler, then you can
add a definition to ImplicitPlugins.json, which is embedded in the
solr-core jar. Unless you want to do jar surgery, it's best to make
that change in the source code and recompile Solr. I think that you can
add the jar for the handler to server/lib/ext but there are situations
(which I can't say whether yours would qualify) where the jar needs to
be added to WEB-INF/lib in the webapp.
Many handlers that get created are specific to each core, and so they
start with /solr/CORENAME and will only operate on the named core. You
should never create a core named admin, as it will interfere with the
global handlers.
Note that if you are in cloud mode (running Solr with ZooKeeper), then
you should never use /solr/admin/cores to do anything other than reload
a core. Any actual changes must be done with /solr/admin/collections or
you run the risk of really screwing up your cluster. It is recommended
to use the collections handler for reloads too.
Thanks,
Shawn
