Once you figure this out it would be awesome if you could write up what
you did - a blog would be a fantastic resource for people writing
plugins in the future.
Best
Charlie
On 16/11/2022 11:52, Jan Høydahl wrote:
Yes
Seehttps://solr.apache.org/guide/solr/latest/configuration-guide/cluster-plugins.html
for the docs.
Jan
16. nov. 2022 kl. 00:43 skrev gnandre<arnoldbron...@gmail.com>:
Also, is this supported only in SolrCloud mode?
On Tue, Nov 15, 2022 at 6:42 PM gnandre<arnoldbron...@gmail.com> wrote:
Thanks, Ishan. Is this available only in Solr 8.6+? I am using 8.5.0 :(
On Tue, Nov 15, 2022 at 2:19 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
https://issues.apache.org/jira/browse/SOLR-14404
On Wed, Nov 16, 2022 at 12:46 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
Here's a core container level plugin, for example:
https://github.com/yasa-org/yasa/tree/master/yasa-solr-plugin
On Mon, Nov 14, 2022 at 10:07 PM Gus Heck<gus.h...@gmail.com> wrote:
In 9.x it should be possible to write a separate servlet that can
answer
custom non-search queries. Then all you need to edit is web.xml. You
can
now get hold of a core container
via org.apache.solr.servlet.CoreContainerProvider#getCoreContainer.
Looking at the code, it seems you still need to live in the apache
package
because that method is not public, but if you've got a demonstrable use
case for it I don't see why that couldn't be made public in future
versions. If that's tweaked to be public you could avoid changing
implicit
plugins, would not need to live under admin, and it should be possible
to
load from a separate jar if the jar is inserted
into /server/solr-webapp/webapp/WEB-INF/lib
A question to consider when choosing is whether you want the end point
to
be protected by authentication. If so then you're going to want to do
it
Shawn's way. If you want something publicly visible (say to
infrastructure
systems without login) then a servlet might be more useful since it
will
live outside of all our security stuff.
On Mon, Nov 14, 2022 at 2:16 AM gnandre<arnoldbron...@gmail.com>
wrote:
Thanks, Shawn. I think what you propose there will be very helpful.
There
are definitely usecases where we want to work at the solr node level
and
not core level. Fieldcache is one other example.
In my case, I am trying to write a simple health check request
handler
that
makes sure that all cores on a particular node are loaded and are
queriable. The ping request handler works on a core level. The
/solr/admin/cores api works for me but it returns with the ok status
even
if some other cores are still loading after solr restart.
Ps. I am using legacy setup (non-cloud)
On Mon, Nov 14, 2022, 2:04 AM Shawn Heisey<apa...@elyograg.org>
wrote:
On 11/13/22 23:55, Shawn Heisey wrote:
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.
Seehttps://issues.apache.org/jira/browse/SOLR-15859 for an
example
where I am creating a new global handler.
I am wondering if ImplicitPlugins.json could be put in a location
like
server/lib/ext so recompiling Solr or jar surgery isn't required.
I
think server/lib/ext is searched on the classpath before WEB-INF.
Even
better would be to have another json where user-specified implicit
handlers can be defined.
Thanks,
Shawn
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
--
Charlie Hull - Managing Consultant at OpenSource Connections Limited
Founding member of The Search Network <http://www.thesearchnetwork.com>
and co-author of Searching the Enterprise
<https://opensourceconnections.com/wp-content/uploads/2020/08/ES_book_final_journal_version.pdf>
tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828
OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin
Amtsgericht Charlottenburg | HRB 230712 B
Geschäftsführer: John M. Woodell | David E. Pugh
Finanzamt: Berlin Finanzamt für Körperschaften II
