This entry is part 2 of 4 in the Developing Custom Solr SearchComponents series

In this article, I discuss SearchComponents briefly, and show how straightforward it is (in non-SolrCloud mode) to develop a custom Solr SearchComponent. In the next articles in the series, we examine the flow of logic in SolrCloud mode, and how you might be able to develop a SolrCloud-compatible SearchComponent.

Standalone Solr/non-SolrCloud

In standalone Solr mode, there are 3 methods to implement when developing a custom SearchComponent. Here is the simplest no-op SearchComponent.

public class TestSearchComponent extends SearchComponent {
    @Override
    public void prepare(ResponseBuilder rb) throws IOException {
 
    }
 
    @Override
    public void process(ResponseBuilder rb) throws IOException {
 
    }
 
    @Override
    public String getDescription() {
        return "My custom search component";
    }
}

The Java class that encapsules Solr search workflow is SearchHandler.

For non-SolrCloud mode, the general application flow is:

for( SearchComponent c : components ) {
  c.prepare(rb);
}
for( SearchComponent c : components ) {
  c.process(rb);
}

If you look at some of Solr's standard SearchComponents, you'll see that it is fairly arbitrary what goes into prepare() vs process(). It is entirely possible to do stuff entirely in prepare() or process(). If you'd like to modify how a certain component works, or to modify its output, you could either subclass it and override the method altogether, or add a component before or after it and modify its side-effects (in the request params or the response).

Deploying your custom SearchComponent

To deploy your new SearchComponent, bundle it as a jar and place it in the lib folder of your Solr core. If this is your first SearchComponent, this lib folder *does not exist* and must be created.

The path to the lib directory will be something like:

/{solr.home}/{core}/lib

e.g.

/var/solr/data/mycorename/lib

The lib directory is at the same level as the conf and data directories for your Solr core.

Then, in solrconfig.xml, add

<searchComponent name="test" class="com.company.solr.TestSearchComponent"/>
<requestHandler name="/test" class="org.apache.solr.handler.component.SearchHandler">
    <lst name="defaults">
    </lst>
    <arr name="components">
      <str>test</str>
      <str>query</str>
    </arr>
  </requestHandler>

As the Solr guide shows, you can also use first-components and last-components in place of components when declaring your component.

Conclusion

This concludes the first article in the series. In the next article, we will examine how search requests are served in SolrCloud and how the application flow is more involved and complex.