Skip to content

Commit

Permalink
Merge remote-tracking branch 'upstream/main' into SOLR-16957
Browse files Browse the repository at this point in the history
  • Loading branch information
epugh committed Sep 12, 2023
2 parents 59f6ae1 + b98d936 commit d6947f6
Show file tree
Hide file tree
Showing 338 changed files with 6,018 additions and 2,296 deletions.
83 changes: 83 additions & 0 deletions dev-docs/apis.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
= APIs in Solr
:toc: left

Solr's codebase currently has a handful of ways of defining APIs.
This complexity stems largely from two ongoing transitions:
1. Away from our "v1" APIs and towards the new "v2" API.
2. Away from a legacy API framework towards the off-the-shelf JAX-RS library for implementing our v2 APIs

As we finish these transitions, this complexity should simplify considerably.
But in the interim, this document can help guide developers who need to understand or modify APIs in Solr.

== API Types

APIs in Solr (regardless of whether v1 or v2) can typically be classified as either "per-core" or "cluster" APIs.

Per-core APIs, as the name suggests, typically affect only a single core or collection, usually used to search or analyze that core's contents in some way.
Implementation-wise, they're registered on the `SolrCore` object itself.
They are configured in solrconfig.xml, which also means they can differ from one core to another based on the configset being used.

Alternatively "cluster" APIs potentially affect the entire Solr instance or cluster.
They're registered on the `CoreContainer` object itself.
It's much less common to provide configuration for these APIs, but it is possible to do so using `solr.xml`.

== V1 APIs

v1 APIs are the primary way that users consume Solr, as our v2 APIs remain "experimental".
Many new APIs are added as "v2 only", however updates to existing v1 APIs still happen frequently.

v1 APIs exist in Solr as implementations of the `SolrRequestHandler` interface, usually making use of the `RequestHandlerBase` base class.
RequestHandlers have two methods of primary interest:
1. `init`, often used to parse per-API configuration or otherwise setup the class
2. `handleRequest` (or `handleRequestBody` if using `RequestHandlerBase`), the main entrypoint for the API, containing the business logic and constructing the response.

While they do define many aspects of the endpoint's interface (e.g. query parameters, request body format, response format, etc.), RequestHandler's don't actually specify the URL path that they're located at.
These paths are instead either hardcoded at registration time (see `CoreContainer.load` and `ImplicitPlugins.json`), or specified by users in configuration files (typically `solrconfig.xml`).

== V2 APIs

v2 APIs are currently still "experimental", and not necessarily recommended yet for users.
But they're approaching parity with v1 and will eventually replace Solr's "RequestHandler"-based APIs.

=== New "JAX-RS" APIs

New v2 APIs in Solr are written in compliance with "JAX-RS", a library and specification that uses annotations to define APIs.
Many libraries implement the JAX-RS spec: Solr currently uses the implementation provided by the "Jersey" project.

These v2 API definitions consist of two parts: a JAX-RS annotated interface in the `api` module "defining" the API, and a class in `core` "implementing" the interface.
Separating the API "definition" and "implementation" in this way allows us to only define each API in a single place, and use code generators to produce other API-related bits such as SolrJ code and ref-guide documentation.

=== Writing JAX-RS APIs

Writing a new v2 API may appear daunting, but additions in reality are actually pretty simple:

1. *Create POJO ("Plain Old Java Object") classes as needed to represent the API's request and response*:
** POJOs are used to represent both the body of the API request (for some `POST` and `PUT` endpoints), as well as the response from the API.
** Re-use of existing classes here is preferred where possible. A library of available POJOs can be found in the `org.apache.solr.client.api.model` package of the `api` gradle project.
** POJO class fields are typically "public" and annotated with the Jackson `@JsonProperty` annotations to allow serialization/deserialization.
** POJO class fields should also have a Swagger `@Schema` annotation where possible, describing the purpose of the field. These descriptions are technically non-functional, but add lots of value to our OpenAPI spec and any artifacts generated downstream.
2. *Find or create an interface to hold the v2 API definition*:
** API interfaces live in the `org.apache.solr.client.api.endpoint` package of the `api` gradle project. Interfaces are usually given an "-Api" suffix to indicate their role.
** If a new API is similar enough to existing APIs, it may make sense to add the new API definition into an existing interface instead of creating a wholly new one. Use your best judgement.
3. *Add a method to the chosen interface representing the API*:
** The method should take an argument representing each path and query parameter (annotated with `@PathParam` or `@QueryParam` as appropriate). If the API is a `PUT` or `POST` that expects a request body, the method should take the request body POJO as its final argument, annotated with `@RequestBody`.
** Each method parameter should also be annotated with the Swagger `@Parameter` annotation. Like the `@Schema` annotation mentioned above, `@Parameter` isn't strictly required for correct operation, but they add lots of value to our OpenAPI spec and generated artifacts.
** As a return value, the method should return the response-body POJO.
4. *Futher JAX-RS Annotation*: The interface method in step (3) has specified its inputs and outputs, but several additional annotations are needed to define how users access the API, and to make it play nice with the code-generation done by Solr's build.
** Each interface must have a `@Path` annotation describing the path that the API is accessed from. Specific interface methods can also be given `@Path` annotations, making the "effective path" a concatenation of the interface and method-level values. `@Path` supports a limited regex syntax, and curly-brackets can be used to create named placeholders for path-parameters.
** Each interface method should be given an HTTP-method annotation (e.g. `@GET`, `@POST`, etc.)
** Each interface method must be marked with a Swagger `@Operation` annotation. This annotation is used to provide metadata about the API that appears in the OpenAPI specification and in any artifacts generated from that downstream. At a minimum, `summary` and `tags` values should be specified on the annotation. (`tags` is used by our SolrJ code generation to group similar APIs together. Typically APIs are only given a single tag representing the plural name of the most relevant "resource" (e.g. `tags = {"aliases"}`, `tags = {"replica-properties"}`)
5. *Create a class implementing the API interface*: Implementation classes live in the `core` gradle project, typically in the `org.apache.solr.handler` package or one of its descendants.
** Implementing classes must extent `JerseyResource`, and are typically named similarly to the API interface created in (2) above without the "-Api" suffix. e.g. `class AddReplicaProperty extends JerseyResource implements AddReplicaPropertyApi`)
** Solr's use of Jersey offers us some limited dependency-injection ("DI") capabilities. Class constructors annotated with `@Inject` can depend on a selection of types made available through DI, such as `CoreContainer`, `SolrQueryRequest`, `SolrCore`, etc. See the factory-bindings in `JerseyApplications` (or other API classes) for a sense of which types are available for constructor injection.
** Add a body to your classes method(s). For the most part this is "normal" Java development.
6. *Register your API*: APIs must be registered to be available at runtime. If the v2 API is associated with an existing v1 RequestHandler, the API class name can be added to the handler's `getJerseyResources` method. If there is no associated RequestHandler, the API should be registered similar to other APIs in `CoreContainer.load`.

A good example for each of these steps can be seen in Solr's v2 "add-replica-property" API, which has a defining interface https://github.com/apache/solr/blob/9426902acb7081a2e9a1fa29699c5286459e1365/solr/api/src/java/org/apache/solr/client/api/endpoint/AddReplicaPropertyApi.java[AddReplicaPropertyApi], an implementing class https://github.com/apache/solr/blob/9426902acb7081a2e9a1fa29699c5286459e1365/solr/core/src/java/org/apache/solr/handler/admin/api/AddReplicaProperty.java[AddReplicaProperty], and the two POJOs https://github.com/apache/solr/blob/main/solr/api/src/java/org/apache/solr/client/api/model/AddReplicaPropertyRequestBody.java[AddReplicaPropertyRequestBody] and https://github.com/apache/solr/blob/main/solr/api/src/java/org/apache/solr/client/api/model/SolrJerseyResponse.java[SolrJerseyResponse].

=== Legacy v2 API Framework

While we've settled on JAX-RS as our framework for defining v2 APIs going forward, Solr still retains many v2 APIs that were written using an older homegrown framework.
This framework defines APIs using annotations (e.g. `@EndPoint`) similar to those used by JAX-RS, but lacks the full range of features and 3rd-party tooling.
We're in the process of migrating these API definitions to JAX-RS and hope to remove all support for this legacy framework in a future release.

47 changes: 45 additions & 2 deletions solr/CHANGES.txt
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,8 @@ Improvements

* SOLR-16536: Replace OpenTracing instrumentation with OpenTelemetry (Alex Deparvu, janhoy)

* SOLR-15367: Convert "rid" functionality into a default Tracer (Alex Deparvu, David Smiley)

Optimizations
---------------------
(No changes)
Expand Down Expand Up @@ -68,7 +70,9 @@ Other Changes
================== 9.4.0 ==================
New Features
---------------------
(No changes)
* SOLR-16654: Add support for node-level caches (Michael Gibney)

* SOLR-16954: Make Circuit Breakers available for Update Requests (janhoy, Christine Poerschke, Pierre Salagnac)

Improvements
---------------------
Expand Down Expand Up @@ -101,8 +105,23 @@ Improvements

* SOLR-16940: Users can pass Java system properties to the SolrCLI via the SOLR_TOOL_OPTS environment variable. (Houston Putman)

* SOLR-15474: Make Circuit breakers individually pluggable (Atri Sharma, Christine Poerschke, janhoy)

* SOLR-16927: Allow SolrClientCache clients to use Jetty HTTP2 clients (Alex Deparvu, David Smiley)

* SOLR-16896, SOLR-16897: Add support of OAuth 2.0/OIDC 'code with PKCE' flow (Lamine Idjeraoui, janhoy, Kevin Risden)

* SOLR-16879: Limit the number of concurrent expensive core admin operations by running them in a
dedicated thread pool. Backup, Restore and Split are expensive operations.
(Pierre Salagnac, David Smiley)

* SOLR-16964: The solr.jetty.ssl.sniHostCheck option now defaults to the value of SOLR_SSL_CHECK_PEER_NAME, if it is provided.
This will enable client and server hostName check settings to be governed by the same environment variable.
If users want separate client/server settings, they can manually override the solr.jetty.ssl.sniHostCheck option in SOLR_OPTS. (Houston Putman)

* SOLR-16970: SOLR_OPTS is now able to override options set by the Solr control scripts, "bin/solr" and "bin/solr.cmd". (Houston Putman)


Optimizations
---------------------

Expand All @@ -128,8 +147,30 @@ Bug Fixes

* PR#1826: Allow looking up Solr Package repo when that URL references a raw repository.json hosted on Github when the file is JSON but the mimetype used is text/plain. (Eric Pugh)

* SOLR-16944: V2 API /api/node/health should be governed by "health" permission, not "config-read" (janhoy)

* SOLR-16859: Missing Proxy support for Http2SolrClient (Alex Deparvu)

* SOLR-16929: SolrStream propagates undecoded error message (Alex Deparvu)

* SOLR-16934: Allow Solr to read client (javax.net.ssl.*) trustStores and keyStores via SecurityManager. (Houston Putman)

* SOLR-16946: Updated Cluster Singleton plugins are stopped correctly when the Overseer is closed. (Paul McArthur)

* SOLR-16933: Include the full query response when using the API tool, and fix serialization issues for SolrDocumentList. (Houston Putman)

* SOLR-16916: Use of the JSON Query DSL should ignore the defType parameter
(Christina Chortaria, Max Kadel, Ryan Laddusaw, Jane Sandberg, David Smiley)

* SOLR-16958: Fix spurious warning about LATEST luceneMatchVersion (Colvin Cowie)

* SOLR-16955: Tracing v2 apis breaks SecurityConfHandler (Alex Deparvu, David Smiley)

* SOLR-16044: SlowRequest logging is no longer disabled if SolrCore logger set to ERROR (janhoy, hossman)

* SOLR-16415: asyncId must not have '/'; enforce this. Enhance ZK cleanup to process directories
instead of fail. (David Smiley, Paul McArthur)

Dependency Upgrades
---------------------

Expand All @@ -148,6 +189,8 @@ Other Changes

* SOLR-16915: Lower the AffinityPlacementPlugin's default minimalFreeDiskGB to 5 GB (Houston Putman)

* SOLR-16623: new SolrJettyTestRule for tests needing HTTP or Jetty. (David Smiley, Joshua Ouma)

================== 9.3.0 ==================

Upgrade Notes
Expand Down Expand Up @@ -271,7 +314,7 @@ Improvements

* SOLR-16687: Add support of SolrClassLoader to SolrZkClient (Lamine Idjeraoui via Jason Gerlowski & Houston Putman)

* SOLR-9378: Internal shard requests no longer include the wasteful shard.url param. [shard] transformer now defaults to returning
* SOLR-9378: Internal shard requests no longer include the wasteful shard.url param. [shard] transformer now defaults to returning
only the shard id (based on luceneMatchVersion), but can be configured to return the legacy list of replicas. (hossman)

* SOLR-16816: Update node metrics while making affinityPlacement selections. Therefore selections can be made given the expected cluster
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -17,26 +17,22 @@

package org.apache.solr.client.api.endpoint;

import static org.apache.solr.client.api.util.Constants.BINARY_CONTENT_TYPE_V2;

import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.parameters.RequestBody;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import org.apache.solr.client.api.model.AddReplicaPropertyRequestBody;
import org.apache.solr.client.api.model.SolrJerseyResponse;

@Path("/collections/{collName}/shards/{shardName}/replicas/{replicaName}/properties/{propName}")
public interface AddReplicaPropertyApi {

@PUT
@Produces({"application/json", "application/xml", BINARY_CONTENT_TYPE_V2})
@Operation(
summary = "Adds a property to the specified replica",
tags = {"replicas"})
tags = {"replica-properties"})
public SolrJerseyResponse addReplicaProperty(
@Parameter(
description = "The name of the collection the replica belongs to.",
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
/*
* 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.
*/
package org.apache.solr.client.api.endpoint;

import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.parameters.RequestBody;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import org.apache.solr.client.api.model.GetAliasPropertyResponse;
import org.apache.solr.client.api.model.GetAllAliasPropertiesResponse;
import org.apache.solr.client.api.model.SolrJerseyResponse;
import org.apache.solr.client.api.model.UpdateAliasPropertiesRequestBody;
import org.apache.solr.client.api.model.UpdateAliasPropertyRequestBody;

/** V2 API definitions for managing and inspecting properties for collection aliases */
@Path("/aliases/{aliasName}/properties")
public interface AliasPropertyApis {

@GET
@Operation(
summary = "Get properties for a collection alias.",
tags = {"alias-properties"})
GetAllAliasPropertiesResponse getAllAliasProperties(
@Parameter(description = "Alias Name") @PathParam("aliasName") String aliasName)
throws Exception;

@GET
@Path("/{propName}")
@Operation(
summary = "Get a specific property for a collection alias.",
tags = {"alias-properties"})
GetAliasPropertyResponse getAliasProperty(
@Parameter(description = "Alias Name") @PathParam("aliasName") String aliasName,
@Parameter(description = "Property Name") @PathParam("propName") String propName)
throws Exception;

@PUT
@Operation(
summary = "Update properties for a collection alias.",
tags = {"alias-properties"})
SolrJerseyResponse updateAliasProperties(
@Parameter(description = "Alias Name") @PathParam("aliasName") String aliasName,
@RequestBody(description = "Properties that need to be updated", required = true)
UpdateAliasPropertiesRequestBody requestBody)
throws Exception;

@PUT
@Path("/{propName}")
@Operation(
summary = "Update a specific property for a collection alias.",
tags = {"alias-properties"})
SolrJerseyResponse createOrUpdateAliasProperty(
@Parameter(description = "Alias Name") @PathParam("aliasName") String aliasName,
@Parameter(description = "Property Name") @PathParam("propName") String propName,
@RequestBody(description = "Property value that needs to be updated", required = true)
UpdateAliasPropertyRequestBody requestBody)
throws Exception;

@DELETE
@Path("/{propName}")
@Operation(
summary = "Delete a specific property for a collection alias.",
tags = {"alias-properties"})
SolrJerseyResponse deleteAliasProperty(
@Parameter(description = "Alias Name") @PathParam("aliasName") String aliasName,
@Parameter(description = "Property Name") @PathParam("propName") String propName)
throws Exception;
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
/*
* 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.
*/
package org.apache.solr.client.api.endpoint;

import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.parameters.RequestBody;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import org.apache.solr.client.api.model.BalanceReplicasRequestBody;
import org.apache.solr.client.api.model.SolrJerseyResponse;

@Path("cluster/replicas/balance")
public interface BalanceReplicasApi {
@POST
@Operation(
summary = "Balance Replicas across the given set of Nodes.",
tags = {"cluster"})
SolrJerseyResponse balanceReplicas(
@RequestBody(description = "Contains user provided parameters")
BalanceReplicasRequestBody requestBody)
throws Exception;
}
Loading

0 comments on commit d6947f6

Please sign in to comment.