mirror of https://github.com/apache/lucene.git
114 lines
5.3 KiB
Plaintext
114 lines
5.3 KiB
Plaintext
= 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,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">
|
|
<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.
|