On 11/17/22 22:05, gnandre wrote:
Unfortunately, I am still on legacy mode and not cloud mode.
So, I can't take advantage of this feature :(
In the meantime, I have implemented the Solr plugin and it is working as
expected but the only issue is that it needs to be called in the
context of
some core.
I wonder if we can reference cores with numbers? e.g. /solr/0/my/api/call
instead of /solr/<some_core_name>/my/api/call where - refers to first core
in some sense (say alphabetical)
That would alleviate the issue at least a bit because I don't need to know
the name of any particular core to get some node level info.
Sending again to the list. Accidentally sent only to end user. Twice!
Currently, global handlers (/admin/collections and /admin/cores for
example) are added by code in the CoreContainer class.
Here's an idea for fellow devs to consider: Can we have those handlers
specified instead by a file similar to ImplicitPlugins.json, maybe
NodeImplicitPlugins.json or CoreContainerImplicitPlugins.json that would
live in the solr-core jar along with ImplicitPlugins.json? And have
both code paths look for User* varieties of those filenames on the
classpath? Then users could just add UserImplicitPlugins.json and/or
UserNodeImplicitPlugins.json to ${solr.solr.home}/lib along with the
user-supplied jar(s) that implement them and those handlers would be
automatically available.
This is not to say that your idea of numbering cores is wrong ... just
that if your plugin is for the node or cluster, it shouldn't be accessed
at the core/collection level, and then there is no need for core
numbering. One thing you could do until something like the idea above
is added is create an empty core with a specific name on every node with
the handler in solrconfig.xml and then use that core name to access your
handler.
Thanks,
Shawn
