Apache Solr Documentation

6.5 Ref Guide (PDF Download)
Solr Tutorial
Solr Community Wiki

Older Versions of this Guide (PDF)

Ref Guide Topics


*** As of June 2017, the latest Solr Ref Guide is located at https://lucene.apache.org/solr/guide ***

Please note comments on these pages have now been disabled for all users.

Skip to end of metadata
Go to start of metadata

The <initParams> section of solrconfig.xml allows you to define request handler parameters outside of the handler configuration.

The use cases are

  • Some handlers are implicitly defined in code - see Implicit RequestHandlers - and there should be a way to add/append/override some of the implicitly defined properties
  • There are a few properties that are used across handlers. This helps you keep only a single definition of those properties and apply them over multiple handlers.

For example, if you want several of your search handlers to return the same list of fields, you can create an <initParams> section without having to define the same set of parameters in each request handler definition. If you have a single request handler that should return different fields, you can define the overriding parameters in individual <requestHandler> sections as usual.

The properties and configuration of an <initParams> section mirror the properties and configuration of a request handler. It can include sections for defaults, appends, and invariants, the same as any request handler.

For example, here is one of the <initParams> sections defined by default in the data_driven_config example:

xml#666666solid _text_ ]]>

This sets the default search field ("df") to be "_text_" for all of the request handlers named in the path section. If we later want to change the /query request handler to search a different field by default, we could override the <initParams> by defining the parameter in the <requestHandler> section for /query.

The syntax and semantics are similar to that of a  <requestHandler> . The following are the attributes




A comma-separated list of paths which will use the parameters. Wildcards can be used in paths to define nested paths, as described below.


The name of this set of parameters. The name can be used directly in a requestHandler definition if a path is not explicitly named. If you give your <initParams> a name, you can refer to the params in a <requestHandler> that is not defined as a path.

For example, if an <initParams> section has the name "myParams", you can call the name when defining your request handler:



An <initParams> section can support wildcards to define nested paths that should use the parameters defined. A single asterisk (*) denotes that a nested path one level deeper should use the parameters. Double asterisks (**) denote all nested paths no matter how deep should use the parameters.

For example, if we have an <initParams> that looks like this:

xml#666666solid _text_ 10 title ]]>

We've defined three paths with this section:

  • /myhandler declared as a direct path.
  • /root/* with a single asterisk to indicate the parameters should apply to paths that are one level deep.
  • /root1/** with double asterisks to indicate the parameters should apply to all nested paths, no matter how deep.

When we define the request handlers, the wildcards will work in the following ways:

xml#666666solid ]]>

The /myhandler class was named as a path in the <initParams> so this will use those parameters.

Next we have a request handler named /root/search5:


We defined a wildcard for nested paths that are one level deeper than /root, so this request handler will use the parameters. This one, however, will not, because /root/search5/test is more than one level deep from /root:


If we want to define all levels of nested paths, we should use double asterisks, as in the example path /root1/**:


Any path under /root1, whether explicitly defined in a request handler or not, will use the parameters defined in the matching initParams section.


  • No labels