| = InitParams in SolrConfig |
| // Licensed to the Apache Software Foundation (ASF) under one |
| // or more contributor license agreements. See the NOTICE file |
| // distributed with this work for additional information |
| // regarding copyright ownership. The ASF licenses this file |
| // to you under the Apache License, Version 2.0 (the |
| // "License"); you may not use this file except in compliance |
| // with the License. You may obtain a copy of the License at |
| // |
| // http://www.apache.org/licenses/LICENSE-2.0 |
| // |
| // Unless required by applicable law or agreed to in writing, |
| // software distributed under the License is distributed on an |
| // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| // KIND, either express or implied. See the License for the |
| // specific language governing permissions and limitations |
| // under the License. |
| |
| The `<initParams>` section of `solrconfig.xml` allows you to define request handler parameters outside of the handler configuration. |
| |
| There are a couple of use cases where this might be desired: |
| |
| * Some handlers are implicitly defined in code - see <<implicit-requesthandlers.adoc#,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 `_default` example: |
| |
| [source,xml] |
| ---- |
| <initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse"> |
| <lst name="defaults"> |
| <str name="df">_text_</str> |
| </lst> |
| </initParams> |
| ---- |
| |
| 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: |
| |
| `path`:: |
| A comma-separated list of paths which will use the parameters. Wildcards can be used in paths to define nested paths, as described below. |
| |
| `name`:: |
| 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 parameters 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: |
| + |
| [source,xml] |
| <requestHandler name="/dump1" class="DumpRequestHandler" initParams="myParams"/> |
| |
| == Wildcards in initParams |
| |
| 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: |
| |
| [source,xml] |
| ---- |
| <initParams name="myParams" path="/myhandler,/root/*,/root1/**"> |
| <lst name="defaults"> |
| <str name="fl">_text_</str> |
| </lst> |
| <lst name="invariants"> |
| <str name="rows">10</str> |
| </lst> |
| <lst name="appends"> |
| <str name="df">title</str> |
| </lst> |
| </initParams> |
| ---- |
| |
| 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: |
| |
| [source,xml] |
| ---- |
| <requestHandler name="/myhandler" class="SearchHandler"/> |
| ---- |
| |
| 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`: |
| |
| [source,xml] |
| ---- |
| <requestHandler name="/root/search5" class="SearchHandler"/> |
| ---- |
| |
| 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`: |
| |
| [source,xml] |
| ---- |
| <requestHandler name="/root/search5/test" class="SearchHandler"/> |
| ---- |
| |
| If we want to define all levels of nested paths, we should use double asterisks, as in the example path `/root1/**`: |
| |
| [source,xml] |
| ---- |
| <requestHandler name="/root1/search/tests" class="SearchHandler"/> |
| ---- |
| |
| Any path under `/root1`, whether explicitly defined in a request handler or not, will use the parameters defined in the matching `initParams` section. |