You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2018/04/20 19:29:40 UTC
[1/2] lucene-solr:branch_7x: SOLR-11646: Add v2 APIs for Config API;
change "ConfigSet" to "configset" in docs & specs to match community
spelling
Repository: lucene-solr
Updated Branches:
refs/heads/branch_7x 8c9b00a7a -> 5915e61e4
SOLR-11646: Add v2 APIs for Config API; change "ConfigSet" to "configset" in docs & specs to match community spelling
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/df57afce
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/df57afce
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/df57afce
Branch: refs/heads/branch_7x
Commit: df57afce9be949aef65330b2fe4243667c13d4c3
Parents: 8c9b00a
Author: Cassandra Targett <ct...@apache.org>
Authored: Thu Apr 19 09:57:50 2018 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri Apr 20 14:29:15 2018 -0500
----------------------------------------------------------------------
solr/solr-ref-guide/src/config-api.adoc | 720 ++++++++++++++-----
.../apispec/cluster.configs.Commands.json | 12 +-
.../apispec/cluster.configs.delete.json | 2 +-
.../src/resources/apispec/cluster.configs.json | 2 +-
4 files changed, 543 insertions(+), 193 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/df57afce/solr/solr-ref-guide/src/config-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-api.adoc b/solr/solr-ref-guide/src/config-api.adoc
index 5220f49..48106c7 100644
--- a/solr/solr-ref-guide/src/config-api.adoc
+++ b/solr/solr-ref-guide/src/config-api.adoc
@@ -22,53 +22,140 @@ This feature is enabled by default and works similarly in both SolrCloud and sta
When using this API, `solrconfig.xml` is not changed. Instead, all edited configuration is stored in a file called `configoverlay.json`. The values in `configoverlay.json` override the values in `solrconfig.xml`.
-== Config API Entry Points
+== Config API Endpoints
-* `/config`: retrieve or modify the config. GET to retrieve and POST for executing commands
-* `/config/overlay`: retrieve the details in the `configoverlay.json` alone
-* `/config/params`: allows creating parameter sets that can override or take the place of parameters defined in `solrconfig.xml`. See the <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> section for more details.
+All Config API endpoints are collection-specific, meaning this API can inspect or modify the configuration for a single collection at a time.
+
+* `_collection_/config`: retrieve the full effective config, or modify the config. Use GET to retrieve and POST for executing commands.
+* `_collection_/config/overlay`: retrieve the details in the `configoverlay.json` only, removing any options defined in `solrconfig.xml` directly or implicitly through defaults.
+* `_collection_/config/params`: create parameter sets that can override or take the place of parameters defined in `solrconfig.xml`. See <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> for more information about this endpoint.
== Retrieving the Config
-All configuration items, can be retrieved by sending a GET request to the `/config` endpoint - the results will be the effective configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml`:
+All configuration items can be retrieved by sending a GET request to the `/config` endpoint:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1getconfig]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2getconfig]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+The response will be the total Solr configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml` and those configured implicitly (by default) by Solr out of the box.
+
+It's possible to restrict the returned config to a top-level section, such as, `query`, `requestHandler` or `updateHandler`. To do this, append the name of the section to the `config` endpoint. For example, to retrieve configuration for all request handlers:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1gethandler]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+http://localhost:8983/solr/techproducts/config/requestHandler
+
+----
+====
+
+[example.tab-pane#v2gethandler]
+====
+[.tab-label]*V2 API*
[source,bash]
----
-curl http://localhost:8983/solr/techproducts/config
+http://localhost:8983/api/collections/techproducts/config/requestHandler
----
+====
+--
-To restrict the returned results to a top level section, e.g., `query`, `requestHandler` or `updateHandler`, append the name of the section to the `/config` endpoint following a slash. For example, to retrieve configuration for all request handlers:
+The output will be details of each request handler defined in `solrconfig.xml`, all <<implicit-requesthandlers.adoc#implicit-requesthandlers,defined implicitly>> by Solr, and all defined with this Config API stored in `configoverlay.json`.
+
+The available top-level sections that can be added as path parameters are: `query`, `requestHandler`, `searchComponent`, `updateHandler`, `queryResponseWriter`, `initParams`, `znodeVersion`, `listener`, `directoryFactory`, `indexConfig`, and `codecFactory`.
+
+To further restrict the request to a single component within a top-level section, use the `componentName` request parameter.
+
+For example, to return configuration for the `/select` request handler:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1getcomponent]
+====
+[.tab-label]*V1 API*
[source,bash]
----
-curl http://localhost:8983/solr/techproducts/config/requestHandler
+http://localhost:8983/solr/techproducts/config/requestHandler?componentName=/select
----
+====
-To further restrict returned results to a single component within a top level section, use the `componentName` request param, e.g., to return configuration for the `/select` request handler:
+[example.tab-pane#v2getcomponent]
+====
+[.tab-label]*V2 API*
[source,bash]
----
-curl http://localhost:8983/solr/techproducts/config/requestHandler?componentName=/select
+http://localhost:8983/api/collections/techproducts/config/requestHandler?componentName=/select
+----
+====
+--
+
+The output of this command will look similar to:
+
+[source,json]
+----
+{
+ "config":{"requestHandler":{"/select":{
+ "name": "/select",
+ "class": "solr.SearchHandler",
+ "defaults":{
+ "echoParams": "explicit",
+ "rows":10,
+ "preferLocalShards":false
+ }}}}
+}
----
+The ability to restrict to objects within a top-level section is limited to request handlers (`requestHandler`), search components (`searchComponent`), and response writers (`queryResponseWriter`).
+
== Commands to Modify the Config
-This API uses specific commands to tell Solr what property or type of property to add to `configoverlay.json`. The commands are passed as part of the data sent with the request.
+This API uses specific commands with POST requests to tell Solr what property or type of property to add to or modify in `configoverlay.json`. The commands are passed with the data to add or modify the property or component.
-The config commands are categorized into 3 different sections which manipulate various data structures in `solrconfig.xml`. Each of these is described below.
+The Config API commands for modifications are categorized into 3 types, each of which manipulate specific data structures in `solrconfig.xml`. These types are:
-* <<Commands for Common Properties,Common Properties>>
-* <<Commands for Custom Handlers and Local Components,Components>>
-* <<Commands for User-Defined Properties,User-defined properties>>
+* `set-property` and `unset-property` for <<Commands for Common Properties,Common Properties>>
+* Component-specific `add-`, `update-`, and `delete-` commands for <<Commands for Handlers and Components,Custom Handlers and Local Components>>
+* `set-user-property` and `unset-user-property` for <<Commands for User-Defined Properties,User-defined properties>>
=== Commands for Common Properties
-The common properties are those that are frequently need to be customized in a Solr instance. They are manipulated with two commands:
+The common properties are those that are frequently customized in a Solr instance. They are manipulated with two commands:
* `set-property`: Set a well known property. The names of the properties are predefined and fixed. If the property has already been set, this command will overwrite the previous setting.
* `unset-property`: Remove a property set using the `set-property` command.
-The properties that are configured with these commands are predefined and listed below. The names of these properties are derived from their XML paths as found in `solrconfig.xml`.
+The properties that can be configured with `set-property` and `unset-property` are predefined and listed below. The names of these properties are derived from their XML paths as found in `solrconfig.xml`.
+
+*Update Handler Settings*
+
+See <<updatehandlers-in-solrconfig.adoc#updatehandlers-in-solrconfig,UpdateHandlers in SolrConfig>> for defaults and acceptable values for these settings.
* `updateHandler.autoCommit.maxDocs`
* `updateHandler.autoCommit.maxTime`
@@ -77,56 +164,170 @@ The properties that are configured with these commands are predefined and listed
* `updateHandler.autoSoftCommit.maxTime`
* `updateHandler.commitWithin.softCommit`
* `updateHandler.indexWriter.closeWaitsForMerges`
+
+*Query Settings*
+
+See <<query-settings-in-solrconfig.adoc#query-settings-in-solrconfig,Query Settings in SolrConfig>> for defaults and acceptable values for these settings.
+
+_Caches and Cache Sizes_
+
* `query.filterCache.class`
* `query.filterCache.size`
* `query.filterCache.initialSize`
* `query.filterCache.autowarmCount`
+* `query.filterCache.maxRamMB`
* `query.filterCache.regenerator`
* `query.queryResultCache.class`
* `query.queryResultCache.size`
* `query.queryResultCache.initialSize`
* `query.queryResultCache.autowarmCount`
+* `query.queryResultCache.maxRamMB`
* `query.queryResultCache.regenerator`
* `query.documentCache.class`
* `query.documentCache.size`
* `query.documentCache.initialSize`
* `query.documentCache.autowarmCount`
-
* `query.documentCache.regenerator`
* `query.fieldValueCache.class`
* `query.fieldValueCache.size`
* `query.fieldValueCache.initialSize`
* `query.fieldValueCache.autowarmCount`
* `query.fieldValueCache.regenerator`
+
+_Query Sizing and Warming_
+
+* `query.maxBooleanClauses`
+* `query.enableLazyFieldLoading`
* `query.useFilterForSortedQuery`
* `query.queryResultWindowSize`
* `query.queryResultMaxDocCached`
-* `query.enableLazyFieldLoading`
-* `query.boolToFilterOptimizer`
-* `query.maxBooleanClauses`
-* `jmx.agentId`
-* `jmx.serviceUrl`
-* `jmx.rootName`
+
+*RequestDispatcher Settings*
+
+See <<requestdispatcher-in-solrconfig.adoc#requestdispatcher-in-solrconfig,RequestDispatcher in SolrConfig>> for defaults and acceptable values for these settings.
+
* `requestDispatcher.handleSelect`
-* `requestDispatcher.requestParsers.multipartUploadLimitInKB`
-* `requestDispatcher.requestParsers.formdataUploadLimitInKB`
* `requestDispatcher.requestParsers.enableRemoteStreaming`
* `requestDispatcher.requestParsers.enableStreamBody`
+* `requestDispatcher.requestParsers.multipartUploadLimitInKB`
+* `requestDispatcher.requestParsers.formdataUploadLimitInKB`
* `requestDispatcher.requestParsers.addHttpRequestToContext`
-=== Commands for Custom Handlers and Local Components
+==== Examples of Common Properties
+
+Constructing a command to modify or add one of these properties follows this pattern:
+
+[source,json,subs="quotes"]
+----
+{"set-property":{"<_property_>": "<_value_>"}}
+----
+
+A request to increase the `updateHandler.autoCommit.maxTime` would look like:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1-setprop]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type: application/json' -d '{"set-property":{"updateHandler.autoCommit.maxTime":15000}}' http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2-setprop]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type: application/json' -d '{"set-property":{"updateHandler.autoCommit.maxTime":15000}}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+You can use the `config/overlay` endpoint to verify the property has been added to `configoverlay.json`:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1overlay]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config/overlay?omitHeader=true
+----
+====
+
+[example.tab-pane#v2overlay]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl http://localhost:8983/api/collections/techproducts/config/overlay?omitHeader=true
+----
+====
+--
+
+Output:
-Custom request handlers, search components, and other types of localized Solr components (such as custom query parsers, update processors, etc.) can be added, updated and deleted with specific commands for the component being modified.
+[source,json]
+----
+{
+ "overlay": {
+ "znodeVersion": 1,
+ "props": {
+ "updateHandler": {
+ "autoCommit": {"maxTime": 15000}
+ }
+}}}
+----
+
+To unset the property:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1unsetprop]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type: application/json' -d '{"unset-property": "updateHandler.autoCommit.maxTime"}' http://localhost:8983/solr/techproducts/config
+----
+====
-The syntax is similar in each case: `add-<component-name>`, `update-<component-name>`, and `delete-<component-name>`. The command name is not case sensitive, so `Add-RequestHandler`, `ADD-REQUESTHANDLER` and `add-requesthandler` are all equivalent.
+[example.tab-pane#v2unsetprop]
+====
+[.tab-label]*V2 API*
-In each case, `add-` commands add the new configuration to `configoverlay.json`, which will override any other settings for the component in `solrconfig.xml`; `update-` commands overwrite an existing setting in `configoverlay.json`; and `delete-` commands remove the setting from `configoverlay.json`.
+[source,bash]
+----
+curl -X POST -H 'Content-type: application/json' -d '{"unset-property": "updateHandler.autoCommit.maxTime"}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+=== Commands for Handlers and Components
+
+Request handlers, search components, and other types of localized Solr components (such as query parsers, update processors, etc.) can be added, updated and deleted with specific commands for the type of component being modified.
-Settings removed from `configoverlay.json` are not removed from `solrconfig.xml`.
+The syntax is similar in each case: `add-<component-name>`, `update-_<component-name>_`, and `delete-<component-name>`. The command name is not case sensitive, so `Add-RequestHandler`, `ADD-REQUESTHANDLER` and `add-requesthandler` are equivalent.
+
+In each case, `add-` commands add a new configuration to `configoverlay.json`, which will override any other settings for the component in `solrconfig.xml`.
+
+`update-` commands overwrite an existing setting in `configoverlay.json`.
+
+`delete-` commands remove the setting from `configoverlay.json`.
+
+Settings removed from `configoverlay.json` are not removed from `solrconfig.xml` if they happen to be duplicated there.
The full list of available commands follows below:
-==== General Purpose Commands
+==== Basic Commands for Components
These commands are the most commonly used:
@@ -143,7 +344,7 @@ These commands are the most commonly used:
* `update-queryresponsewriter`
* `delete-queryresponsewriter`
-==== Advanced Commands
+==== Advanced Commands for Components
These commands allow registering more advanced customizations to Solr:
@@ -159,7 +360,6 @@ These commands allow registering more advanced customizations to Solr:
* `add-updateprocessor`
* `update-updateprocessor`
* `delete-updateprocessor`
-
* `add-queryconverter`
* `update-queryconverter`
* `delete-queryconverter`
@@ -170,23 +370,159 @@ These commands allow registering more advanced customizations to Solr:
* `update-runtimelib`
* `delete-runtimelib`
-See the section <<Creating and Updating Request Handlers>> below for examples of using these commands.
+==== Examples of Handler and Component Commands
-==== What about updateRequestProcessorChain?
+To create a request handler, we can use the `add-requesthandler` command:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{
+ "add-requesthandler": {
+ "name": "/mypath",
+ "class": "solr.DumpRequestHandler",
+ "defaults":{ "x": "y" ,"a": "b", "rows":10 },
+ "useParams": "x"
+ }
+}' http://localhost:8983/solr/techproducts/config
+----
-The Config API does not let you create or edit `updateRequestProcessorChain` elements. However, it is possible to create `updateProcessor` entries and can use them by name to create a chain.
+[.dynamic-tabs]
+--
+[example.tab-pane#v1addhandler]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{
+ "add-requesthandler": {
+ "name": "/mypath",
+ "class": "solr.DumpRequestHandler",
+ "defaults": { "x": "y" ,"a": "b", "rows":10 },
+ "useParams": "x"
+ }
+}' http://localhost:8983/solr/techproducts/config
+----
+====
-example:
+[example.tab-pane#v2addhandler]
+====
+[.tab-label]*V2 API*
[source,bash]
----
-curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
-"add-updateprocessor" : { "name" : "firstFld",
- "class": "solr.FirstFieldValueUpdateProcessorFactory",
- "fieldName":"test_s"}}'
+curl -X POST -H 'Content-type:application/json' -d '{
+ "add-requesthandler": {
+ "name": "/mypath",
+ "class": "solr.DumpRequestHandler",
+ "defaults": { "x": "y" ,"a": "b", "rows":10 },
+ "useParams": "x"
+ }
+}' http://localhost:8983/api/collections/techproducts/config
----
+====
+--
-You can use this directly in your request by adding a parameter in the `updateRequestProcessorChain` for the specific update processor called `processor=firstFld`.
+Make a call to the new request handler to check if it is registered:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/mypath?omitHeader=true
+----
+
+And you should see the following as output:
+
+[source,json]
+----
+{
+ "params":{
+ "indent": "true",
+ "a": "b",
+ "x": "y",
+ "rows": "10"},
+ "context":{
+ "webapp": "/solr",
+ "path": "/mypath",
+ "httpMethod": "GET"}}
+----
+
+To update a request handler, you should use the `update-requesthandler` command:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1updatehandler]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{
+ "update-requesthandler": {
+ "name": "/mypath",
+ "class": "solr.DumpRequestHandler",
+ "defaults": {"x": "new value for X", "rows": "20"},
+ "useParams": "x"
+ }
+}' http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2updatehandler]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{
+ "update-requesthandler": {
+ "name": "/mypath",
+ "class": "solr.DumpRequestHandler",
+ "defaults": {"x": "new value for X", "rows": "20"},
+ "useParams": "x"
+ }
+}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+As a second example, we'll create another request handler, this time adding the 'terms' component as part of the definition:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1add-handler]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{
+ "add-requesthandler": {
+ "name": "/myterms",
+ "class": "solr.SearchHandler",
+ "defaults": {"terms": true, "distrib":false},
+ "components": ["terms"]
+ }
+}' http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2add-handler]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{
+ "add-requesthandler": {
+ "name": "/myterms",
+ "class": "solr.SearchHandler",
+ "defaults": {"terms": true, "distrib":false},
+ "components": ["terms"]
+ }
+}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
=== Commands for User-Defined Properties
@@ -195,12 +531,139 @@ Solr lets users templatize the `solrconfig.xml` using the place holder format `$
* `set-user-property`: Set a user-defined property. If the property has already been set, this command will overwrite the previous setting.
* `unset-user-property`: Remove a user-defined property.
-The structure of the request is similar to the structure of requests using other commands, in the format of `"command":{"variable_name":"property_value"}`. You can add more than one variable at a time if necessary.
+The structure of the request is similar to the structure of requests using other commands, in the format of `"command":{"variable_name": "property_value"}`. You can add more than one variable at a time if necessary.
For more information about user-defined properties, see the section <<configuring-solrconfig-xml.adoc#user-defined-properties-in-core-properties,User defined properties in core.properties>>.
See also the section <<Creating and Updating User-Defined Properties>> below for examples of how to use this type of command.
+==== Creating and Updating User-Defined Properties
+
+This command sets a user property.
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1userprop]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{"set-user-property": {"variable_name": "some_value"}}' http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2userprop]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{"set-user-property": {"variable_name": "some_value"}}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+Again, we can use the `/config/overlay` endpoint to verify the changes have been made:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1useroverlay]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config/overlay?omitHeader=true
+----
+====
+
+[example.tab-pane#v2useroverlay]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl http://localhost:8983/api/collections/techproducts/config/overlay?omitHeader=true
+----
+====
+--
+
+And we would expect to see output like this:
+
+[source,json]
+----
+{"overlay":{
+ "znodeVersion":5,
+ "userProps":{
+ "variable_name": "some_value"}}
+}
+----
+
+To unset the variable, issue a command like this:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1unsetuser]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{"unset-user-property": "variable_name"}' http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2unsetuser]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{"unset-user-property": "variable_name"}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+=== What about updateRequestProcessorChain?
+
+The Config API does not let you create or edit `updateRequestProcessorChain` elements. However, it is possible to create `updateProcessor` entries and use them by name to create a chain.
+
+For example:
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1addupdateproc]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{"add-updateprocessor":
+ {"name": "firstFld",
+ "class": "solr.FirstFieldValueUpdateProcessorFactory",
+ "fieldName": "test_s"}
+}' http://localhost:8983/solr/techproducts/config
+----
+====
+
+[example.tab-pane#v2addupdateproc]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' -d '{"add-updateprocessor":
+ {"name": "firstFld",
+ "class": "solr.FirstFieldValueUpdateProcessorFactory",
+ "fieldName": "test_s"}
+}' http://localhost:8983/api/collections/techproducts/config
+----
+====
+--
+
+You can use this directly in your request by adding a parameter in the `updateRequestProcessorChain` for the specific update processor called `processor=firstFld`.
+
== How to Map solrconfig.xml Properties to JSON
By using this API, you will be generating JSON representations of properties defined in `solrconfig.xml`. To understand how properties should be represented with the API, let's take a look at a few examples.
@@ -223,10 +686,10 @@ The same request handler defined with the Config API would look like this:
----
{
"add-requesthandler":{
- "name":"/query",
- "class":"solr.SearchHandler",
+ "name": "/query",
+ "class": "solr.SearchHandler",
"defaults":{
- "echoParams":"explicit",
+ "echoParams": "explicit",
"rows": 10
}
}
@@ -249,10 +712,10 @@ And the same searchComponent with the Config API:
----
{
"add-searchcomponent":{
- "name":"elevator",
- "class":"solr.QueryElevationComponent",
- "queryFieldType":"string",
- "config-file":"elevate.xml"
+ "name": "elevator",
+ "class": "solr.QueryElevationComponent",
+ "queryFieldType": "string",
+ "config-file": "elevate.xml"
}
}
----
@@ -262,7 +725,7 @@ Removing the searchComponent with the Config API:
[source,json]
----
{
- "delete-searchcomponent":"elevator"
+ "delete-searchcomponent": "elevator"
}
----
@@ -354,154 +817,41 @@ Define the same properties with the Config API:
The Config API always allows changing the configuration of any component by name. However, some configurations such as `listener` or `initParams` do not require a name in `solrconfig.xml`. In order to be able to `update` and `delete` of the same item in `configoverlay.json`, the name attribute becomes mandatory.
-== Config API Examples
-
-=== Creating and Updating Common Properties
-
-This change sets the `query.filterCache.autowarmCount` to 1000 items and unsets the `query.filterCache.size`.
-
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d'{
- "set-property" : {"query.filterCache.autowarmCount":1000},
- "unset-property" :"query.filterCache.size"}'
-----
-
-Using the `/config/overlay` endpoint, you can verify the changes with a request like this:
-
-[source,bash]
-----
-curl http://localhost:8983/solr/gettingstarted/config/overlay?omitHeader=true
-----
-
-And you should get a response like this:
-
-[source,json]
-----
-{
- "overlay":{
- "znodeVersion":1,
- "props":{"query":{"filterCache":{
- "autowarmCount":1000,
- "size":25}}}}}
-----
-
-=== Creating and Updating Request Handlers
-
-To create a request handler, we can use the `add-requesthandler` command:
-
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
- "add-requesthandler" : {
- "name": "/mypath",
- "class":"solr.DumpRequestHandler",
- "defaults":{ "x":"y" ,"a":"b", "rows":10 },
- "useParams":"x"
- }
-}'
-----
-
-Make a call to the new request handler to check if it is registered:
-
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/mypath?omitHeader=true
-----
-
-And you should see the following as output:
-
-[source,json]
-----
-{
- "params":{
- "indent":"true",
- "a":"b",
- "x":"y",
- "rows":"10"},
- "context":{
- "webapp":"/solr",
- "path":"/mypath",
- "httpMethod":"GET"}}
-----
-
-To update a request handler, you should use the `update-requesthandler` command:
-
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
- "update-requesthandler": {
- "name": "/mypath",
- "class":"solr.DumpRequestHandler",
- "defaults": {"x":"new value for X", "rows":"20"},
- "useParams":"x"
- }
-}'
-----
-
-As another example, we'll create another request handler, this time adding the 'terms' component as part of the definition:
-
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
- "add-requesthandler": {
- "name": "/myterms",
- "class":"solr.SearchHandler",
- "defaults": {"terms":true, "distrib":false},
- "components": [ "terms" ]
- }
-}'
-----
-
-=== Creating and Updating User-Defined Properties
-This command sets a user property.
+== How the Config API Works
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{
- "set-user-property" : {"variable_name":"some_value"}}'
-----
+Every core watches the ZooKeeper directory for the configset being used with that core. In standalone mode, however, there is no watch (because ZooKeeper is not running). If there are multiple cores in the same node using the same configset, only one ZooKeeper watch is used.
-Again, we can use the `/config/overlay` endpoint to verify the changes have been made:
+For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`. Every write operation performed through the API would 'touch' the directory and all watchers are notified. Every core would check if the schema file, `solrconfig.xml`, or `configoverlay.json` has been modified by comparing the `znode` versions. If any have been modified, the core is reloaded.
-[source,bash]
-----
-curl http://localhost:8983/solr/techproducts/config/overlay?omitHeader=true
-----
+If `params.json` is modified, the params object is just updated without a core reload (see <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> for more information about `params.json`).
-And we would expect to see output like this:
+=== Empty Command
-[source,json]
-----
-{"overlay":{
- "znodeVersion":5,
- "userProps":{
- "variable_name":"some_value"}}
-}
-----
+If an empty command is sent to the `/config` endpoint, the watch is triggered on all cores using this configset. For example:
-To unset the variable, issue a command like this:
+[.dynamic-tabs]
+--
+[example.tab-pane#v1empty]
+====
+[.tab-label]*V1 API*
[source,bash]
----
-curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{"unset-user-property" : "variable_name"}'
+curl -X POST -H 'Content-type:application/json' -d '{}' http://localhost:8983/solr/techproducts/config
----
+====
-== How the Config API Works
-
-Every core watches the ZooKeeper directory for the configset being used with that core. In standalone mode, however, there is no watch (because ZooKeeper is not running). If there are multiple cores in the same node using the same configset, only one ZooKeeper watch is used. For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`. Every write operation performed through the API would 'touch' the directory (sets an empty byte[] to trigger watches) and all watchers are notified. Every core would check if the Schema file, `solrconfig.xml` or `configoverlay.json` is modified by comparing the `znode` versions and if modified, the core is reloaded.
-
-If `params.json` is modified, the params object is just updated without a core reload (see the section <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> for more information about `params.json`).
-
-=== Empty Command
-
-If an empty command is sent to the `/config` endpoint, the watch is triggered on all cores using this configset. For example:
+[example.tab-pane#v2empty]
+====
+[.tab-label]*V2 API*
[source,bash]
----
-curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{}'
+curl -X POST -H 'Content-type:application/json' -d '{}' http://localhost:8983/api/collections/techproducts/config
----
+====
+--
Directly editing any files without 'touching' the directory *will not* make it visible to all nodes.
@@ -513,4 +863,4 @@ Any component can register a listener using:
`SolrCore#addConfListener(Runnable listener)`
-to get notified for config changes. This is not very useful if the files modified result in core reloads (i.e., `configoverlay.xml` or Schema). Components can use this to reload the files they are interested in.
+to get notified for config changes. This is not very useful if the files modified result in core reloads (i.e., `configoverlay.xml` or the schema). Components can use this to reload the files they are interested in.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/df57afce/solr/solrj/src/resources/apispec/cluster.configs.Commands.json
----------------------------------------------------------------------
diff --git a/solr/solrj/src/resources/apispec/cluster.configs.Commands.json b/solr/solrj/src/resources/apispec/cluster.configs.Commands.json
index 065f175..3792686 100644
--- a/solr/solrj/src/resources/apispec/cluster.configs.Commands.json
+++ b/solr/solrj/src/resources/apispec/cluster.configs.Commands.json
@@ -1,6 +1,6 @@
{
- "documentation": "https://lucene.apache.org/solr/guide/configsets-api.html",
- "description": "Create ConfigSets.",
+ "documentation": "https://lucene.apache.org/solr/guide/configsets-api.html#configsets-create",
+ "description": "Create configsets.",
"methods": [
"POST"
],
@@ -11,20 +11,20 @@
"commands": {
"create": {
"type" :"object",
- "description": "Create a ConfigSet, based on another ConfigSet already in ZooKeeper.",
+ "description": "Create a configset, based on another configset already in ZooKeeper.",
"documentation": "https://lucene.apache.org/solr/guide/configsets-api.html#configsets-create",
"properties": {
"name" :{
"type" :"string",
- "description" : "The name of the ConfigSet to be created."
+ "description" : "The name of the configset to be created."
},
"baseConfigSet":{
"type" : "string",
- "description" :"The existing ConfigSet to copy as the basis for the new one."
+ "description" :"The existing configset to copy as the basis for the new one."
},
"properties" : {
"type":"object",
- "description": "Additional key-value pairs, in the form of 'ConfigSetProp.<key>=<value>', as needed. These properties will override the same properties in the base ConfigSet.",
+ "description": "Additional key-value pairs, in the form of 'ConfigSetProp.<key>=<value>', as needed. These properties will override the same properties in the base configset.",
"additionalProperties" : true
}
},
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/df57afce/solr/solrj/src/resources/apispec/cluster.configs.delete.json
----------------------------------------------------------------------
diff --git a/solr/solrj/src/resources/apispec/cluster.configs.delete.json b/solr/solrj/src/resources/apispec/cluster.configs.delete.json
index a03ba4b..20985b8 100644
--- a/solr/solrj/src/resources/apispec/cluster.configs.delete.json
+++ b/solr/solrj/src/resources/apispec/cluster.configs.delete.json
@@ -1,6 +1,6 @@
{
"documentation": "https://lucene.apache.org/solr/guide/configsets-api.html#configsets-delete",
- "description": "Delete ConfigSets. The name of the ConfigSet to delete must be provided as a path parameter.",
+ "description": "Delete configsets. The name of the configset to delete must be provided as a path parameter.",
"methods": [
"DELETE"
],
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/df57afce/solr/solrj/src/resources/apispec/cluster.configs.json
----------------------------------------------------------------------
diff --git a/solr/solrj/src/resources/apispec/cluster.configs.json b/solr/solrj/src/resources/apispec/cluster.configs.json
index 55fc8b6..45d91d9 100644
--- a/solr/solrj/src/resources/apispec/cluster.configs.json
+++ b/solr/solrj/src/resources/apispec/cluster.configs.json
@@ -1,6 +1,6 @@
{
"documentation": "https://lucene.apache.org/solr/guide/configsets-api.html#configsets-list",
- "description": "List all ConfigSets in the cluster.",
+ "description": "List all configsets in the cluster.",
"methods": [
"GET"
],
[2/2] lucene-solr:branch_7x: SOLR-11646: more v2 examples;
redesign Implicit Handler page to add v2 api paths where they exist
Posted by ct...@apache.org.
SOLR-11646: more v2 examples; redesign Implicit Handler page to add v2 api paths where they exist
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/5915e61e
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/5915e61e
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/5915e61e
Branch: refs/heads/branch_7x
Commit: 5915e61e42aa0311b8b574949fed8a2ec566a502
Parents: df57afc
Author: Cassandra Targett <ct...@apache.org>
Authored: Fri Apr 20 14:27:34 2018 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri Apr 20 14:29:25 2018 -0500
----------------------------------------------------------------------
solr/solr-ref-guide/src/about-this-guide.adoc | 2 +
solr/solr-ref-guide/src/blob-store-api.adoc | 96 ++++-
solr/solr-ref-guide/src/config-api.adoc | 6 +-
solr/solr-ref-guide/src/config-sets.adoc | 36 +-
solr/solr-ref-guide/src/configsets-api.adoc | 244 +++++++-----
.../src/configuring-solrconfig-xml.adoc | 42 ++-
.../src/implicit-requesthandlers.adoc | 374 ++++++++++++++++---
.../src/requestdispatcher-in-solrconfig.adoc | 2 +-
8 files changed, 629 insertions(+), 173 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/about-this-guide.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/about-this-guide.adoc b/solr/solr-ref-guide/src/about-this-guide.adoc
index 3d7fc24..956d361 100644
--- a/solr/solr-ref-guide/src/about-this-guide.adoc
+++ b/solr/solr-ref-guide/src/about-this-guide.adoc
@@ -60,6 +60,8 @@ Throughout this Guide, we have added examples of both styles with sections label
The section <<v2-api.adoc#v2-api,V2 API>> provides more information about how to work with the new API structure, including how to disable it if you choose to do so.
+All APIs return a response header that includes the status of the request and the time to process it. Some APIs will also include the parameters used for the request. Many of the examples in this Guide omit this header information, which you can do locally by adding the parameter `omitHeader=true` to any request.
+
== Special Inline Notes
Special notes are included throughout these pages. There are several types of notes:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/blob-store-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/blob-store-api.adoc b/solr/solr-ref-guide/src/blob-store-api.adoc
index dd92141..77cb2c4 100644
--- a/solr/solr-ref-guide/src/blob-store-api.adoc
+++ b/solr/solr-ref-guide/src/blob-store-api.adoc
@@ -34,7 +34,7 @@ The BlobHandler is automatically registered in the .system collection. The `solr
If you do not use the `-shards` or `-replicationFactor` options, then defaults of numShards=1 and replicationFactor=3 (or maximum nodes in the cluster) will be used.
-You can create the `.system` collection with the <<collections-api.adoc#collections-api,Collections API>>, as in this example:
+You can create the `.system` collection with the <<collections-api.adoc#create,CREATE command>> of the Collections API, as in this example:
[.dynamic-tabs]
--
@@ -44,8 +44,10 @@ You can create the `.system` collection with the <<collections-api.adoc#collecti
[source,bash]
----
-curl http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&replicationFactor=2
+curl http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&replicationFactor=2&numShards=2
----
+
+Note that this example will create the .system collection across 2 shards with a replication factor of 2; you may need to customize this for your Solr implementation.
====
[example.tab-pane#v2create]
@@ -54,8 +56,10 @@ curl http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&rep
[source,bash]
----
-curl -X POST -H 'Content-type: application/json' -d '{"create":{"name":".system", "replicationFactor": 2}}' http://localhost:8983/api/collections
+curl -X POST -H 'Content-type: application/json' -d '{"create": {"name": ".system", "numShards": "2", "replicationFactor": "2"}}' http://localhost:8983/api/collections
----
+
+Note that this example will create the .system collection across 2 shards with a replication factor of 2; you may need to customize this for your Solr implementation.
====
--
@@ -65,6 +69,12 @@ IMPORTANT: The `bin/solr` script cannot be used to create the `.system` collecti
After the `.system` collection has been created, files can be uploaded to the blob store with a request similar to the following:
+[.dynamic-tabs]
+--
+[example.tab-pane#v1upload]
+====
+[.tab-label]*V1 API*
+
[source,bash]
----
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @{filename} http://localhost:8983/solr/.system/blob/{blobname}
@@ -76,14 +86,48 @@ For example, to upload a file named "test1.jar" as a blob named "test", you woul
----
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @test1.jar http://localhost:8983/solr/.system/blob/test
----
+====
+
+[example.tab-pane#v2upload]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @{filename} http://localhost:8983/api/collections/.system/blob/{blobname}
+----
+
+For example, to upload a file named "test1.jar" as a blob named "test", you would make a POST request like:
+
+[source,bash]
+----
+curl -X POST -H 'Content-Type: application/octet-stream' --data-binary @test1.jar http://localhost:8983/api/collections/.system/blob/test
+----
+====
+--
A GET request will return the list of blobs and other details:
+[.dynamic-tabs]
+--
+[example.tab-pane#v1getblob]
+====
+[.tab-label]*V1 API*
+
+For all blobs:
+
[source,bash]
----
curl http://localhost:8983/solr/.system/blob?omitHeader=true
----
+For a single blob:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/.system/blob/test?omitHeader=true
+----
+
Output:
[source,json]
@@ -100,19 +144,24 @@ Output:
}
}
----
+====
+
+[example.tab-pane#v2getblob]
+====
+[.tab-label]*V2 API*
-Details on individual blobs can be accessed with a request similar to:
+For all blobs:
[source,bash]
----
-curl http://localhost:8983/solr/.system/blob/{blobname}
+curl http://localhost:8983/api/collections/.system/blob?omitHeader=true
----
-For example, this request will return only the blob named 'test':
+For a single blob:
[source,bash]
----
-curl http://localhost:8983/solr/.system/blob/test?omitHeader=true
+curl http://localhost:8983/api/collections/.system/blob/test?omitHeader=true
----
Output:
@@ -131,20 +180,49 @@ Output:
}
}
----
+====
+--
+
+The filestream response writer can retrieve a blob for download, as in:
-The filestream response writer can return a particular version of a blob for download, as in:
+[.dynamic-tabs]
+--
+[example.tab-pane#v1retrieveblob]
+====
+[.tab-label]*V1 API*
+For a specific version of a blob, include the version to the request:
[source,bash]
----
curl http://localhost:8983/solr/.system/blob/{blobname}/{version}?wt=filestream > {outputfilename}
----
-For the latest version of a blob, the \{version} can be omitted,
+For the latest version of a blob, the `\{version}` can be omitted:
[source,bash]
----
curl http://localhost:8983/solr/.system/blob/{blobname}?wt=filestream > {outputfilename}
----
+====
+
+[example.tab-pane#v2retrieveblob]
+====
+[.tab-label]*V2 API*
+For a specific version of a blob, include the version to the request:
+
+[source,bash]
+----
+curl http://localhost:8983/api/collections/.system/blob/{blobname}/{version}?wt=filestream > {outputfilename}
+----
+
+For the latest version of a blob, the `\{version}` can be omitted:
+
+[source,bash]
+----
+curl http://localhost:8983/api/collections/.system/blob/{blobname}?wt=filestream > {outputfilename}
+----
+====
+--
== Use a Blob in a Handler or Component
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/config-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-api.adoc b/solr/solr-ref-guide/src/config-api.adoc
index 48106c7..f6295cc 100644
--- a/solr/solr-ref-guide/src/config-api.adoc
+++ b/solr/solr-ref-guide/src/config-api.adoc
@@ -57,7 +57,8 @@ http://localhost:8983/api/collections/techproducts/config
====
--
-The response will be the total Solr configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml` and those configured implicitly (by default) by Solr out of the box.
+The response will be the Solr configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml`.
+
It's possible to restrict the returned config to a top-level section, such as, `query`, `requestHandler` or `updateHandler`. To do this, append the name of the section to the `config` endpoint. For example, to retrieve configuration for all request handlers:
@@ -70,7 +71,6 @@ It's possible to restrict the returned config to a top-level section, such as, `
[source,bash]
----
http://localhost:8983/solr/techproducts/config/requestHandler
-
----
====
@@ -85,7 +85,7 @@ http://localhost:8983/api/collections/techproducts/config/requestHandler
====
--
-The output will be details of each request handler defined in `solrconfig.xml`, all <<implicit-requesthandlers.adoc#implicit-requesthandlers,defined implicitly>> by Solr, and all defined with this Config API stored in `configoverlay.json`.
+The output will be details of each request handler defined in `solrconfig.xml`, all <<implicit-requesthandlers.adoc#implicit-requesthandlers,defined implicitly>> by Solr, and all defined with this Config API stored in `configoverlay.json`. To see the configuration for implicit request handlers, add `expandParams=true` to the request. See the documentation for the implicit request handlers for examples using this command.
The available top-level sections that can be added as path parameters are: `query`, `requestHandler`, `searchComponent`, `updateHandler`, `queryResponseWriter`, `initParams`, `znodeVersion`, `listener`, `directoryFactory`, `indexConfig`, and `codecFactory`.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/config-sets.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-sets.adoc b/solr/solr-ref-guide/src/config-sets.adoc
index 12c6cd14..b61be18 100644
--- a/solr/solr-ref-guide/src/config-sets.adoc
+++ b/solr/solr-ref-guide/src/config-sets.adoc
@@ -18,7 +18,15 @@
On a multicore Solr instance, you may find that you want to share configuration between a number of different cores. You can achieve this using named configsets, which are essentially shared configuration directories stored under a configurable configset base directory.
-To create a configset, simply add a new directory under the configset base directory. The configset will be identified by the name of this directory. Then into this copy the config directory you want to share. The structure should look something like this:
+Configsets are made up of the configuration files used in a Solr installation: inclduding `solrconfig.xml`, the schema, language-files, `synonyms.txt`, DIH-related configuration, and others as needed for your implementation.
+
+Solr ships with two example configsets located in `server/solr/configsets`, which can be used as a base for your own. These example configsets are named `_default` and `sample_techproducts_configs`.
+
+== Configsets in Standalone Mode
+
+If you are using Solr in standalone mode, configsets are created on the filesystem.
+
+To create a configset, add a new directory under the configset base directory. The configset will be identified by the name of this directory. Then into this copy the config directory you want to share. The structure should look something like this:
[source,bash]
----
@@ -33,25 +41,39 @@ To create a configset, simply add a new directory under the configset base direc
/solrconfig.xml
----
-The default base directory is `$SOLR_HOME/configsets`, and it can be configured in `solr.xml`.
+The default base directory is `$SOLR_HOME/configsets`. This path can be configured in `solr.xml` (see <<format-of-solr-xml.adoc#format-of-solr-xml,Format of solr.xml>> for details).
To create a new core using a configset, pass `configSet` as one of the core properties. For example, if you do this via the CoreAdmin API:
[.dynamic-tabs]
--
-[example.tab-pane#v1api]
+[example.tab-pane#v1use-configset]
====
[.tab-label]*V1 API*
-[source,text]
+[source,bash]
+----
curl http://localhost:8983/admin/cores?action=CREATE&name=mycore&instanceDir=path/to/instance&configSet=configset2
+----
====
-[example.tab-pane#v2api]
+[example.tab-pane#v2use-configset]
====
[.tab-label]*V2 API*
-[source,text]
-curl -v -X POST -H 'Content-type: application/json' -d '{"create":[{"name":"mycore", "instanceDir":"path/to/instance", "configSet":"configSet2"}]}' http://localhost:8983/api/cores
+
+[source,bash]
+----
+curl -v -X POST -H 'Content-type: application/json' -d '{
+ "create":[{
+ "name": "mycore",
+ "instanceDir": "path/to/instance",
+ "configSet": "configSet2"}]}'
+ http://localhost:8983/api/cores
+----
====
--
+
+== Configsets in SolrCloud Mode
+
+In SolrCloud mode, you can use the <<configsets-api.adoc#configsets-api,Configsets API>> to manage your configsets.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/configsets-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configsets-api.adoc b/solr/solr-ref-guide/src/configsets-api.adoc
index 59b4925..ba42b79 100644
--- a/solr/solr-ref-guide/src/configsets-api.adoc
+++ b/solr/solr-ref-guide/src/configsets-api.adoc
@@ -1,4 +1,4 @@
-= ConfigSets API
+= Configsets API
:page-toclevels: 1
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
@@ -17,94 +17,155 @@
// specific language governing permissions and limitations
// under the License.
-The ConfigSets API enables you to create, delete, and otherwise manage ConfigSets.
+The Configsets API enables you to upload new configsets to ZooKeeper, create, and delete configsets when Solr is running SolrCloud mode.
-To use a ConfigSet created with this API as the configuration for a collection, use the <<collections-api.adoc#collections-api,Collections API>>.
+Configsets are a collection of configuration files such as `solrconfig.xml`, `synonyms.txt`, the schema, language-specific files, DIH-related configuration, and other collection-level configuration files (everything that normally lives in the `conf` directory). Solr ships with two example configsets (`_default` and `sample_techproducts_configs`) which can be used when creating collections. Using the same concept, you can create your own configsets and make them available when creating collections.
-This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <<config-sets.adoc#config-sets,Config Sets>>.
+This API provides a way to upload configuration files to ZooKeeper and share the same set of configuration files between two or more collections.
-== ConfigSets API Entry Points
+Once a configset has been uploaded to ZooKeeper, use the configset name when creating the collection with the <<collections-api.adoc#collections-api,Collections API>> and the collection will use your configuration files.
-The base URL for all API calls is `\http://<hostname>:<port>/solr`.
+Configsets do not have to be shared between collections if they are uploaded with this API, but this API makes it easier to do so if you wish. An alternative to uploading your configsets in advance would be to put the configuration files into a directory under `server/solr/configsets` and using the directory name as the `-d` parameter when using `bin/solr create` to create a collection.
-* `/admin/configs?action=CREATE`: <<configsets-create,create>> a ConfigSet, based on an existing ConfigSet
-* `/admin/configs?action=DELETE`: <<configsets-delete,delete>> a ConfigSet
-* `/admin/configs?action=LIST`: <<configsets-list,list>> all ConfigSets
-* `/admin/configs?action=UPLOAD`: <<configsets-upload,upload>> a ConfigSet
+NOTE: This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <<config-sets.adoc#config-sets,Config Sets>>.
-[[configsets-create]]
-== Create a ConfigSet
+The API works by passing commands to the `configs` endpoint. The path to the endpoint varies depending on the API being used: the v1 API uses `solr/admin/configs`, while the v2 API uses `api/cluster/configs`. Examples of both types are provided below.
-`/admin/configs?action=CREATE&name=_name_&baseConfigSet=_baseConfigSet_`
+[[configsets-list]]
+== List Configsets
-Create a ConfigSet, based on an existing ConfigSet.
+The `list` command fetches the names of the configsets that are available for use during collection creation.
-=== Create ConfigSet Parameters
+[.dynamic-tabs]
+--
+[example.tab-pane#v1listconfigset]
+====
+[.tab-label]*V1 API*
-The following parameters are supported when creating a ConfigSet.
+With the v1 API, the `list` command must be capitalized as `LIST`:
-name::
-The ConfigSet to be created. This parameter is required.
+[source,bash]
+----
+http://localhost:8983/solr/admin/configs?action=LIST&omitHeader=true
-baseConfigSet::
-The ConfigSet to copy as a base. This parameter is required.
+----
+====
+
+[example.tab-pane#v2listconfigset]
+====
+[.tab-label]*V2 API*
+
+With the v2 API, the `list` command is implied when there is no data sent with the request.
+
+[source,bash]
+----
+http://localhost:8983/api/cluster/configs?omitHeader=true
+----
+====
+--
+
+The output will look like:
+
+[source,json]
+----
+{
+ "configSets": [
+ "_default",
+ "techproducts",
+ "gettingstarted"
+ ]
+}
+----
-configSetProp._name_=_value_::
-Any ConfigSet property from base to override.
+[[configsets-upload]]
+== Upload a Configset
-=== Create ConfigSet Response
+Upload a configset, which is sent as a zipped file.
-The response will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
+A configset is uploaded in a "trusted" mode if authentication is enabled and the upload operation is performed as an authenticated request. Without authentication, a configset is uploaded in an "untrusted" mode. Upon creation of a collection using an "untrusted" configset, the following functionality will not work:
-=== Create ConfigSet Examples
+* If specified in the configset, the DataImportHandler's ScriptTransformer will not initialize.
+* The XSLT transformer (`tr` parameter) cannot be used at request processing time.
+* If specified in the configset, the StatelessScriptUpdateProcessor will not initialize.
-*Input*
+If you use any of these parameters or features, you must have enabled security features in your Solr installation and you must upload the configset as an authenticated user.
-Create a ConfigSet named 'myConfigSet' based on a 'predefinedTemplate' ConfigSet, overriding the immutable property to false.
+The `upload` command takes one parameter:
+
+name::
+The configset to be created when the upload is complete. This parameter is required.
-[source,text]
+The body of the request should be a zip file that contains the configset. The zip file must be created from within the `conf` directory (i.e., `solrconfig.xml` must be the top level entry in the zip file).
+
+Here is an example on how to create the zip file named "myconfig.zip" and upload it as a config set named "myConfigSet":
+
+[source,bash]
----
-http://localhost:8983/solr/admin/configs?action=CREATE&name=myConfigSet&baseConfigSet=predefinedTemplate&configSetProp.immutable=false&wt=xml
+$ (cd solr/server/solr/configsets/sample_techproducts_configs/conf && zip -r - *) > myconfigset.zip
+
+$ curl -X POST --header "Content-Type:application/octet-stream" --data-binary @myconfigset.zip "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet"
----
-*Output*
+The same can be achieved using a Unix pipe with a single request as follows:
-[source,xml]
+[source,bash]
----
-<response>
- <lst name="responseHeader">
- <int name="status">0</int>
- <int name="QTime">323</int>
- </lst>
-</response>
+$ (cd server/solr/configsets/sample_techproducts_configs/conf && zip -r - *) | curl -X POST --header "Content-Type:application/octet-stream" --data-binary @- "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet"
----
-[[configsets-delete]]
-== Delete a ConfigSet
+NOTE: The `UPLOAD` command does not yet have a v2 equivalent API.
-`/admin/configs?action=DELETE&name=_name_`
+[[configsets-create]]
+== Create a Configset
+
+The `create` command creates a new configset based on a configset that has been previously uploaded.
-Delete a ConfigSet
+If you have not yet uploaded any configsets, see the <<Upload a Configset>> command above.
-=== Delete ConfigSet Parameters
+The following parameters are supported when creating a configset.
name::
-The ConfigSet to be deleted. This parameter is required.
+The configset to be created. This parameter is required.
-=== Delete ConfigSet Response
+baseConfigSet::
+The name of the configset to copy as a base. This parameter is required.
-The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
+configSetProp._property_=_value_::
+A configset property from the base configset to override in the copied configset.
-=== Delete ConfigSet Examples
+For example, to create a configset named "myConfigset" based on a previously defined "predefinedTemplate" configset, overriding the immutable property to false.
-*Input*
+[.dynamic-tabs]
+--
+[example.tab-pane#v1createconfigset]
+====
+[.tab-label]*V1 API*
-Delete ConfigSet 'myConfigSet'
+With the v1 API, the `create` command must be capitalized as `CREATE`:
-[source,text]
+[source,bash]
----
-http://localhost:8983/solr/admin/configs?action=DELETE&name=myConfigSet&wt=xml
+http://localhost:8983/solr/admin/configs?action=CREATE&name=myConfigSet&baseConfigSet=predefinedTemplate&configSetProp.immutable=false&wt=xml&omitHeader=true
----
+====
+
+[example.tab-pane#v2createconfigset]
+====
+[.tab-label]*V2 API*
+
+With the v2 API, the `create` command is provided as part of the JSON data that contains the required parameters:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type: application/json' -d '{
+ "create":{
+ "name": "myConfigSet",
+ "baseConfigSet": "predefinedTemplate",
+ "configSetProp.immutable": "false"}}'
+ http://localhost:8983/api/cluster/configs?omitHeader=true
+----
+====
+--
*Output*
@@ -113,75 +174,56 @@ http://localhost:8983/solr/admin/configs?action=DELETE&name=myConfigSet&wt=xml
<response>
<lst name="responseHeader">
<int name="status">0</int>
- <int name="QTime">170</int>
+ <int name="QTime">323</int>
</lst>
</response>
----
-[[configsets-list]]
-== List ConfigSets
+[[configsets-delete]]
+== Delete a Configset
-`/admin/configs?action=LIST`
+The `delete` command removes a configset. It does not remove any collections that were created with the configset.
-Fetch the names of the ConfigSets in the cluster.
+name::
+The configset to be deleted. This parameter is required.
-=== List ConfigSet Examples
+To delete a configset named "myConfigSet":
-*Input*
+[.dynamic-tabs]
+--
+[example.tab-pane#v1deleteconfigset]
+====
+[.tab-label]*V1 API*
-[source,text]
-----
-http://localhost:8983/solr/admin/configs?action=LIST
-----
-
-*Output*
+With the v1 API, the `delete` command must be capitalized as `DELETE`. The name of the configset to delete is provided with the `name` parameter:
-[source,json]
+[source,bash]
----
-{
- "responseHeader":{
- "status":0,
- "QTime":203},
- "configSets":["myConfigSet1",
- "myConfig2"]}
+http://localhost:8983/solr/admin/configs?action=DELETE&name=myConfigSet&omitHeader=true
----
+====
-[[configsets-upload]]
-== Upload a ConfigSet
-
-`/admin/configs?action=UPLOAD&name=_name_`
-
-Upload a ConfigSet, sent in as a zipped file. Please note that a ConfigSet is uploaded in a "trusted" mode if authentication is enabled and this upload operation is performed as an authenticated request. Without authentication, a ConfigSet is uploaded in an "untrusted" mode. Upon creation of a collection using an "untrusted" ConfigSet, the following functionality would not work:
-
- * DataImportHandler's ScriptTransformer does not initialize, if specified in the ConfigSet.
- * XSLT transformer (tr parameter) cannot be used at request processing time.
- * StatelessScriptUpdateProcessor does not initialize, if specified in the ConfigSet.
+[example.tab-pane#v2deleteconfigset]
+====
+[.tab-label]*V2 API*
-=== Upload ConfigSet Parameters
+With the v2 API, the `delete` command is provided as the request method, as in `-X DELETE`. The name of the configset to delete is provided as a path parameter:
-name::
-The ConfigSet to be created when the upload is complete. This parameter is required.
-
-The body of the request should contain a zipped config set.
-
-=== Upload ConfigSet Response
-
-The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
-
-=== Upload ConfigSet Examples
-
-Create a config set named 'myConfigSet' from the zipped file myconfigset.zip. The zip file must be created from within the `conf` directory (i.e., `solrconfig.xml` must be the top level entry in the zip file). Here is an example on how to create the zip file and upload it:
-
-[source,text]
+[source,bash]
----
-$ (cd solr/server/solr/configsets/sample_techproducts_configs/conf && zip -r - *) > myconfigset.zip
-
-$ curl -X POST --header "Content-Type:application/octet-stream" --data-binary @myconfigset.zip "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet"
+curl -X DELETE http://localhost:8983/api/cluster/configs/myConfigSet?omitHeader=true
----
+====
+--
-The same can be achieved using a Unix pipe, without creating an intermediate zip file, as follows:
+*Output*
-[source,text]
+[source,xml]
----
-$ (cd server/solr/configsets/sample_techproducts_configs/conf && zip -r - *) | curl -X POST --header "Content-Type:application/octet-stream" --data-binary @- "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=myConfigSet"
+<response>
+ <lst name="responseHeader">
+ <int name="status">0</int>
+ <int name="QTime">170</int>
+ </lst>
+</response>
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
index 75da8b7..83febaf 100644
--- a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
+++ b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
@@ -81,21 +81,21 @@ The <<config-api.adoc#config-api,Config API>> allows you to use an API to modify
[source,json]
----
-{"userProps":{
- "dih.db.url":"jdbc:oracle:thin:@localhost:1521",
- "dih.db.user":"username",
- "dih.db.pass":"password"}}
+{"userProps": {
+ "dih.db.url": "jdbc:oracle:thin:@localhost:1521",
+ "dih.db.user": "username",
+ "dih.db.pass": "password"}}
----
For more details, see the section <<config-api.adoc#config-api,Config API>>.
=== solrcore.properties
-If the configuration directory for a Solr core contains a file named `solrcore.properties` that file can contain any arbitrary user defined property names and values using the Java standard https://en.wikipedia.org/wiki/.properties[properties file format], and those properties can be used as variables in the XML configuration files for that Solr core.
+If the configuration directory for a Solr core contains a file named `solrcore.properties` that file can contain any arbitrary user-defined property names and values using the Java https://en.wikipedia.org/wiki/.properties[properties file format]. Those properties can then be used as variables in other configuration files for that Solr core.
For example, the following `solrcore.properties` file could be created in the `conf/` directory of a collection using one of the example configurations, to override the lockType used.
-[source,bash]
+[source,properties]
----
#conf/solrcore.properties
solr.lock.type=none
@@ -116,15 +116,37 @@ The path and name of the `solrcore.properties` file can be overridden using the
=== User-Defined Properties in core.properties
-Every Solr core has a `core.properties` file, automatically created when using the APIs. When you create a SolrCloud collection, you can pass through custom parameters to go into each core.properties that will be created, by prefixing the parameter name with "property." as a URL parameter. Example:
+Every Solr core has a `core.properties` file, automatically created when using the APIs. When you create a SolrCloud collection, you can pass through custom parameters by prefixing the parameter name with `_property.name_` as a parameter.
+
+For example, to add a property named "my.custom.prop":
+
+[.dynamic-tabs]
+--
+[example.tab-pane#v1customprop]
+====
+[.tab-label]*V1 API*
[source,bash]
+----
http://localhost:8983/solr/admin/collections?action=CREATE&name=gettingstarted&numShards=1&property.my.custom.prop=edismax
+----
+====
-That would create a `core.properties` file that has at least the following properties (others omitted for brevity):
+[example.tab-pane#v2]
+====
+[.tab-label]*V2 API*
[source,bash]
----
+curl -X POST -H 'Content-type: application/json' -d '{"create": {"name": "gettingstarted", "numShards": "1", "property.my.custom.prop": "edismax"}}' http://localhost:8983/api/collections
+----
+====
+--
+
+This will create a `core.properties` file that has at least the following properties (others omitted for brevity):
+
+[source,properties]
+----
#core.properties
name=gettingstarted
my.custom.prop=edismax
@@ -143,7 +165,9 @@ The `my.custom.prop` property can then be used as a variable, such as in `solrco
=== Implicit Core Properties
-Several attributes of a Solr core are available as "implicit" properties that can be used in variable substitution, independent of where or how they underlying value is initialized. For example: regardless of whether the name for a particular Solr core is explicitly configured in `core.properties` or inferred from the name of the instance directory, the implicit property `solr.core.name` is available for use as a variable in that core's configuration file...
+Several attributes of a Solr core are available as "implicit" properties that can be used in variable substitution, independent of where or how the underlying value is initialized.
+
+For example, regardless of whether the name for a particular Solr core is explicitly configured in `core.properties` or inferred from the name of the instance directory, the implicit property `solr.core.name` is available for use as a variable in that core's configuration file:
[source,xml]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/implicit-requesthandlers.adoc b/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
index b58eee7..622fbd5 100644
--- a/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
+++ b/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
@@ -16,64 +16,352 @@
// specific language governing permissions and limitations
// under the License.
-Solr ships with many out-of-the-box RequestHandlers, which are called implicit because they are not configured in `solrconfig.xml`.
+Solr ships with many out-of-the-box RequestHandlers, which are called implicit because they do not need to be configured in `solrconfig.xml` before you are able to use them.
These handlers have pre-defined default parameters, known as _paramsets_, which can be modified if necessary.
-== List of Implicitly Available Endpoints
+== Available Implicit Endpoints
-// TODO 7.1 - this doesn't look great in the PDF, redesign the presentation
+NOTE: All endpoint paths listed below should be placed after Solr's host and port (if a port is used) to construct a URL.
-// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+=== Admin Handlers
-[cols="15,20,15,50",options="header"]
+Many of these handlers are used throughout the Admin UI to show information about Solr.
+
+[horizontal]
+File:: Returns content of files in `${solr.home}/conf/`. This handler must have a collection name in the path to the endpoint.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/admin/file` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ShowFileRequestHandler.html[ShowFileRequestHandler] |`_ADMIN_FILE`
+|===
+
+Logging:: Retrieve and modify registered loggers.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoints |Class & Javadocs |Paramset
+|v1: `solr/admin/info/logging`
+
+v2: `api/node/logging` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ShowFileRequestHandler.html[LoggingHandler] |`_ADMIN_LOGGING`
+|===
+
+Luke:: Expose the internal lucene index. This handler must have a collection name in the path to the endpoint.
++
+*Documentation*: http://wiki.apache.org/solr/LukeRequestHandler
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/admin/luke` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/LukeRequestHandler.html[LukeRequestHandler] |`_ADMIN_LUKE`
+|===
+
+
+MBeans:: Provide info about all registered {solr-javadocs}/solr-core/org/apache/solr/core/SolrInfoBean.html[SolrInfoMBeans]. This handler must have a collection name in the path to the endpoint.
++
+*Documentation*: <<mbean-request-handler.adoc#mbean-request-handler,MBean Request Handler>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/admin/mbeans` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SolrInfoMBeanHandler.html[SolrInfoMBeanHandler] |`_ADMIN_MBEANS`
+|===
+
+Ping:: Health check. This handler must have a collection name in the path to the endpoint.
++
+*Documentation*: <<ping.adoc#ping,Ping>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/admin/ping` |{solr-javadocs}/solr-core/org/apache/solr/handler/PingRequestHandler.html[PingRequestHandler] |`_ADMIN_PING`
+|===
+
+Plugins:: Return info about all registered plugins. This handler must have a collection name in the path to the endpoint.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/admin/plugins` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/PluginInfoHandler.html[PluginInfoHandler] | None.
+|===
+
+System Properties:: Return JRE system properties.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoints |Class & Javadocs |Paramset
+|v1: `solr/admin/info/properties`
+
+v2: `api/node/properties` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/PropertiesRequestHandler.html[PropertiesRequestHandler] |`_ADMIN_PROPERTIES`
+|===
+
+Segments:: Return info on last commit generation Lucene index segments.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/admin/segments` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.html[SegmentsInfoRequestHandler] |`_ADMIN_SEGMENTS`
+|===
+
+System Settings:: Return server statistics and settings.
++
+*Documentation*: https://wiki.apache.org/solr/SystemInformationRequestHandlers#SystemInfoHandler
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoints |Class & Javadocs |Paramset
+|v1: `solr/admin/info/system`
+
+v2: `api/node/system` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SystemInfoHandler.html[SystemInfoHandler] |`_ADMIN_SYSTEM`
+|===
++
+This endpoint can also take the collection or core name in the path (`solr/<collection>/admin/system` or `solr/<core>/admin/system`) which will include all of the system-level information and additional information about the specific core that served the request.
+
+Threads:: Return info on all JVM threads.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoints |Class & Javadocs |Paramset
+|v1: `solr/admin/info/threads`
+
+v2: `api/node/threads` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ThreadDumpHandler.html[ThreadDumpHandler] |`_ADMIN_THREADS`
+|===
+
+=== Analysis Handlers
+
+[horizontal]
+Document Analysis:: Return a breakdown of the analysis process of the given document.
++
+*Documentation*: https://wiki.apache.org/solr/AnalysisRequestHandler
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/analysis/document` |{solr-javadocs}/solr-core/org/apache/solr/handler/DocumentAnalysisRequestHandler.html[DocumentAnalysisRequestHandler] |`_ANALYSIS_DOCUMENT`
+|===
+
+Field Analysis:: Return index- and query-time analysis over the given field(s)/field type(s). This handler drives the <<analysis-screen.adoc#analysis-screen,Analysis screen>> in Solr's Admin UI.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/analysis/field` |{solr-javadocs}/solr-core/org/apache/solr/handler/FieldAnalysisRequestHandler.html[FieldAnalysisRequestHandler] |`_ANALYSIS_FIELD`
+|===
+
+=== Handlers for Configuration
+
+[horizontal]
+Config API:: Retrieve and modify Solr configuration.
++
+*Documentation*: <<config-api.adoc#config-api,Config API>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|v1: `solr/<collection>/config`
+
+v2: `api/collections/<collection>/config` |{solr-javadocs}/solr-core/org/apache/solr/handler/SolrConfigHandler.html[SolrConfigHandler] |`_CONFIG`
+|===
+
+Dump:: Echo the request contents back to the client.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/debug/dump` |{solr-javadocs}/solr-core/org/apache/solr/handler/DumpRequestHandler.html[DumpRequestHandler] |`_DEBUG_DUMP`
+|===
+
+Replication:: Replicate indexes for SolrCloud recovery and Master/Slave index distribution. This handler must have a core name in the path to the endpoint.
++
+[cols="3*.",frame=none,grid=cols,options="header"]
|===
-|Endpoint |Request Handler class |Paramset |Description
-|`/admin/file` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ShowFileRequestHandler.html[ShowFileRequestHandler] |`_ADMIN_FILE` |Returns content of files in `${solr.home}` `/conf/`.
-|`/admin/logging` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ShowFileRequestHandler.html[LoggingHandler] |`_ADMIN_LOGGING` |Retrieve/modify registered loggers.
-|http://wiki.apache.org/solr/LukeRequestHandler[`/admin/luke`] |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/LukeRequestHandler.html[LukeRequestHandler] |`_ADMIN_LUKE` |Expose the internal lucene index.
-|<<mbean-request-handler.adoc#mbean-request-handler,`/admin/mbeans`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SolrInfoMBeanHandler.html[SolrInfoMBeanHandler] |`_ADMIN_MBEANS` |Provide info about all registered {solr-javadocs}/solr-core/org/apache/solr/core/SolrInfoBean.html[SolrInfoMBeans].
-|<<ping.adoc#ping,`/admin/ping`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/PingRequestHandler.html[PingRequestHandler] |`_ADMIN_PING` |Health check.
-|`/admin/plugins` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/PluginInfoHandler.html[PluginInfoHandler] |N/A |Return info about all registered plugins.
-|`/admin/properties` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/PropertiesRequestHandler.html[PropertiesRequestHandler] |`_ADMIN_PROPERTIES` |Return JRE system properties.
-|`/admin/segments` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.html[SegmentsInfoRequestHandler] |`_ADMIN_SEGMENTS` |Return info on last commit generation Lucene index segments.
-|https://wiki.apache.org/solr/SystemInformationRequestHandlers#SystemInfoHandler[`/admin/system`] |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SystemInfoHandler.html[SystemInfoHandler] |`_ADMIN_SYSTEM` |Return server statistics and settings
-|https://wiki.apache.org/solr/SystemInformationRequestHandlers#ThreadDumpHandler[`/admin/threads`] |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ThreadDumpHandler.html[ThreadDumpHandler] |`_ADMIN_THREADS` |Return info on all JVM threads.
-|https://wiki.apache.org/solr/AnalysisRequestHandler[`/analysis/document`] |{solr-javadocs}/solr-core/org/apache/solr/handler/DocumentAnalysisRequestHandler.html[DocumentAnalysisRequestHandler] |`_ANALYSIS_DOCUMENT` |Return a breakdown of the analysis process of the given document.
-|`/analysis/field` |{solr-javadocs}/solr-core/org/apache/solr/handler/FieldAnalysisRequestHandler.html[FieldAnalysisRequestHandler] |`_ANALYSIS_FIELD` |Return index- and query-time analysis over the given field(s)/field type(s).
-|<<config-api.adoc#config-api,`/config`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/SolrConfigHandler.html[SolrConfigHandler] |`_CONFIG` |Retrieve/modify Solr configuration.
-|`/debug/dump` |{solr-javadocs}/solr-core/org/apache/solr/handler/DumpRequestHandler.html[DumpRequestHandler] |`_DEBUG_DUMP` |Echo the request contents back to the client.
-|<<exporting-result-sets.adoc#exporting-result-sets,`/export`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/ExportHandler.html[ExportHandler] |`_EXPORT` |Export full sorted result sets.
-|<<realtime-get.adoc#realtime-get,`/get`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/RealTimeGetHandler.html[RealTimeGetHandler] |`_GET` |Real-time get: low-latency retrieval of the latest version of a document.
-|<<graph-traversal.adoc#exporting-graphml-to-support-graph-visualization,`/graph`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/GraphHandler.html[GraphHandler] |`_ADMIN_GRAPH` |Return http://graphml.graphdrawing.org/[GraphML] formatted output from a <<graph-traversal.adoc#graph-traversal,`gather` `Nodes` streaming expression>>.
-|<<index-replication.adoc#index-replication,`/replication`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/ReplicationHandler.html[ReplicationHandler] |`_REPLICATION` |Replicate indexes for SolrCloud recovery and Master/Slave index distribution.
-|<<schema-api.adoc#schema-api,`/schema`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/SchemaHandler.html[SchemaHandler] |`_SCHEMA` |Retrieve/modify Solr schema.
-|<<parallel-sql-interface.adoc#sql-request-handler,`/sql`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/SQLHandler.html[SQLHandler] |`_SQL` |Front end of the Parallel SQL interface.
-|<<streaming-expressions.adoc#streaming-requests-and-responses,`/stream`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/StreamHandler.html[StreamHandler] |`_STREAM` |Distributed stream processing.
-|<<the-terms-component.adoc#using-the-terms-component-in-a-request-handler,`/terms`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/component/SearchHandler.html[SearchHandler] |`_TERMS` |Return a field's indexed terms and the number of documents containing each term.
-|<<uploading-data-with-index-handlers.adoc#uploading-data-with-index-handlers,`/update`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE` |Add, delete and update indexed documents formatted as SolrXML, CSV, SolrJSON or javabin.
-|<<uploading-data-with-index-handlers.adoc#csv-update-convenience-paths,`/update/csv`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_CSV` |Add and update CSV-formatted documents.
-|<<uploading-data-with-index-handlers.adoc#csv-update-convenience-paths,`/update/json`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON` |Add, delete and update SolrJSON-formatted documents.
-|<<transforming-and-indexing-custom-json.adoc#transforming-and-indexing-custom-json,`/update/json/docs`>> |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON_DOCS` |Add and update custom JSON-formatted documents.
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<core>/replication` |{solr-javadocs}/solr-core/org/apache/solr/handler/ReplicationHandler.html[ReplicationHandler] |`_REPLICATION`
|===
-== How to View the Configuration
+Schema API:: Retrieve and modify the Solr schema.
++
+*Documentation*: <<schema-api.adoc#schema-api,Schema API>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|v1: `solr/<collection>/schema`, `solr/<core>/schema`
-You can see configuration for all request handlers, including the implicit request handlers, via the <<config-api.adoc#config-api,Config API>>. For the `gettingstarted` collection:
+v2: `api/collections/<collection>/schema`, `api/cores/<core>/schema` |{solr-javadocs}/solr-core/org/apache/solr/handler/SchemaHandler.html[SchemaHandler] |`_SCHEMA`
+|===
-[source,text]
-curl http://localhost:8983/solr/gettingstarted/config/requestHandler
+=== Query Handlers
-To restrict the results to the configuration for a particular request handler, use the `componentName` request parameter. To see just the configuration for the `/export` request handler:
+[horizontal]
+Export:: Export full sorted result sets.
++
+*Documentation*: <<exporting-result-sets.adoc#exporting-result-sets,Exporting Result Sets>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/export` |{solr-javadocs}/solr-core/org/apache/solr/handler/ExportHandler.html[ExportHandler] |`_EXPORT`
+|===
-[source,text]
-curl "http://localhost:8983/solr/gettingstarted/config/requestHandler?componentName=/export"
+RealTimeGet:: Low-latency retrieval of the latest version of a document.
++
+*Documentation*: <<realtime-get.adoc#realtime-get,RealTime Get>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/get` |{solr-javadocs}/solr-core/org/apache/solr/handler/RealTimeGetHandler.html[RealTimeGetHandler] |`_GET`
+|===
+
+Graph Traversal:: Return http://graphml.graphdrawing.org/[GraphML] formatted output from a `gatherNodes` streaming expression.
++
+*Documentation*: <<graph-traversal.adoc#graph-traversal,Graph Traversal>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/graph` |{solr-javadocs}/solr-core/org/apache/solr/handler/GraphHandler.html[GraphHandler] |`_ADMIN_GRAPH`
+|===
+
+SQL:: Front end of the Parallel SQL interface.
++
+*Documentation*: <<parallel-sql-interface.adoc#sql-request-handler,SQL Request Handler>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/sql` |{solr-javadocs}/solr-core/org/apache/solr/handler/SQLHandler.html[SQLHandler] |`_SQL`
+|===
+
+Streaming Expressions:: Distributed stream processing.
++
+*Documentation*: <<streaming-expressions.adoc#streaming-requests-and-responses,Streaming Requests and Responses>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/stream` |{solr-javadocs}/solr-core/org/apache/solr/handler/StreamHandler.html[StreamHandler] |`_STREAM`
+|===
+
+Terms:: Return a field's indexed terms and the number of documents containing each term.
++
+*Documentation*: <<the-terms-component.adoc#using-the-terms-component-in-a-request-handler,Using the Terms Component in a Request Handler>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/terms` |{solr-javadocs}/solr-core/org/apache/solr/handler/component/SearchHandler.html[SearchHandler] |`_TERMS`
+|===
+
+=== Update Handlers
+
+[horizontal]
+Update:: Add, delete and update indexed documents formatted as SolrXML, CSV, SolrJSON or javabin.
++
+*Documentation*: <<uploading-data-with-index-handlers.adoc#uploading-data-with-index-handlers,Uploading Data with Index Handlers>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/update` |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE`
+|===
+
+CSV Updates:: Add and update CSV-formatted documents.
++
+*Documentation*: <<uploading-data-with-index-handlers.adoc#csv-update-convenience-paths,CSV Update Convenience Paths>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/update/csv` |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_CSV`
+|===
+
+JSON Updates:: Add, delete and update SolrJSON-formatted documents.
++
+*Documentation*: <<uploading-data-with-index-handlers.adoc#json-update-convenience-paths,JSON Update Convenience Paths>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/update/json` |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON`
+|===
+
+Custom JSON Updates:: Add and update custom JSON-formatted documents.
++
+*Documentation*: <<transforming-and-indexing-custom-json.adoc#transforming-and-indexing-custom-json,Transforming and Indexing Custom JSON>>
++
+[cols="3*.",frame=none,grid=cols,options="header"]
+|===
+|API Endpoint |Class & Javadocs |Paramset
+|`solr/<collection>/update/json/docs` |{solr-javadocs}/solr-core/org/apache/solr/handler/UpdateRequestHandler.html[UpdateRequestHandler] |`_UPDATE_JSON_DOCS`
+|===
+
+== How to View Implicit Handler Paramsets
+
+You can see configuration for all request handlers, including the implicit request handlers, via the <<config-api.adoc#config-api,Config API>>.
To include the expanded paramset in the response, as well as the effective parameters from merging the paramset parameters with the built-in parameters, use the `expandParams` request param. For the `/export` request handler, you can make a request like this:
-[source,text]
-curl "http://localhost:8983/solr/gettingstarted/config/requestHandler?componentName=/export&expandParams=true"
-== How to Edit the Configuration
+[.dynamic-tabs]
+--
+[example.tab-pane#v1expandparams]
+====
+[.tab-label]*V1 API*
+
+[source,bash]
+----
+http://localhost:8983/solr/gettingstarted/config/requestHandler?componentName=/export&expandParams=true
+----
+====
+
+[example.tab-pane#v2expandparams]
+====
+[.tab-label]*V2 API*
+
+[source,bash]
+----
+http://localhost:8983/api/collections/gettingstarted/config/requestHandler?componentName=/export&expandParams=true
+----
+====
+--
+
+The response will look similar to:
+
+[source,json]
+----
+{
+ "config": {
+ "requestHandler": {
+ "/export": {
+ "class": "solr.ExportHandler",
+ "useParams": "_EXPORT",
+ "components": ["query"],
+ "defaults": {
+ "wt": "json"
+ },
+ "invariants": {
+ "rq": "{!xport}",
+ "distrib": false
+ },
+ "name": "/export",
+ "_useParamsExpanded_": {
+ "_EXPORT": "[NOT AVAILABLE]"
+ },
+ "_effectiveParams_": {
+ "distrib": "false",
+ "omitHeader": "true",
+ "wt": "json",
+ "rq": "{!xport}"
+ }
+ }
+ }
+ }
+}
+----
+
+== How to Edit Implicit Handler Paramsets
-Because implicit request handlers are not present in `solrconfig.xml`, configuration of their associated `default`, `invariant` and `appends` parameters may be edited via<<request-parameters-api.adoc#request-parameters-api, Request Parameters API>> using the paramset listed in the above table. However, other parameters, including SearchHandler components, may not be modified. The invariants and appends specified in the implicit configuration cannot be overridden.
+Because implicit request handlers are not present in `solrconfig.xml`, configuration of their associated `default`, `invariant` and `appends` parameters may be edited via the <<request-parameters-api.adoc#request-parameters-api, Request Parameters API>> using the paramset listed in the above table. However, other parameters, including SearchHandler components, may not be modified. The invariants and appends specified in the implicit configuration cannot be overridden.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/5915e61e/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
index e60f52f..c2008fa 100644
--- a/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
+++ b/solr/solr-ref-guide/src/requestdispatcher-in-solrconfig.adoc
@@ -68,7 +68,7 @@ This attribute can be used to indicate that the original `HttpServletRequest` ob
addHttpRequestToContext="false" />
----
-The below command is an example of how to enable RemoteStreaming and BodyStreaming through the <<config-api.adoc#creating-and-updating-common-properties,Config API>>:
+The below command is an example of how to enable RemoteStreaming and BodyStreaming through the <<config-api.adoc#commands-for-common-properties,Config API>>:
[.dynamic-tabs]
--